All plugins in global rackspace

I wanted to tackle the problem that it took around 5 minutes to load a gig file, having around 40 rackspaces with 2-20 plugins per rackspace.
Another reason is that I reach the limit of my RAM memory.

To prevent this, I decided to put all (especially instrument) plugins into the global rackspace, and use the Gig Performer presets to switch. This reduced the time to load to about 1 minute, and it doesn’t matter if I use now 40 or 80 rackspaces (so I use the songs of both bands I play in, in one gig file).

I counted the plugins I used for ALL songs I used, and it turned out to be like around 8 Kontakt7 instances, a few Kontakt6, FM8, some Massive and MassiveX, a few Vital, Pneuma/Pro and some more, in total around 40 plugin instances.

So I had to find a way how to get MIDI data from the local rackspace, routing it to global, and back to local to add effects and mixing them.

I succeeded, however, there is one main disadvantage: Patch Persist does NOT work anymore (using my script) as loading the presets will temporarily disturb the sound, having them reused between songs. Switching songs take about 1-3 seconds.

I can write/show more, so if you like I can spend an article on it … it uses the new MIDI Rechannelizer in a nice way, and uses scripting heavily.

I did not add the gig file as it is using only commercial plugins, and also it contains unrelated things like controlling lights via my keyboard, changing songs by +5/-5 and some other small goodies.

It’s not “anymore”, it never worked for that scenario and it can’t work for that scenario. The mechanism depends on keeping two rackspaces (the old and new) active at the same time.

Indeed … what I meant by changing from the ‘normal’ way to using loading presets via Gig Performer, so since I use my new script it does not work anymore (not because of GP 5 vs GP 4 for example). I can imagine for some people it’s a no-go to lose patch persist.

Because I am curious:
You built your gig using the global rackspace because of loading time?

Curiousity is always good … and I added a second reason too, RAM memory is getting to the limits. But loading time also was one … GP never crashed so far, but still.

How much RAM is available on your system?

I have 32 GB, with the new script using 11 GB (including QLC+), before without QLC+ around 29-30 GB.

OK, and the CPU usage in using all plugins in global rackspace is the same as using separate rackspaces?

Yes, because I’m reusing the plugins between the songs.

E.g. In song 1 I use e.g. 2 Kontakt7 instances and 1 Hammond instance, and in song 2 I (re)use those same 1 Kontakt7 instance and a MassiveX instance etc. For that I need only 2 Kontakt7 instances, 1 Hammond instance and 1 Massive instance. With 40 or 80 songs, you can imagine this saves a lot of plugin (instances). And they only need to be loaded once (loading the presets of course need to be done per song).

I do not understand
Some songs are not using MassiveX, right?
Others do to use Hammond instance.
But they all are active, right?

How can CPU usage be the same?

Do you bypass not needed plugins ?

Yes, the script reads a file with some configuration settings (names of the presets and instances, and some routing info), then it bypasses all instances which are unused.
(Actually, it starts bypassing everything, and while parsing the current song, it un-bypassing the used plugins).

Why does this work better than simply creating rackspaces for each song (say)?

Because if I have e.g. 10 plugins per rackspace (40) it will be 400 plugins to be loaded.

Yeah, that’s probably similar to what I have.

About a year or so ago I threw out the idea of “freezing” a plugin (especially sample-based) so it could be used in multiple rackspaces without requiring more ram for each use.

I then learned about the Global Rackspace and figured it was functionally very similar.

But, I still sort of think that idea had some merit. (Of course, it is easy for me to throw out suggestions without appreciating how different changes affect different things. I have no doubt it can get complicated very fast. And stability is probably always a first priority).

1 Like

It is a bit complicated, but I will later today or tomorrow write more about how I tackled this.

My suggestion was more directed toward the GP Developers. (But, I am certainly interested in whatever you having cooking. :))

1 Like

Since there are several people interested, I include the gig file and some explanation as the routing is not so trivial at first.
Band1x.zip (6.7 MB)

Note that I did not include the necessary GP Preset files and the scripts and wiring is work in progress.

Below is a rough explanation:

First a text file is read (called songs.txt), containing the configuration for each song, below is a fragment for one song shown:

How Did You Love
 | 1:HA:1, 3:K7/Grandeur:19, 5:SU/Surge Synth 1:9, 7:PN/Pneuma Synth 1:7, 13:PH/Choir:25
 | Light = Mood:Uptempo

This means that MIDI Channel 1 will be used for HA(mmond), using the preset name ‘How Did You Love’, which end up at audio channel 1 (for Left and 2 for Right), then MIDI Channel 3 is for for Kontakt 7’s with GP Preset Grandeur, output to 19/20, then MIDI Channel 5 Surge using GP Preset Surge Synth, etc.

Below is the full songs.txt file:

Songs.txt (9.0 KB)

Below is the local rackspace for one song shown … The global rackspace has a Hammond section which will automatically be enabled (shown) when a Hammond is used.
Also there are some generic buttons and some light panel using for the light (DMX) system (work in progress).

The next picture shows the local rackspace wiring. Here things are getting interested.
First, the MIDI inputs are placed, and optional transposes etc. These are then changed to a MIDI Channel Constrainer, to make sure that each MIDI block will change it’s MIDI channel to the one selection in the songs.txt file.

After that everything is routed to the bypassed rechannelizer on the right. This is ONLY for nicer layout, and all MIDI channels are sent then to the global rackspace.

This is the global rackspace, which is the ‘heart’ of the system and will be split in smaller chunks.

First, all MIDI channels from the local rackspace (a mixture of 16 channels) are now split again.
A script (see attachment below, also some shared parts)
scripts.zip (12.4 KB)

The script calculates how to MIDI-map the input MIDI channels to the output MIDI channels and since there are more than 16 plugins, mixers are used to make sure the correct routings are set.

Then before each plugin there is a MIDI Channel Constrainer to change it’s MIDI channel back to 1 and lead it into the plugin, to be output to the mixer.

After that, the audio is routed back to the local rackspace, where effects, audio mixers can be used, and routed back to the global rackspace again for post processing.

Finally there is some post processing.

The script may look complicated (with more than 1,500 lines), however, it has a lot of functionality:

  • Bypassing everything that is unused
  • Parsing the songs.txt file and setting the channel constrainers and MIDI rechannelizer.
  • Loading the correct presets

And some other goodies unrelated to this, like:

  • having some buttons for going forward/backward 5 songs in the set list (to prevent loading times)
  • stream audio file player support
  • post processing
  • using pads for the light (DMX) controller.

If you have any questions, please let me know.

4 Likes

Hello. The topic is very interesting. I am also trying to find a solution to reduce the RAM used. It would be nice if they added the aliases function from Mainstage in next update. I work on a ship and play with a band. We have about 150 songs with backing tracks. I loaded a few plugins into Global Rackspace and I’ve already made a few presets with sounds and layers with different settings. Unfortunately, I can’t split the keyboard sounds. Can you explain to me? I can send my gig file for you to look at.

To reduce RAM usage you can use predictive load