I love all the options in Cantabile and that there are often multiple ways to do one thing depending on preference, situation, rapid-load need, etc. I also love the idea of creating my own patch banks so, for example, creating a “Kontakt Pad Bank” of my favorite Kontact pads regardless of coming from NI or other resources. But then started wondering about the best way to do this for worship songs…
Is it better to create songs and have the particular instruments I regularly use for that song embedded? I like that idea as I also transpose a lot so all these settings could be kept per song. And even save multiple versions in different keys if I like.
Racks are fascinating and more cross-song useful it seems; so maybe I create a few racks of my favorite pads and other instruments, then create songs that reference those few racks.
Or should I create instrument banks, then when using the song I load up a bank and choose my favorite instrument from there and save the song? I guess that’s probably similar to #1 above. If so, this doesn’t appear to pre-load all the instruments in the bank, which is smart and I don’t want that anyway, but maybe allows me to more easily switch to another instrument more quickly in practice instead of rooting through thousands of instruments on the fly.
Sort of thinking out loud here, but if any of you seasoned folks want to lend some advice I’m all ears.
Different Vst Instruments behave differently and Multi channel, Multi timbral Sample based players like Kontakt present a unique type. Since you intend to use racks across multiple songs in a song list you will likely end up pre-loading memory as well to save memory space and enable faster switching between your Kontakt patches so inside your Kontakt pad rack I would set up your Kontakt vst with a multi-patch and with a different pad sound sample in each slot and with each slot set to different MIDI channels 1 up to 16 if needed. Then Cantabile can just use MIDI channels on it’s input routes to access the pad patches and they will be loaded and ready when called. A Song will generally end up consisting of these input routing configurations to the Kontakt plugin you have inside your “linked” Rack. Omnisphere acts well this way too if you have a lot of reusable tones. Hope this helps …
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.
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.
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.
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).
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…)?
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.
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.
It feels like I’m just barely scratching the surface of this app, and that’s a cool thing.