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?
Pretty much - not sure I held the sustain beyond the first beat of the new song…but meant that I could switch songs while the last chord of Song 1 was being held and all the patches I needed for the first beat of Song 2 were there ready for me to play on the beat.
Been I while since I’ve needed to do it TBH…(it was a jukebox musical with a segue between two numbers) so my memory’s a little hazy!
The solution I described in my earlier post solves this problem and requires none of the steps you listed. To make a new song set, I just load my master song, right-click on each rack and select “Replace Rack” to replace it with a different song’s rack, and I’m done. No reprogramming. It takes me about 30 seconds to create a new set from my collection of song-racks, and each song is sustainable with pedal as I start to play the next.
OK, I have a better idea of what you’re doing there. I guess you need to separately note things like song tempo, time signature etc. as that won’t be stored in a rack, only in a song. And for anyone using other song information that is typically saved in a song, such as global transposition, notes, etc. those can’t be stored in a rack either.
The other thing that’s missing when you do things like this is that it’s harder to see at a glance notes/comments (can’t remember the name of the column) for each instrument/FX layer in a rack for quick adjustment or memory.
For example, I may have a pad that uses CC17 for filter cutoff, two EPs whose volume is controlled by CC20, an FX layer (stutter/glitch) controlled by CC21. I put those in the notes column so if in the middle of playing I forget what knob on my controller I’ve assigned to the EP volume I can glance at the computer screen an the song has all that info. And I can quickly reach over and do things on the computer if I need to.
If this is all in a rack I’d need to expand each rack… maybe they all stay expanded when there are multiple racks? Not sure.
So I can see how this might work in scenarios where songs have very consistent VSTs and settings, and you have a separate place you’re referencing tempo and time signature, setting that up each time but it seems that’d add a lot to my workflow and limit more visibility.
But if I have to do this for only 2 songs in a 5-song set, maybe that’s a decent workaround/option.
That’s true, if tempo/meter isn’t served by an external clock, one must set them for each song state. I’ve found that to be very quick (adds another few seconds per song prep time).
I think you can set each song state to auto-open a particular rack when the state loads (e.g., using a binding). Like you, my VST controls are not consistent so I need notes, but I personally prefer forScore for my sheet music, in which I have notes about which buttons to press when; so I only refer to my rack comments when prepping. I’m also loving my Presonus Atom SQ controller because it lets me color-code the buttons per song, which really helps me remember which is which. (See my other thread on the merits of that controller.)
I guess I should also mention that there’s actually a nifty way to “store” tempo/meter/transpose settings in racks that I sometimes use for more complex songs: I have my master song programmed to send a special CC message to the “current” song-rack whenever it becomes the “active” song. This allows all my song-racks to optionally listen for that CC message and set the global tempo/meter/transpose to prescribed, song-specific values. The tempo-setting bindings live in the rack, so it’s a way to “store” such things in racks.
