The original problem you stated was the huge startup time and memory usage. That indicates you weren’t actually using predictive loading?
How a VST defines its own “plugin state” is up to the VST. For most VSTs every parameter that the user can adjust is stored as part of the plugin state. The purpose of that as designed was so that if you save a project in a DAW and re-open it later the state of the plugin can be saved with the project file and when it’s re-loaded everything will sound as it was when saved.
I can’t speak for the developers, but in principal I can’t think of a reason that the plugin states in the global rackspace couldn’t be saved with individual rackspaces. I’m just not sure how useful that feature would be for most users. It would be problematic for the way I use it, so it’s something that the user would have to be able to turn on or off.
The other major thing to be aware of with sample based plugins like Keyscape is that the plugin state does not generally include all of the samples. Again, it’s up to the VST developer to decide how to define that, but from what I’ve seen the typical plugin state information for a sample-based VST will include a reference to what samples it required (e.g., Yamaha LA) but not the samples itself.
So, for example, if you want to be able to quickly switch between a grand piano and a Rhodes the only way to do that is to have both sets of samples loaded at the same time. So you could put two instances of Keyscape in your Global rackspace if you wanted to.
The other solution you could consider is running a second instance of GP in parallel. I’ve done this with Superior Drummer, which has long loading times and takes up a lot of memory. If I want access to three different drum kits across say 30 rackspaces I find it easier to just put Superior Drummer in a second instance than to put three instances of it in the Global rackspace.
1 Like
Yes you are right, I wasn’t really aware if it is still enabled in my setup and it was disabled. But on the other hand when I enabld it again I get a faster startup, yes thats nice but I get an unpredictable extra delay when switching btw. racspaces arbitrarily. I guess that’s a bigger issue in live performances compared to the startup time. But thanks for pointing me on this again!
Yes I do
Not the best idea, take a look at Rig Manager.
You will love it 
Are you a Standup Musician 
“Erkennen Sie die Melodie?”
I know Rig manager but I have no different HW setups where RIG manager would help to switch/map different HW to “controller roles” in my performance. But I’m aware of this
No but during rehersals and even on stage sometimes things go in a differnet order than scheduled originally.
Thanks a lot for you detailed description and for bringing much more light into the dark!
I’m using Windows 10 and an UR44. And since the Steinberg USB driver is not multiclient capable I can not use the same interface in multiple instances. Other manufacturers like RME seem to provide this capability. I will think about.
Take a bottle of beer and you are fine
I am using RME UFX II (I know upper class), and this is working super reliable.
Yes I know but I was hoping the creator of VST would do the job as well
That is not the only use for Rig Manager. Even if you only have one rig, it’s very convenient to be able to refer to your controls by name.
Also, if you use widgets instead of mapping VST plugins directly to MIDI controls, you get the benefits of both scaling and grouping - both of which are much harder to do if you bypass widgets.
Also, using widgets instead of direct MIDI mapping (which not all plugins support, by the way) lets you much more easily see what is connected to what as well as the ability to leverage variations to change parameters automatically
I see, I used Widgets in the previous GP versions where configuring and layouting was a bit boaring and time consuming. This has been enhanced signifficantly in GP4 and I’d like to give it a second try.
And of course scaling
Oh yes I like that, and I also re-tried learning scripting which is really a fun now!
But currenty I’m missing a function retrieving the name of the currently loaded GIG or GIG file.
Is there any way to get this info?
Why do you need that?
You could include the new comment plugin in the global rackspace and show it for example by assigning a widget to show that plugin.
I want to save the settings of my global plugins (VSTI blocks in my globel rackspace) each time I change/adjust them specifically for the local rackspace which is currently using it. And then each time I re-activate this local racksapce again I want to restore exactly this preset in this global plugin automatically using “LoadGPPreset(…)” in a “On ControlChangeEvent(…)” handler by sending an appropiate CC from local to global rackspace e.g. via virtual midi cable. This way e.g. I want to restore the specific drawbars setting of the VB3 block in the global rackspace as required by this currently activated local rackspace.
This means I need a GP Preset naming scheme to uniquely address such presets. For this I want to use a name format like: “GIGfileName”-“RackspaceName”-“GlobalVSTIBlockName”
So the GIG-File name is the top most context in the address-component which I need to organize the settings data uniquely for all GIGs.
I have seen functions retrieving the song name but is there no simmilar getter for the rackspace name?
Ok but this is somting like a workaround. Each time I “copy-create” a new GIG file I need to adjust this “comment”. In this case I would prefer to use a string constant in the event handler and adjust it in the same way.