It is often said that if you find yourself using the same plugin in several rackspaces, it might make sense to put that plugin into the Global Rackspace and then access it from each rackspace that uses it. I’m curious to know exactly under what circumstances will moving VST instruments into the Global Rackspace help performance, and in what ways, and how much, so that I can have a better understanding of when it makes sense to take that step.
I think my main goal would be to reduce gig loading time (since right now my gig takes more than 5 minutes to load up, so if it crashes in mid-set I’m kind of screwed). As a secondary goal I would like to use less RAM (since maybe it’s high RAM usage which would be causing most of the crashes?). I don’t think it’s very important to reduce CPU usage for me at this point since that never seems to be an issue. Are there other considerations as well?
Let’s say my gig file has 100 rackspaces in it, and I find that 50 of them are using the same piano plugin, 30 of them are using the same organ, and 5 of them are using the same guitar. I should definitely move the piano to the Global Rackspace, right? Shold I also move the organ? What about the guitar? What’s the best way to think about these questions?
Moving an often used plugin to the global rackspace is a good idea.
BUT: You have to manage when this plugins needs to be bypassed and transpose and key range.
This is very easy in local rackspaces but not straight forward when using a global rackspace.
Best would be you get MIDI In in the local rackspace where you define your key splits and filter note on messages for plugins which should not produce sound.
And then route this MIDI via the OSC MIDI to the global rackspace.
Make sure that you use plugin which do not consume CPU when not played.
Softube Juno 106 is a super sounding pluging, but is uses CPU even when not played.
So if I have any instrument used in two or more rackspaces, will it save resources to move it to the Global Rackspace (assuming I bypass it in the rackspaces that don’t use it and assuming it consumes no CPU when bypassed)? Obviously I’ll start with the instruments that are used in dozens of rackspaces, but once I get going on this reorganisation process, when should I stop? Is there a point of diminishing returns?
When an instruments with the identical sound is used in only some rackspaces I would not use it in the global rackspace.
The global rackspace is more like a Master Bus where to put some Master Compressor, Master EQ or Master Limiter in.
In my global rackspace I am using a Master Limiter and Steven Slate VSX.
All other plugins I am using in the local rackspace.
And with predictive load enables you can save RAM when necessary.
In my case, I will probably in the future use several instruments and MIDI in plugin blocks in the global rackspace and store for each rackspace the varying properties separately.
Another option is to reuse rackspaces in different songs. I do not believe this increases ram use (unlike duplicating rackspaces).
In different songs you can tweak the relative volumes (maybe essentially mute some?).
As I started writing this, I wondered if variations on a rackspace use more ram? I would think not. If so, variations would also allow you to reuse “instruments” without doubling the ram used (assuming I am correct that you do not take a ram hit in creating a rackspace variation). In the variation you have tremendous control to bypass plug ins, etc.
Michel, when we talked about creating template rackspaces, I didn’t really think about ram use. But, based on my inquiries on this website, each duplicate rackspace uses up a chunk of ram.
Reusing the rackspace in different songs in a set list does not (as I understand it).
And, subject to confirmation, creating a rackspace variation with enormous control via widgets may not. (Need to confirm this).
I’m sort of rambling and could be off base in some respects, but hopefully this is useful for the discussion.
I assume indeed that duplicated rackspaces consume more memory.
That’s why I am intending to put (like Solomon is asking) instruments into the global rackspace to be used by local rackspaces.
But I also want the keyboard split for those instruments to be handled inside the global rackspace (but saved per local rackspace). For this I use scripting and using a physical (self) created file.
If you have a shortcut set up that loads an instance of GP that has predictive loading enabled (with the minimum number of preloaded rackspaces), you can be up and running much more quickly. Use this instance as the backup in case you get a crash.
These are wise words, and in my situation I’m probably not going to follow your suggestion, astute though it be. All of my zone splits and other processing (such as some magic with the sustain pedal and the expression pedal) are currently handled in my (quite long) Global Rackspace script, which then forwards MIDI events to the local rackspace, where VST instruments turn it into audio which they send back to the global rackspace to be mixed and output. So my current plan is to have a facility whereby the local rackspace can request specific instruments from the Global Rackspace to be on particular channels. One rackspace might want the global acoustic piano on channel 2 and a local instrument on channel 1, whereas another one might want the global acoustic piano on channel 1. Yes this sounds complicated. Wish me luck haha! (The more I think about it, the more likely it seems that I may end up doing it exactly as you suggest after all…)
I would love to hear more discussion on this topic. I am sort of considering the same issue as Solomon.
I would think that a heavy ram using/low cpu using instrument that you would like to use in many different rackspaces (along with different instruments in the same rackspace) might be an ideal usage for the Global Rackspace (?)
Let’s say you have an instrument that uses lots of ram, but not much CPU. Maybe something like Sampletekk Black Grande. Let’s say you do not need to tweak the sample library itself. You can pretty much reuse it “as is” subject to changes via widgets (which give you enormous flexibility in many ways).
If you put it in the Global Rackspace, I would think you could freely create rackspaces that incorporate this piano it without using additional ram (?).
But, unlike just reusing a rackspace with the Black Grande, by putting it in the Global Rackspace you are free to create different rackspaces with a variety of instruments in them.
I would think if you have, for example, 5 of these high ram/low CPU instruments, maybe put them in the Global Rackspace. Then you could mix and match them, along with other (maybe lower ram/higher cpu) instruments on individual rackspaces?
I almost always have an instance of Superior Drummer 3 in my global rackspaces, along with a midi file player, so that I can use it for basic rhythm tracks when I’m just playing around or jamming.
In the past, when I used big sample-based instruments with long load times and high RAM usage I’d put those in the global rackspace, but for the most part I’ve stopped using those (other than for drums). If I were still using sample based piano and Rhodes I would most likely put those in the global rackspace to always have them available.
I can think of a few ram based instruments that I have in several different rackspaces that should likely go in the Global Rackspace. I guess some criteria are: Are they ram intensive, are they relatively low CPU, do you need to use them in a variety of rackspaces with different instruments (if you were always using them alone, you could just re-use the rackspace), and are you good re-using a version without modifying the instrument itself (for example, changing the articulations or settings in Kontakt, etc.)
If my case, I should probably put the following instruments in the Global Rackspace and modify my current rackspaces so they do not include instances of them: Friedlander Violin and Session Horns.
