Saving plugin settings without using widgets?

I’m using GP as a VST host for FOH. Several of the plugins I’m using have a very large number of parameters, and mapping all these parameters to panel widgets would be impractical.

It appears creating rack variations only saves the widget values. If I create a rack variation and then change a plugin value via it’s native panel, that value changes everywhere, and other variations of the rack have the new value, not the original value.

So how can I save unique plugin settings with each rack variation (or with songs/song parts, etc) without having to map each plugin parameter to a widget?

Thanks!

The Plugin State is part of the rackspace.
So variations do not store different plugin states.
Variations are only to store different widget settings but not storing different plugin states.

But with scripting you could recall GP presets.

Maybe this approach could help:

Summary: just create GP presets an recall them in your variations by radio buttons

2 Likes

And FYI, this is why plugin state is not stored per variation. Restoring plugin state is not instantaneous and in most cases, the plugins will not produce audio while state is being restored, resulting in audio dropouts.

Thanks! So I found the GP User presets (took me a bit to realize it was on the plugin menu). That part was easy enough. But I’m surprised that mapping a user preset to a widget requires a custom script. Seems like this should be built into GP.

I’ve downloaded the example but haven’t managed to get it working yet. When I open the script editor there is nothing there. Not sure how to find/open the script that makes this thing work.

Why don’t you create different rackspaces with different settings of your plug-ins, but all with the same wiring? Starting from one template with all you need, and then multiple duplicating and adjusting steps?

These rackspaces could be mapped individualley to songs, for example for a setlist of the show or band?

1 Like

This makes sense to me to, Angel. It sounds like he is not using plugins that are ram intensive (sample libraries). So, might as well just create separate rackspaces instead of using variations.

I have 60 rackspaces and 60 songs in my gig file, each with NI Kontakt, Omnisphere, sample libs … and 64 GB RAM.

Awesome! That works! I thought I had tried that before and it didn’t work. But I just tried it again and it works! Thank you!

1 Like

Several reasons.

  1. We have found from experience in the past that some plugins don’t handle having their state change on the fly and just crash. This is why the script function that loads presets is still marked experimental.
  2. Even when it does work, most plugins will go silent for an indeterminate amount of time during that load, thereby causing glitches, something we worked very hard to avoid and it is why we use that multiple rackspace model that you’ve just discovered works for you :slight_smile:
  3. The whole point of variations is just that - to have a small number of variances that you can quickly jump between, e.g, change phaser depth, turn on (or off) an echo, tweak the volume for a solo, turn one plugin on while bypassing another one.

We may expose preset loading through presets at some point but it has not been a high priority because we prefer to preload everything so nothing actually has to change while you’re performing

2 Likes

Ahh, I misunderstood. I thought you were handling FOH mixing, etc.

Yes, my use is FOH/mixing. The VST presets just need to be loaded per song, so switchover time isn’t a big deal. The idea is to have a good starting point based on studio sessions/rehearsal’s, and then tweak as needed during the song.