That does help… so one way to go would then be setting up maybe a few racks, “Pads, Pianos, Synths” and put my favorites in there. Then still save songs that utilize those 3 racks. Downside is if I remove a pad and replace it with another the song may not reference the previous pad… or does it just reference a slot in the rack? Not too big of a deal overall but could be relevant especially with things like synths where there are more variations. Or if I replaced a piano with an EP in a rack.
Suggest you take a look at @Derek Cook’s Cantabile guide. From the Cantabile web site, find Support. It’s under support.
Pro-tips: 1) Racks give you the advantage of pre-loading samples and VSTs. 2) If you transpose a lot, use the Routes in your Songs to do the transpose operation. Don’t do it in the Racks. Think of the Racks as Instruments. The Rack States are re-usable Patch Settings. Never delete one–it might be needed somewhere else. Instead, create a new one. The amount of disk space or memory used is minuscule compared to a sampled instrument.
2 Likes
I will check it out, thanks!
No, you are correct in the first instance, any pads you chose would need to stay in the same slots in the Kontakt Rack to preserve any previous song associations.
Yes, you shouldn’t do that. Once you use a rack preset in any song, don’t remove it! If you change it, it will change in all your songs. This can also be positive, when fine-tuning individual sounds - but you should be very much aware that your changes apply to all songs. Another example: moving to a newer version of a plugin. When Pianoteq came out with version 6, I simply modified my “Pianoteq” rack - and all my songs used P6 without any further adaptation.
As @RackedBrain wrote, think of your racks as “preset synths” - you build presets (=rack states) and use them across your songs. And I also fully agree with Richard: the song level is where you build your routing, zones, MIDI filtering and so on. You just construct a song-specific configuration out of your re-usable building-blocks (racks) by threading them together with routes.
The big advantage of using racks is that they only get loaded once in re-loaded setlists. If you put the same plugin directly in 20 songs, it will be loaded in 20 separate instances when pre-loading a setlist. If you embed it into a rack, it will only get loaded once. So once your songs and setlists get bigger and more complex, racks are the only real way to go if you don’t want to swamp your machine in plugin instances.
The only thing I would embed directly in songs are media players - they’re far easier to manage at song level than hiding them in a rack.
BTW: I even encapsulate inputs and outputs in racks - makes it easier to route more complex configs. See this post: Introducing Routing Diagrams - #6 by Torsten
Cheers,
Torsten
2 Likes
Thanks, @Torsten! I will totally check out your post. I was thinking, too bad there are only 16 MIDI channels, which kind of limits my rack to 16 instruments (i.e. a favorite Synth Rack). But just remembered, I can have multiple favorite racks as they take so little space. 
It feels like I’m just barely scratching the surface of this app, and that’s a cool thing.
Not really - you can use rack states and state-dependent routes to address any combination of instruments within a rack, invisible to the outside. So, preset 1 might play Diva, preset 2 Repro-5, and preset 3 even a combination of both…
But TBH, I’ve moved away from “fat racks” and moved to very lean “single-synth”-racks mostly and do the combining, stacking and mixing at song level. So most of my racks these days consist of a single instrument plugin plus an EQ. Some are a bit more extensive, e.g. an epiano rack with some pedals (phaser, chorus) and an amp sim integrated or a guitar amp rack with a couple of pedals thrown in, but most of them are single-instrument.
I also have multiple racks of the same instrument so I can combine them in songs, e.g. M1-strings, M1-solo, m1-polysynth, or multiple instances of VB-3 (one to layer with my main piano sound, another for soloing).
Have fun and explore!
Cheers,
Torsten
2 Likes
16 channels was never a limitation, even in the hardware days. You simply used a multi-port MIDI interface. I’m up to 32 ports (4 x 8-in/out interfaces) in the studio - not with 16 channels used on any of the ports, I hasten to add! When you have multi-timbral instruments it’s wise to give each their own MIDI port to avoid clashes and simplify layering
Thanks for the input! I guess my primary reason for using racks was not to necessarily have more than 16 instruments live in one song but to collect my favorites in racks so I don’t have to keep notes as to which of the 10,000 instruments I really like most. So in that vein, I just have to make more racks when I have more than 16 favorite synths, for example, which of course isn’t a problem.
Maybe the other way to handle “favorites” is to make a thin rack (i.e. 1 instrument, Komplete Kontrol for example) and load in my custom patch bank (by Cantabile) with my favorites in there. Choices.
Hmm, @Torsten… Liking that idea of the one rack per instrument. I don’t use any effects currently in worship sets and really need to start. I mean, nothing other than whatever’s built-in to each instrument, which is either nothing or basic.
So in this case I’d save the racks out to files in folders (i.e. \Synths, \Pads, etc.). And the instrument in each rack could be a Cantabile patch bank that I’ve saved of my favorite patches. For example I could have a Favorite Pads patch bank for Komplete Kontrol. Then I create a new rack, add KK instrument, import Favorite Pads patch bank, choose say Patch #2 “Matrix Pad”, add effects if I want and save and export that rack as “\Pads\Matrix Pad.cantabileRack”.
This would then probably get me the most flexibility:
- I’d have favorite instruments organized in folders ready to import.
- I’d be able to, in a practice session, easily choose from other favorites within the VST by using the imported patch bank if desired.
- Each rack would be simple to work with and have the effects I’ve found most desirable.
So that leaves an interesting suggestion… It would be neat to have persistent, global racks and patch banks so I wouldn’t have to always export and import every time I added new favorites. You could still import if you wanted the song to stay independent of any global changes as it is today or you could choose from your persistent resources that are centralized.
… or at very least, a “rack chooser” with a “preview” function. So before importing a rack that has one instrument we could click “preview” and it would be a short MP3 file we’ve saved so it helps us remember what that instrument and effects sounded like. Kinda like what NI does with their previews for instruments.
That’s what linked racks are - they are global across all your songs; any changes to them will affect all songs that use them; any patch that you add to it as a rack state will be available to all songs.
If you want to customize such a rack, you can easily convert it to an embedded rack in a song file and edit it for the specific song only without any effect on the global rack. But beware: such embedded racks will be a separate instance and consume memory for every instance when pre-loading.
One suggestion for live use: try to keep your setup of “favorite” racks to a pragmatic minimum of proven workhorses that are easy on CPU and RAM and are “good enough” for live use. From a performance and stability perspective, that’s the ticket to smooth and trouble-free operation. You wouldn’t drag 20-30 hardware synths on tour with you, would you (unless you’re Jean-Michel Jarre…)?
Cheers,
Torsten
2 Likes
What @Torsten said.
And don’t try to “boil the ocean”. Setup Racks with a few presets you know you will use. Let them grow organically. Otherwise, you’ll define 200 presets and want to change everything in your implementation. After a few weeks working with Cantabile, you will have the “ah-HA moment” and want to change everything. Be advised this may happen more than once. 
2 Likes
+1 RackedBrain.
If I knew then what I know now!
2 Likes
Yep, that’s why I started this conversation… Didn’t want to set things up in a way that seemed right to me but then found out later things that you vets learned long ago.
OK, as to linked racks… I get that they are persistent across songs in a set list. But are they persistent across set lists without constantly exporting them to update them with changes I’ve made? So for example I make a set list for April 14, import linked “Pad Rack” and use instruments in that song. Then I make a set list April 21, import linked “Pad Rack” and decide to add a new instrument to that rack. If I go back and open April 14’s set list and open a song with Pad Rack will it have that new instrument or would I have to first export the changes I made in the April 21 set list?
Yes it will have the changes, the set lists don’t include those changes. Changes and additions to linked racks will show up on older set lists. So no exporting.
Dave
1 Like
Just to be precise on terminology and functionality
Linked racks are simply files very much like song files - they contain references to plugins (not the plugins themselves), plus the “memory blob” of these plugins, including Cantabile’s plugin presets. and of course the routing and plumbing to connect everything.
Linked racks are again referenced in songs: the content of these racks is not stored with the song, but just a reference of the rack used and its rack state and some other parameters. A linked rack is NOT imported in a song (unless you convert it to an embedded rack); when you add a linked rack, it stays its own self-contained file. This also means you must save changes to the rack when you make some.
Racks are also never used in a set list directly - a set list contains SONGS, that again use plugins and racks. A set list is also just a set of references to song files; the song files aren’t contained in the set list file. So if a song is part of several set lists, any change you make to the song is part of the song file; these changes will then apply to the song in all set lists that use the song.
Hope this makes things somewhat clearer.
Just one recommendation: if you are really a newbie to Cantabile, I’d suggest you start small and simple and work your way up to the more complex setups. Currently, it looks like you’re jumping directly into the deep end of the pool without a full understanding of the complexity behind Cantabile - there may be a whole lot of potential confusion and frustration on that route. I can only echo @RackedBrain’s words - don’t try to boil the ocean in your first week…
Cheers,
Torsten
2 Likes
It is on these fora that I learned the trick of creating racks for incoming keyboards that split off the incoming messages into notes, sustain, modulation, pitch-bend, controllers, etc. Using this method you can assign anything to anything, and give yourself ultimate flexibility - like not having to worry which keyboard a sustain pedal is physically attached to, for example.
If there’s one thing I wish I’d understood right from the start it is this. The guys here have been over it several times, so try a search or three. If you can get your head around this it will save you lots of pain in future!
The other trick is to use Symbolic Links to allow you to use a rack multiple times within a song. Another life-saver.
I’m certain there will be other tricks I’ve not yet come across, but these specific examples turned Cantabile from being a mountain to climb to being a Sherpa to carry the weight!
1 Like