Working with existing racks >>> identify not used parts of a rack in a song

1

Hello,

so far I have a lot of different (existing) racks.

In my songs, where I use e.g. 10 different racks with in total around 100 rack states behind, I don’t
use each rack state/each VST instance behind.
The not used rack states/VST instances causes unnecessary RAM/disk space by preloading a song.

My idea:

  1. Identify all not used rackstates per rack in actual song
  2. Store relevant racks under a different name (e.g. actual song name + e.g. Nexus Pads)
  3. delete not used rack states and VSTi instances behind

leads to faster preloading of songs and gains RAM/disk space

Is that possible?
How can I identify by e.g. a mark/flag, which rack states/VSTi instances are used or not used
in the actual song?

2

I suspect that all of this information could be gleaned from Song and Rack JSON files. Parsing them with, e.g. Python and producing reports could be a worthwhile challenge.

3

Yes, this is something I’ve been meaning to do for ages, as I inherited a load of my racks from the import process from Cantabile v2, which left a load of redundant states everywhere. It should be possible to write a script to parse the JSON files, as @RackedBrain suggests.

However, I’m not sure whether it would make any noticeable impact on RAM/disk space or load time. I think the overhead of having extra states in a rack is pretty minimal compared to the time taken to load the actual plugins.

4

Hello @RackedBrain, Hello @Neil_Durant

Thanks for the quick response!

I’m not really familar in working with Json files and/or Python.
I assume, that the JSON files would only shown the used rack states/instances and not the unused, or?

@Neil_Durant
I’m sure in my case, that I would need less RAM/disk space on preloading.
My Racks are e.g. builded for each VST software synthie. They includes always all of the “best of” performances/patches of each VST. Nexus has e.g. in total around 200 “best of” patches. I already splitted the racks deeper by genres to have a good overview: e.g. one rack = “Nexus Complex PADs”, second rack
“Nexus Arps”…and so on.
Cause I combine several racks in songs, I have a “huge amount” to load one song :wink:
One of my songs contains therefore around 12 racks with in toal 425 rack instances.
This works :slight_smile: Loading time is around 5-10 minutes and RAM is up to 32GB…also works :slight_smile:
(do not worry: not all my songs a so big :-)).
In my actual song build I assume, that on the end only 50 rack instances in total are used (out of 425).

I don’t want to destroy my rack structure. The workflow to build a song crossover with my “best of” racks
is very fast and very flexible.

So a “minimal” solution to see in the rack view, which instances are not used in the actual song
would be great.
I have no idea, how to write (or use) scripts so far.

5

Two possible good things could happen: 1) Somebody that’s a pretty good coder could get interested and make time, or 2) Python is an excellent first programming language to learn. If you use any old text editor (Notepad++ is a fav) and look at a JSON file, you’ll be surprised at how easy it is to understand.

6

Why is the number of rack states relevant though? If you have a rack with one plugin in it, it’ll only ever have one VST instance, regardless of how many rack states you have.

Do you have racks containing loads of VSTs, where different states enable or disable different VSTs ?

Neil

7

Not sure I really understand you: are you using a separate instance of a plugin for each preset? :scream:

My songs usually contain 10-20 racks, but any single rack will only contain 1-5 plugins.

Usually, it’s a synth/sampler plugin with some effects (one EQ minimum) chained after them. Rack states either switch presets on the synth plugins or (where the preset system is too convoluted) simply use the “full bank” state behavior (and for some, “full bank” and “selected preset” is necessary).

Some other racks are simply effects used across multiple synths (e.g. “main reverb”, “solo reverb”, “main delay”, etc.) or abstractions for my input devices (e.g. a “main keyboard” rack with separate MIDI outputs for notes, modulation, pitch bend, and aftertouch - makes it easy to route layers or splits).

My whole preloaded set list for my more complex band is around 120 plugin instances - and no way I need 5-10 mins to load it.

I suspect there is a simpler way to achieve what you are trying to do - maybe you can share some screen shots of your typical songs and racks?

Cheers,

Torsten

1 Like
8

Hello @Neil_Durant, Hello @Torsten,

thanks for the discussion, your thoughts.

Indeed my racks depends on several instances of ONE and the same VSTi.
I’m a real fan of the preloading function in P3 in order to switch fast through different song states.

You both are right: if I wouldn’t preload I only need only one and the same VSTi e.g. Omnisphere and
would work only with rack states instead of preloaded rack instances.
With e.g. Omnisphere and Nexus the loading times are sometimes acceptable. Depends of the
patches and samples behind.
The loading times of e.g. Kontakt orchestra libraries are for me quiet too long in switching from
one performance to another.

I guess, my general workflow in working with P3 is complete different from other P3 users
I get inspired to improvise, produce a song by using for a song not only the e.g. 5 VSTi. That would be
the right way, if I indeed would only play one song.
But I like the huge flexibility of Cantabile Performer to have fast access to my flexible fast combineable
VSTi.
I only distinguish songs by genre like Chill, New Age, Soul/Funk, Orchestra/Soundtrack.
Behind all these genres I have the before describted rack organisation.
The main advantage for me: never search/think about, where are my performances I need in the moment :wink:

9

Surely the more efficient way would be to have more racks, each with one instrument VST, so Cantabile only ever loads the ones it needs for the setlist you’re playing? Otherwise you’re guaranteeing times when Cantabile will load plugins it doesn’t need. The solution is to let Cantabile manage it, by splitting up into more separate racks, rather than identifying unused bits of these mega-racks.

Like @Torsten, many of my songs involve 20+ racks, including many sample-heavy plugins etc, and for a typical 2 live hour set it comes to about 120-130 plugin instances, and it all loads in under a minute (from SSD).

Neil

10

Hey @Neil_Durant,

this is exactly I try to achive on the end what you described.
I guess the difference in our workflows is, that I always start with…I name it something like “general ready start or basis racks”…
These racks includes all best of patches by genre per VSTi.
Then I build a new song or a new rack, I don’t want start again and again from the scratch and searching
patches within the VSTi itselves. The hard work is already done to have a structure via finished racks.

I guess, I have to solve my topic manually:

  • open song
  • rename the racks for individual song use
  • go through each song state
  • look, which rack instance is used and mark each used in the text with a e.g. “*”
  • delete all rack instances without “*”

finish :slight_smile:

11

But if you rename racks for individual song use, you won’t be benefiting from Cantabile’s ability to intelligently re-use racks across songs in a set (thus saving RAM and load time).

It seems like an odd way to go about creating songs - start with one with everything in it, then find a way to remove everything you don’t need. Why not just design some really useful, re-usable racks containing only one instrument VST each, and some really useful rack states in those racks. Then song creation is just a matter of throwing in the racks you know you need, and you’ll then always have the most minimal, lightweight songs possible.

I second @Torsten’s suggestion to post some screenshots of the inside of some of your racks, so we can get an idea what you’re doing. Because it really sounds like you’re making life unnecessarily difficult for yourself.

Neil

12

@Neil_Durant

Thanks for you input.

Ok, perhaps I have to rethink, if I going to use “deeper/sub” genres for my rack organization in order
to decrease the no. of rack instances per rack.

Might be indeed a good idea, to show via screenshots how I use racks.

13

This sub-genres thing is the bit I’m puzzled about. Are you saying you have, for example, a Nexus rack, and inside that you have multiple embedded racks for “Nexus Complex PADs”, “Nexus Arps” etc?

If that’s the case, why? Why not get rid of the embedded sub-racks, and have a single Nexus rack, and separate its rack states by genre? For example, rack states 0-99 complex pads, 100-199 arps etc. You could add a “dummy” song state in there named “==ARPS==” etc., to keep them visually separate and name each block of states.

Or alternatively have different top-level racks, one for Nexus Arps, one for Nexus Complex Pads, etc. Then just add whichever one(s) you need to a song. That would also make it easier to run several in parallel if you needed to.

Neil

14

This is what I do with a number of Korg M1 racks: M1 strings, M1 synth sounds, M1 solo sounds. Each of them has a different bank loaded (but just one instance of M1). Then different rack states simply change a preset within the specific M1 instance.

I understand that this is more difficult with sample-based sound engines, especially big Kontakt libraries. For these, I tend to have specific racks that have ONE sample set loaded (e.g. session brass) and keep it loaded all the time. Different rack states may then change the processing AFTER Kontakt (e.g. different EQ settings or modulation effects after Kontakt), but the core Kontakt patch never changes. But having a lot of these sounds means a lot of pre-loaded Kontakt instances and a lot of sample RAM - I try to have very few of these large sample libraries, if any. There are a ton of non-sample-based synths that provide presets for all kinds of genres with very short switching times.

Of course, for orchestral libraries, it’s difficult to live without samples - but for live use, there are a number of smaller-footprint alternatives to big Kontakt libraries. It’s worth looking at the SRX Orchestra plug from Roland - pretty lean, instant preset switching, and a lot of orchestral flavors.

Cheers,

Torsten

15

Hi @Neil_Durant , Hi @Torsten

Yes, I organized it like in the way you both do.
Also having the Korg M1 VST.
Have 1 rack M1 Pianos
1 rack M1 Epianos
1 rack M1 Pads
and so on.
Or I structured racks like Jarre Pads, Jarre Arpeggios, Vangelis Pads, Yello Arpeggios and so on.
These both structure types makes it very easy for me, to find something fast.

My “problem” is: I don’t know before I create a new song/song state, what I would combine…it’s more like a “try on error” thing in order get the best combination of VST.
Here Cantabile is for me still outstanding as solution to have this fast working flexibility.

@Neil_Durant
I have also e.g. a Nexus rack, which is structured as you describted. Within these Nexus rack the rack states I use text/names whichs start with a shortname of the genre.

@Torsten
Yes, you’re on the sample base sound engines. Perhaps I have to rethink, how and then using preloading.
Today I love it pretty much to switch through all my song states with one click in order to play direct and not wait a moment :slight_smile:
Has the SRX Orchestra of Roland string runs, arpeggios included like e.g. from Best Service “The Orchestra”? This library is ready to play for e.g. ready soundscores/soundtracks.

16

In Cantabile 2, I used to have a “monster rack” with all possible instruments in it and with scenes/states for songs or song parts. With Cantabile 3, I have completely changed my approach: I usually have a basic starter template, which for me consists of a piano with an optional string layer on the lower keybard and an organ VSTi on the upper keyboard. It also includes all my basic routing, abstracted keyboards, pedals, master volume and effect racks, so that I can immediately start playing and editing.

Based on this song template, I can easily add other racks or replace the existing ones - building a song of standard complexity takes no more than a minute. It takes a bit more time when I need complex layers or multiple states with different instruments active or controller fades between states.

In addition to this, I have a “universal” song, which allows me to switch quickly between a basic set of bread&butter patches (10 for my upper keys, 10 for my lower keys, 8 guitar patches and 3 VoiceLive presets). This is great for rehearsals when trying out new songs without having to prepare Cantabile songs in advance. Given that I want to switch sounds independently for three separate playing sources (keys upper / lower, guitar), this song file is a bit complex, with a lot of Cantabile rack and route trickery (can’t use states, since these switch complete configuration, and not configuration of a subset).

So, usually, I start exploring a song in my “universal” configuration and then, once I’ve got my head around it, I build a dedicated Cantabile setup, based on my basic template, adding my instrument racks to taste, creating states for song segments where needed and fine-tuning the setup. My goal then is to have full “automation” of the configuration: load a song and start playing, using only my “red button” to step through states, with only very few faders for real-time adjustments (e.g. adjust solo volume when needed…)

One thing I’ve learned in my time with Cantabile: working with VSTi live is a different beast than working with them in a production environment. For a live setup, it pays to concentrate on a set of key instruments with a low CPU and RAM footprint for bread & butter. I certainly have a ton of synth plugins that I use in production, but for my live setups, I use only one or two virtual analogs, 2-3 “rompler-based” synths like M1 or Xpand (currently testing the Roland JV1080). In this space, mostly “good enough is good enough” for live - no need to manage a zoo of plugins for the last 5% of sound. I only use larger sample libraries for the few sounds I just can’t live without, which is mainly piano and a bit of brass. For the rest, I usually trade the last 5% of sound for CPU and RAM efficiency.

This has made my setup pretty lean and mean and fast-loading; plus, Cantabile thanks me with pretty much flawless stability…

Cheers,

Torsten

4 Likes
17

@Torsten

Thank you very much for the deep dive into your configuration and workflow!
Sounds very interesting.
While reading I thought sometimes “yes, some of that I do in that way”.
But, perhaps not really :slight_smile:

If I have more time, I come up with some screenshots (as you suggested) and
try to show a small “photo story” of the workflow.
I guess it’s easier to find/identify room for improvements.

Interesting is your point in different use of your VST live sets and production envoirement.
I’m not really a live player…more improvise and sometimes production…but…production in my
case is also more improvising while recording :slight_smile:

1 Like
18

Back again. Happy new year! :slight_smile:

Based on your information/tipps I reorganized (again) my racks and left the workflow with
preloading everything then open a song.
On the end the actual workflow is the worklow as I started with CP 3, BUT different in using the preloading
function.
So I have again racks, where I only preload one VST and change presets/patches within the VST by using the rack states.
In order to use the preload function for fluid switching from one preset/patch to an other, I load one and the
same rack 3 times in a song.
On each rack state it loads at the same time

  1. the next rackstate in background (muted)
  2. the previous rackstate in background (muted)
  3. the actual rackstate to play (coming either from 1. or 2.)
    So, if I switch forwards or backwards through my rackstates the patch/preset is already preloaded and
    ready to play.

Therefore I don’t have to identify not used VST instances, which causes RAM space.
And the preloading with “a lot of VST” per song is mostly less than 1 minute.

2 Likes