After reading the section on the lifetime of racks, I’m still a little confused as to what is the most efficient way to organise sounds / songs / racks.
There’s a couple of different ways of doing this and it really depends on which way best suits your work flow. ie: it’s a personal preference more than anything. You could either:
Put all the plugins in a rack and use states to manipulate the routing between them.
Put each plugin in a separate rack and wire the racks together from the parent song in different configurations for each song.
Put each plugin in a separate rack and use multiple states on the parent song to configure different connections between. You’d do this when you have different parts of the song needing different effects for example.
Put the primary plugin in one rack and all the effects in a separate rack with states to switch between the different effects.
There’s probably other ways as well. The key point is that if you use Preloaded Set Lists, whichever way you configure it all the racks and all the states will be loaded and ready to go. If you really want to streamline the switching then focus on switching routes in preference to switching presets (unless your plugin is fast to switch anyway).
For me, the question is, what do I consider an “instrument” - is it the rhodes by itself or are the effects (flanger, phaser, chorus) an integral part of its sound?
I try to keep racks as self-contained as possible, so that by choosing a rack state, I get a fully rounded sound. Then I combine racks within a song for individual song parts, including splitting or layering multiple sounds from different racks. The only effects I add at song level are “mixing” effects - mostly reverbs.
So, my ePianoRack contains two EP plugins (Pianoteq and LoungeLizard), plus a number of effects like phaser, chorus, delay, distortion, delay, even a separate reverb (where reverb is an integral part of the sound). Within this rack, I create my E-Piano sound from these components in a state and give it a name (Dreamy Rhodes, Tramp Wurly, …). From my song, I only pick the right EP sound for the song; when I need a new one, I create it within the rack.
Think of a rack as a preset sound module - you put everything into it that you need to create a certain category of sound. I have a number of racks, each focused on a specific task or sound category: piano rack, e-piano rack, string layer rack, hammond rack, main synth rack, lead synth rack, … Every rack contains what it needs to create the specific sound, including effects.
Let me take this a little further down the technical line. So If I set up a (for our example) an Electric Piano rack as Torsten suggested, and manipulate it entirely with states in multiple songs… is that rack really only loaded once in memory?
This is, in reality, the end game I am pursuing. How can I load the most unique sounds with the least overhead… if that makes sense.
However, if you change patches in your plugin in a rack, that might incur the loading of new samples (depends on the plugin, some do, some don’t). If you really want to avoid sample loading, a good way to do it is have multiple instances of the plugin inside the rack, each loaded just with specific samples, and select the sounds by switching MIDI routes by rack state.
And most important, what is the fastest way to switch? I noticed that between states I have a second or so, which is pretty slow in songs when you have to switch on the beat.
Only thing I do is un/suspend plugins in a next state.
Is this the fastest way to switch?
Why do you suspend/unsuspend plugins in states? That is quick, but it’s not immediate. It also means held notes or reverb/envelope tails are cut when you switch to a state in which the current plugin is suspended.
The best way to switch sounds is to switch the MIDI routes going to the rack/plugins, and to leave your racks/plugins enabled throughout your song. You can do this either by:
Having a set of MIDI routes to your plugins which you enable/disable for different states
Re-using MIDI routes by changing the target rack/plugin on the routes
If you do this, you can make super-slick glitch-free sound changes between eighth notes easily, and Cantabile is clever enough to allow you to hold notes/chords over the change (by holding the notes or sustain pedal), and only when you play new notes will the new sounds come out.
No, the fastest way to switch is to have all sounds for your song and all it’s states loaded in advance and then use the midi route muting to turn on and off the connections to the different plugins. If you have to re-enable and shut off plugs it takes more time.plugs it takes more time.
Yes, Solo will work too. But it might be more complicated that way if you have multiple controller keyboards or multiple zones that you want to target to different plugins - you’d still need to have routing changes. But for simpler songs/setups, maybe Solo is the best way - good idea!
Also, note that Solo will only mute the output routes of the plugins. So if you have a keyboard mapped to bunch of synths and using Solo to switch between them, they’ll all be processing incoming notes which are then muted. Switching MIDI routes is the best way to switch sounds.
Also note you don’t need to enable/disable multiple routes. You can have one route and change its target in different states.
Ah i used solo because the routing trick didn’t work with a linked rack because the preset it’s the same in for example all 3 of them (song with 3 different guitar sounds). So i used an embeded rack and solo. Because the disable function didn’t work.
Ofcourse i could have used the routing!
But then you don’t have a visual warning what’s going on. And i know myself
@brad, for a visual indication, how about if racks/plugin rows are visually dimmed if there’s no active route to them ultimately connected to a MIDI input? Of course, filters/zones might mean a rack/plugin is not playable, even though it has a route to it, and conversely a rack/plugin without a route could still be made to play using a note binding. But for the standard case, I think this could be a really useful visual indication of what’s going on.
On the route, yes - I was thinking about visual indication on the target rack/plugin itself, rather than the route. That way, at a glance you’d be able to see which racks/plugins are currently “live”, without needing to look at the target names on the enabled routes.
