What’s the best practice for the following use case?
My global rackspace has a few synths I would use frequently. The goal is to only load one instance of a given synth once then use some sort of method at the local rackspace level to change that’s synths presets. What is the recommended best practice for achieving this?
Best practice would be use your synths in local rackspaces.
This way you can use patch persist.
Yeah, I’ve done that approach with other bands. The problem is, this is very heavy synth oriented 80’s music. I thought the purpose of the global rackspace is to allow you to save memory footprint by only loading a single instance of a VST plugin. I really need that capability, I can actually leverage it to my benefit but the only problem is, I’m stuck using the preset that synth was set when I added that synth block to the global racksapce. Another way I try to save memory is to break down our show by using the set list approach. Rather than load the entire show, I load one set (gig file) at a time.
My hardware setup:
Macbook Pro 14", M5 chip, OS Tahoe 26.x
Focusrite Scarlett 2i2
SABRENT 16-Port USB 3.0 Data Hub & Charger, 90W (HB-PU16)
Roland A-49 MIDI Controller
M-Audio Oxygen Pro 61
Arturia Keylab Essential 88
Only Sample based instruments consume a lot of memory.
And when you load the same synth in each local rackspace only instances of that plugin are loaded and not the complete plugin.
When you really need to save memory you could use predictive load.
Correct. I’ve done the predictive loading approach before in other bands. I guess what I’m saying is that it’s too bad my globala rackspace appraoch has a one fatal flaw: You cannot reliably change a preset from a local rackspace. I guess I’m just stuck with the local rackspace approach and wasting all of that memory with duplicate instances all over the place. It’s not Gig Performer’s fault at all, it’s that VSTs have handed this responsibility to the DAW and VST hosting platforms. I’m guessing the reason was because plugins didn’t manage that well and would cause unexpected behaviors?
What RAM usage is shown in the activity monitor when you use local rackspaces?
Is memory a real issue or do you just feel bad when memory is consumed?
30% and I realize that’s nothing at all. I’m not only running GP but I’m also running Ableton Live to cover playing the backing MIDI tracks for some of this material. There’s no critical mass that has been reached yet but I fear the day it does. I’m not even finished with one set of material (12 song sets). So, a part of this is me panicking thinking I’m going to hit that critical mass soon. I just wish my sound concept of leveraging the global rackspace would work in reality. It’s a very neat and clean way to manage your rig.
How much RAM do you have?
I have 32GB and I am running Ableton Live in parallel.
I am playing in a Pink Floyd Tribute Band and RAM is no issue at all
By the way: What means 30% RAM usage in activity monitor?
The issue with using global rackspace is:
No way to use patch persist
No automatical way to change presets of synths
Complex routing for leveling the sounds needed in the local rackspaces.
Complex routing for key splits, layers etc.
Keep in mind that some plugins do not like to change presets.
This are some of the reasons I never put a synth into the global rackspace.
In my global rackspace only the Master Gain and a limiter is used.
All other processing is done in the local rackspaces.
I’m gathering the REAL memory and cpu usage for you…
BTW: I enjoyed your OSC demonstration!! I want to leverage OSC to drive Ableton from GP. Only my approach will be to have an entire set of backing tracks loaded into Ableton session with Gig Performer sending OSC commands to tell Ableton which location marker to go to when as I move from song to song in live performance.
Why not use session view?
I’m using Arrangement view because of the linear way my backing tracks, clicks and cues are laid out. For me and the way I think, the linear layout of arrangement view seems to make more sense. Maybe you can convince me otherwise?
If I could use Ableton’s session view, I could use your OSC approach as is, right out of the box, right? 
Well, understanding first that global rackspace was not designed nor intended to do this, there are actually several ways you can do it
The obvious way is with some GPScript in the Global Rackspace Script by responding to callbacks that are triggered when you change rackspace, or when you change a variation, etc. and then use the LoadGPPreset system function to load a new user preset.
A different approach is to leverage the OSC system in which case there are several mechanisms you can use
For all of these, give the plugin in the global rackspace an OSC handle - I used “GlobalLegend”
SendOSCMessage { "/GlobalRackspace/GlobalLegend/LoadGPPreset", "Jim" } to "127.0.0.1" : 54344
I’ll give this a go, David. So, with what you’ve recommended, I could still have all of my synths inside the global rackspace? I’m dying to use some of this OSC stuff between GP and Ableton Live. It’s pretty slick stuff.
I found some GP Scriptlet that used the On Activate() event to try to push preset changes over to the global rackspace but it didn’t work at all. Plus Google AI had me coding that scriptlet inside my local rackspace and not in the global racspace.
One question, David: I will have to save my Presets for say, the GForce Prophet 5 (macc user), in
~/Documents/Gig Performer/Presets/GForce/Prophet 5/
The Preset name in my case would be ‘RedSkies-Patch1.gpp_vst3’
I am absolutely not recommending that you do this.
Among other things, a key feature of local rackspaces is that plugin CPU usage is managed automatically as you switch from one rackspace to another. If you put everything in the global rackspace, you’re going to have to manage the plugins yourself to avoid CPU overload. You also lose patch persist, variation support, instant sound switching and other valuable features.
You’re basically trying to work around the GP paradigm. While it can be done (thanks to such things as GP Script and sneaky but unintended purpose of OSC for internal control), it’s breaking the paradigm and you’ll probably have other issues in the future.
I recommend that you stop worrying about premature optimization and just put the plugins you need for a particular song in their own rackspace and even better, if you need different plugin in different parts of a song, then put them in separate rackspaces and use setlist mode with song parts mapped to the required rackspaces as you go through a song.
I think we’re going to have put a stake in the ground and say we really can’t officially support anything produced by AI tools - those things are as likely to get it wrong as right and if the user doesn’t understand exactly what was produced and can correct the mistakes, we get stuck having to support completely wrong suggestions.
No, it would be RedSkies-Patch1 - you don’t use the extension
FWIW, I have tried to follow GP’s intended paradigm. Just using separate instances of plugins and creating rackspaces using whatever plugins you are needing at a particular time (in a particular song part, if using Setlist Mode).
For me the only time tried to reduce instances of a plugin is when I am using sample-based sounds. If it is a soft synth or a physically modeled plugin, I just use it freely without worrying about ram.
In my case, if they are big sample based instruments and I use them often, I do put them in the Global Rackspace (but still one instance of the plugin per “sound”).
Another strategy I use is re-using rackspaces. If they have the plug sounds I need. I can add and bypass additional ones, but re-use the plugin(s) with the sound I want.
Vindes created an extension to make it easier to double check that tweaks to re-use the rackspace do not mess up any other song parts using that rackspace: GitHub - WidnerM/Rackspace-Songlist: Utility to produce a list of all Rackspaces and each of the Songs/Songparts that utilize it · GitHub
Predictive Loading is another option, but I am avoiding it. Although it is amazing, I think it is fair to say it may increase the chance of having issues with stability, etc.
When you use set lists you can set predictive load to a value so that all rackspaces needed for the set list are loaded.
This way all needed plugins are loaded => stability issues.
To be clear: Some plugins do not like to be loaded, unloaded and loaded again.
This is not an issue of Gig Performer itself.
