I’m having problems with changing rack states and I can’t figure out what I’m doing wrong. I have a base rack that stays through the set. The songs are all single part (though only in this set). I have built the rack with a few VSTs. I have created a few states for this rack, say 5, which use the VSTs in different on/off combinations, key ranges, octaves. I want to use Song 1 with Rack state 1, S2 with RS 5, S3 with RS 2, etc. So I go to S1, select RS1, go to S2, select RS 5 and so on. Sounds pretty simple but I can’t. As soon as I change the song, the rack state always goes back to 1. I know there’s rack behaviors involved, but I haven’t changed anything from the default and also, I really don’t understand what “Exported state” means. I would expect the selected rack state to be stored with the song. Thanks for any clarification.
Sounds odd. In the online guide, there’s a comprehensive chapter on state.
Do you use bindings to switch between states?
And speaking of exported state, take a look here.
Hi @MarcoP,
can I suggest creating one state in each song, then choosing the correct state in the rack and finally updating the song state, so that the state of the rack is “saved” into the Song state? In this way, when the Song loads its own state, it should also change the rack state accordingly.
Do this for a couple of Songs and test if it works. Maybe there is another workaround. I usually do this way, because I have more than one state for each song, but it should work the same with just one state per song.
Gabriel
Hi, thank you for the answer, but this is exactly what I’m trying to do. The songs only have 1 state (I will need more states later, but I’m testing with just 1 now), the rack has 5 states. In the behaviours checklist, for all the VSTs involved I have checked both options for program and bank, which should select a different state for each new song. If I choose rack state 1 for song 1 and rack state 4 for song 2, as soon as I change songs the rack state returns to 1 for both. Also, if “updating” the song means exiting the rack, I do that and the song change autosaves the set. Is there something else?
Hi, thank you for the reply. I have read the whole online guide , and it all seems clear except I can’t make it work. I have also tried copying and pasting the rack through the songs, but nothing changed.
Have you checked Run and Bypass in the State Behavior?
Sorry, it was not clear to me that you already had a state in the song.
Sorry again, I do not count on the autosave behaviour of the states so I can’t be of much help. Some time ago, I decided that I preferred to have locked states by default. For my way of working, this was the only way to be sure that only intended modifications where reflected into the state. Now in order to “commit” a change to a state I have to press cntrl+U explicitly. That’s what I meant when I mentioned “updating” a state.
If I have made a change and I want it to be remembered without loosing the previous state, I create a new state.
Maybe you could try forcing the update of the only state you have in the song with cntrl+U and see if it does make a difference.
Gabriel
Thanks for the replies everyone, I’m grateful for your patience. I was sort of able to make the rack state thing work through copy/paste, but now I’m trying songs with a few parts (intro/verse/chorus etc.) and it seems to me it is not possible to change parts and their associated plug-ins without declaring ALL of them at the start, which should not be necessary. Regarding state behaviors, I have checked pretty much everything until the “Editor visibility” box, just to test. But this is what happens: If I want a VST combination for Part 1 (Intro), and a different combination for Part 2 (chorus), with maybe one different VST and the same VST but in a different key range, whatever modification I make to Part 2 is copied to Part 1. So I have to duplicate the same VST in all parts, however many there are, and then I can mute or change key range to the different versions of the same VST throughout the different parts. So, if I use plug-in A in Intro, and then Chorus needs plug-in B replacing A, and I delete A in Chorus to assign B, then A is replaced by B also in Intro. What I can do is create A and B both in Intro, and mute one or the other according to the different Parts. But this adds up to quite a lot of plug-in instances in a whole set list. I don’t believe this is correct, but so far I haven’t been able to do it, besides having to check a whole lot of State Behavior boxes.
Are you suggesting that you want to introduce plugins via states as opposed to just turning them on/off or routing to them?
So, if I use plug-in A in Intro, and then Chorus needs plug-in B replacing A, and I delete A in Chorus to assign B, then A is replaced by B also in Intro
Regarding this, you can’t have a plugin exist for just one state. What you can do is mute per state or deactivate routes per state.
When you select various things in cantabile (rack, plugin, route) you can alter the state behaviours, it sounds like something with those needs changing.
If you can share a state or song file perhaps someone can take a look.
Okay, this is probably what I presume wrong. So states, whether rack or song parts, always remain the same? And in following parts I can only turn the individual plug-ins on/off or route them to another controller? I can’t use a State/Part 1 with one key range and State/Part 2 with a different key range, but I have to call up a second instance of the plug-in and give it the range I need. Is this correct? So also, if I need plug-in A in Verse and plug-in B in Chorus, I can’t simply delete the plug-in I don’t need in Chorus, but I have to call up a separate instance. And in the Behaviours checklist, I should actually uncheck elements so they don’t get carried over to the next State/Part. Is this correct? But supposing you’re working on a rather complex piece, with several sounds and keyboard splits, wouldn’t it get filled with plug-ins pretty quickly? Would they be loaded in memory only once, or every time for every single one? This doesn’t sound right to me. Thanks again.
This is why songs exist. You can have entirely independent setups and access them via a set list. You can preload a set list into ram so there’s no loading time.
Within songs, you have states. States allow the plugins within a song to be configured creatively, with routing, splits, patches and much more to be arranged according to the user’s requirements.
You certainly need to develop strategies for seamless transition but I think you’re worrying a little too much about having a lot of plugins within one song. Cantabile is capable of targeting the demand where needed, and it’s highly unlikely that one song will exhaust your requirements.
That’s why even modest computers are able to achieve excellent results.
I think we need to clarify this question.
I think you are saying:
- I have a song.
- I have two states within that song which need to address a plugin with different key ranges.
This is entirely possible with only one instantiation of the plugin.
The only reason for requiring a second instantiation would be if you required different patches to play simultaneously AND the plug was not capable of multi-timbral performance.
Which plugins specifically are you working with?
Thanks all for your help. After rereading and reworking on my files, I think I get it now, so tell me if I have it right: a song can have as many or as little plug-ins as needed, and plug-ins can be inserted or deleted at will, but a state (song or rack) must contain all the plug-ins that are needed through the whole set of states, and states only allow for suspending or activating them. So if my State 1 needs only one plug-in, but my State 8 needs 10 plug-ins, all of those plug-ins must also be present in State 1, except nine of them will be suspended. Same applies to the different song states, so if I need one more non-rack plug-in for song state 1, and three more for song state 3, all of them must be in song state 1. Is this correct?
For the different octaves and key splits, I think I’ve solved the problem using different MIDI routes (for the same keyboard) with individual octave and key range values, which I enable or disable depending on the state.
Thanks again.
I think you got it 
Think of it that way: a SONG is a collection of plugins, racks, and routes that connect everything. Create a song to have all the instruments and effects together that you may need over the course of a song. Like putting together a physical rig for a live gig - put everything on stage and wire it up.
Now STATES are different configurations of these components - just imagine having your personal stage technician who will switch your individual devices in your live rig on or off, select different presets and connect and disconnect some cables. All that switching can be done per song state, so you have your little stage tech jumping into action every time you change state. But the one thing your technician CAN’T do is bring new instruments, effects or cables onto the stage during the course of a song…
The key reason for this logic in Cantabile is that loading new plugins and re-configuring all the routing between them can create pretty high load on a PC system and disruptions in your audio stream processing. This can create severe “hiccups” in the audio stream - clicks and dropouts - and make the system a bit sluggish overall. This is not something you want to happen while you are playing a song - you need to get that stuff out of the way before you hit your first note. So when you load a song, Cantabile needs a bit of time and energy to set everything up to get you rolling through the song without interruptions. Changing states is typically far less taxing on the system, and a lot more predictable for Cantabile’s audio and MIDI processing sequence to make sure all audio gets processed without interruption and that all MIDI notes get cleanly processed even through state changes, without any “hanging notes”
So I would word it differently: a STATE doesn’t contain anything - the SONG or RACK contains all the components that you need: instruments, effects and routes; a STATE is only a different configuration of these components (an instruction sheet for your little virtual stage tech).
Maybe this makes things a bit easier to handle…
Cheers,
Torsten
That’s a great analogy.
Thank you Torsten, that was very helpful. I think I get it now, but the concept of states was probably my biggest obstacle, and especially the difference between song and rack state. I believe now my mistake was not correctly separating between the two, so without realizing it, I was editing a new song (or song state), but with a previous rack state. So I changed to say, song 5, and expected rack state 5, while in fact it was still rack state 2. Things seem much smoother now that I’m paying attention to the two different things.