Unfortunately, I don’t think there is an easy way to do this between songs in Cantabile.
Bummer – but thanks for the info!
It’s not an easy problem to solve, though I think there are ways to solve it. For example, when issuing a command to switch songs Cantabile could load all the plugins for the next song, but also keep all the plugins live from the old song for a user-determinable amount of time (e.g., 5 seconds) before killing them.
It’s rather surprising to here that implementation complexity is the biggest challenge (rather than say concerns about perf or resident memory). It seems like at some level – at the OS process level if all else fails ! – there should be some way to “double buffer” the whole system and keep the prior sound alive until all the midi notes have ended (or a third song is selected).
But anyway thanks for the details - I guess I’ll investigate some of the other software solutions that do support this feature. Much appreciated!
This subject has come up a lot of times and currently there is no SST or SSS on Cantabile songs but it does satisfy the patch persistence but not from song to song. It does support Song state to Song state transitions like this so some folks made their songs into song states. In other words the set list for a set is all loaded as one song and you switch between the song states for your changes. This does support SST or SSS style changes. I use this style but only where there are songs I want to join like in this request, the rest of the set list is Cantabile songs because there are definite endings and silence to change over in.
Cantabile doesn’t “keep things going” when switching between songs, but I use a work around when I need this between songs, because it doe sustain notes between states within a song. All I do is combine the two songs together, so you have the states for each song all in a single song, and simply keep stepping through the states. It works a treat for me, but it can involve a load of extra programming, but it is well worth it.
The problem with sustaining sound across songs is that this requires two song setups to be active at the same time (for a certain period of overlap) - one for the old, one for the new song. This can create problems along various fronts:
it will require the processing power to run both song setups at the same time - might be too much load for complex setups
the process of loading and un-loading a song while another is busy playing puts additional strain on a system, which could lead to glitches
the old and the new song could contain common shared racks, but in different rack states, which creates conflicts. Essentially this would mean that shared racks would need to be loaded twice to enable this seamless “overlap”. Kind of defeats the idea of preloaded shared racks…
once you get more sophisticated with bindings that fire on song load and song unload, overlapping two songs could have all sorts of nasty implications with the sequence of bindings firing.
I feel that addressing this may be quite a challenge - this is the downside of the super-powerful and flexible architecture of Cantabile. This is a functionality that would be easier to realize in a more simplified, more constrained architecture.
So I wouldn’t hold my breath for this to be implemented anytime soon - we’ll have to work around this somehow…
I do this all the time with Cantabile (most of my “songs” are actually sets of up to 16 songs, each of which overlaps the next), and I find that Cantabile is excellent at this as long as you do what @Sausagefingers describes:
Each of my “songs” is actually a linked rack in Cantabile.
A “set” is actually a song in Cantabile, with one song state for each song in the set.
Each song state has the MIDI route to the relevant song rack enabled, and all the other routes disabled (except that I have always-enabled routes for foot pedals to all the song-racks, so that foot pedal events are never blocked).
Switching song-states changes songs. This works perfectly because Cantabile still sends note-off events along disabled MIDI routes; it only blocks new note-on events to disabled MIDI routes. So I can sustain the chord of the previous song with my fingers or with the foot pedal, switch to the new song, start playing, and everything works just as it should.
If computing resources are a problem, I disable all racks except the ones for the current and previous songs in each song-state. I can even create a delayed binding that disables the previous rack after a set length of time if necessary, so that only one rack is enabled most of the time.
I only need to create this special song once. New song sets can then be implemented by just replacing the racks in the song to quickly create a new song-set.
Once upon a time I trialed Gig Performer vs. Cantabile and concluded that Cantabile is vastly superior in terms of power for this. Gig Performer seems easier and mostly equivalent until you dig into it and discover that it has far fewer options relative to Cantabile when you get down into the details. This makes Cantabile a little harder to learn, but once learned it offers far more power.
Thanks for the suggestions @Hamlen – I can see how this would be actionable for many users with simpler needs. Unfortunately, I don’t think it’ll work for me. Within a single song, I typically use at least 4 separate parts/voices/timbres, and more often 8 or more* - which I am constantly muting/unmuting manually as I transition between song part.
Best case, it sounds like I could only manage two or three “songs” within a Cantabile song, at the cost of a lot of manual programming and limiting my max # of sounds a fair bit (particularly if I also want a separate effect chain per song). Presumably, all these constituent sounds also have to be fully resident in order to allow this, which seems like it’d impose pretty steep overhead.
I sincerely do appreciate all the suggestions, folks! But it is a bit amusing how you all keep saying "yeah, that super useful thing everyone else is doing? It’s not possible because of how powerful and flexible Cantabile is " =D
This probably seems like a lot to most folks, but my standard setup is a master Kronos with midi bass pedals for pads, and and a secondary keyboard that routes both its onboard audio and midi signal to the kronos, where I can apply up to 16 onboard timbres per song plus up to 8 sounds from my laptop running an Omnisphere multi.
Well, this is a bit provocative, don’t you think? I am sure you are aware of the existence of trade-offs, in software like in everything else. You wouldn’t disparage a Ferrari because you can’t plow a field with it, though of course it would be very useful if it could do it.
Your “typical” use seems not so impressive to me, with respect to Cantabile capabilities. As always, anyone must use what suits best his needs…so if Gig Performer is the one, definetely go for it.
In the setup I described, my typical songs each have about 8-32 parts/voices/timbres spread across around 4 instances of Omnisphere and Kontakt per song, which I’m muting/unmuting manually as the song progresses. When I tried this on Gig Performer, it could not keep up; but Cantabile seemed to be more performant, which is why I stuck with it. Just my experience.
Cantabile is more than capable of what you are doing, but it would be good to know which version you are using. The thing to consider is your laptop/pc capability. I started out on my Cantabile journey with an i5 1.0 GHz processor and 8Gbit of RAM with a Yamaha MX61 keyboard as controller. I managed up to 16 vsts, all pre-loaded and running virtually without problem. A couple of times I had to swap a vst or two for ones which were less power hungry, and this did increase as I made more and more demands on my kit.
I now have an i7 2.8GHz processor with 16GBit of RAM and have had no problems whatsoever, running up to 18 vsts, and I haven’t had to worry about processor or RAM overload.
If you follow the route of Songs and States you should be able to incorporate all your changes and mutings, although a footpedal to change from one state to another - I use a Behringer FCB1010, for instance - is more than useful. And although I don’t have the problem now, I have in the past made a state at the end of a song which closes down all the vsts in that song, thus reducing the number of vsts running in the background, and this too will help.
It’s also a question of where you need smooth sound transitions.
TBH I have only ever needed it in songs between parts, not across songs.
But in that I include albums like Dark Side of the Moon where in the Floyd band I was in, we played side one first and then side two from start to finish with no interruption, but in that case, whilst we split side one up to give the guitar player a chance to get ready for slide on “Great Gig”, I treated side two as one continuous song with parts in it. Cantabile works a treat in that context.
So it really depends on what you want to do and how you set things up, and TBH even hardware units with SST usually have limitations that you need to plan for,
Thanks for the suggestions of workarounds @Sausagefingers and others in the thread. I will try that. Often in a set I may only have two songs where I need a seamless transition so hopefully there’s a way to load a song into a state so I don’t have to “rebuild” the song in a state.
@timc you’re exactly right, and I’ve thought the same myself. Cantabile should be able to handle this, ESPECIALLY since it’s a powerful and flexible app.
For example, if seamless transitions work between song states, then why couldn’t I choose an option for an individual song, to seamlessly transition to the next song? It would be a flag, and heck, they could add a warning about watching out for high CPU usage, etc. if necessary.
I’d much rather have the option and choice available than not have the feature available because some people, in some rare scenarios (too many hungry VSTs, too slow a CPU) might have problems. If it works using song states, then the app and your CPU can definitely handle it.
OK, so this workaround is doable, but you can’t “link” a song into a song state as far as I can tell. So I have to copy all the objects from the second song and pasted them in the first song, then disable routing in the second state to instruments that should only be there in the first song, and vice versa.
That’s a lot of work for every scenario I’d run into. I thought I could somehow copy the second song into a song state and go from there.
It’s fine if you use all the same instruments for both songs, but that’s almost never the case for me.
Also, this second song in State 2 means that the first song always has it from now on, but that’s almost never going to be needed for another set, with different songs. So I have to:
Save Song 1 as a separate (combined) song file
Remove the first song from the set
Edit the song to add the second song state
Copy all the instruments, effects, etc. from Song 2
Go paste them into Song 1, State 2
Go to Song 1, State 1, disable routing to song instruments from Song 2.
Go into Song 1, State 2, disable routing to song instruments from Song 1.
Remove the standalone Song 2.
So I guess I’m back to hoping a feature gets added where I can simply check a box in Song 1 (Enable sustained sound transition) so that Song 2 can start even while notes are fading out or being held for a bit from Song 1.
It works when building the big complex workaround as described above, with no hitches, no glitches, so I guess I’m left wondering why this couldn’t be implemented between two songs.
The only surefire way to realize this would be to keep the current song loaded and active when loading the next one. Then, on the next change, swap out the oldest song for the next. I wouldn’t want song loading or un-loading going on during a song, only on changes (avoid CPU and storage overloads).
But this would mean having two songs active at the same time, creating double CPU load. Definitely something I would only want to be optional - given the complexity of my typical songs, I would probably keep this set to OFF.
Would be interesting if @brad considers this feasible…
There is no SST/SSS between songs.
You can hold notes between Song States, as others have described.
However, here’s my workaround:
Each song is a song, as i tend to use song states for parts or different sounds within a song.
FX like Reverb and Delays are in the background rack. All instruments are dry and are routed to the background rack for reverbs and delays.
When i switch between songs, the sound of the instrument stops but the reverb tail or delays keep going, because the background rack doesn’t change between songs.
This way you stop playing when switching songs but there is no sudden ending in the sounds.
The Setlist is always preloaded.
@Steffen Interesting. So I always preload the entire set with no issues. But you’re saying that you have a standard reverb in the background rack for all songs and everything gets routed there? I have a standard compressor and mastering VST (God Particle) in every song, however the settings have to be often customized per song depending on the synths I’m using, so one setting for all songs might be hard to do.
I guess the other thing is that usually I have at least one pad in play, so if I cut it off and just reverb tailed it still would sound very noticeable.
@Torsten My CPU and RAM are quite strong, even on a laptop. I often have anywhere from 4-10 instrument VSTs and a 2-6 FX VSTs in play for one song. So having two songs loaded and active would be no problem at all, especially since the second song’s VSTs shouldn’t be doing much while waiting to receive notes once I move to that song.
However I don’t know what you mean by having 2 songs active at the same time. I pre-load all the songs when I load the set, but what do you mean by swapping out Song 1 for Song 2 as opposed to switching to Song 2?
So in your scenario, say Song 1 is ending and you have the sustain pedal held. You switch to Song 2 and the sounds are still being held as you hold the sustain pedal, but any new notes are using Song 2. You let go of the pedal, Song 1’s sounds trail off while you’re already playing Song 2. Is that functionally how it works?
