I would like to save and restore the state (both parameters and UI) of all plugins and their editors in a rackspace graph when a variation is saved and restored, not just those parameters mapped to panel widgets.
It seems reasonable to allow this option since GP must already store and restorefull plugin state in the rackspace so plugins will open in their last known saved state. The VST3 SDK supports this.
Can an option be added to GP rackspaces that would allow per-variation plugin state save/restore? The only workarounds I can see for this is to clone rackspaces with identical graphs instead of using variations, or writing some code to create panels full of hidden widgets that map to every plugin parameter.
You’re describing what rackspaces are designed do. Variations are designed to retain the changed state of the widgets in a rackapace that are mapped to plugin parameters.
Just use separate rackspacss for the functionality you’re looking for. It’s not a workaround, it’s a feature.
My use case involves a single rack, one plugin graph, one panel. I wasn’t involved in making GP design decisions, but given the naming, RACKspaces seemed designed to represent different RACKS. Variations seem designed to represent different SETTINGS with a rack.
The limitation I have run into is that variations only preserve differences in the mapped widgets, not the entire gamut covering every plugin’s settings.
I suspect that swapping all plugin state when switching variations might cause some glitching as the API to do this likely updates the entire control and probably resets the state first in some cases depending on how the plugin author handles the update. On the other hand, I have code that uses these VST3 SDK calls quite successfully:
// Save
component->getState(componentStateStream);
editController->getState(controllerStateStream); // optional but normal
// Restore
component->setState(componentStateStream);
editController->setComponentState(componentStateStream);
editController->setState(controllerStateStream); // if controller state exists
Your suggestion also breaks how I would use this: perhaps two or three different racks with tools for fixing different mastering problems. All variations of rackspace 1 would be grouped together as variations, rackspace 2 would be together, etc. If I decided to improve the panel or rackspace later, all variations would get the improvement. That wouldn’t happen if each variation was a clone in a separate rackspace. And it would be difficult to find all variations of the original. And the rackspace selector would be nearly twice as long as it needs to be.
If you change a plugin setting that is not mapped to a panel widget (unmapped setting), that setting changes in in every variation. Making each variation keep its own unmapped settings independent of other variations in the rackspace solves my use case.
First of all, that is exactly how GP (and presumably other hosts) do it - it’s well defined in the API.
It works perfectly, until it doesn’t! Unfortunately some plugins don’t properly handle having their state changed on the fly and consequently crashes occur. That’s one of the reasons we use the rackspace model and only parameters associated with widgets are changed through the standard host automation API.
Huh - quite the opposite — if a widget isn’t mapped to a plugin parameter, then changing variations will not affect that parameter at all.
This is unlikely to change, certainly not in the near future. It seems to me that if GP Script isn’t sufficient to handle this rather unique need, given that you seem to understand programming (based on your comments earlier about saving/restoring state), you might want to consider building an extension using the GP-SDK that has its own widgets in a window which you can then control any way you want.
You are absolutely correct, I mis-spoke, the plugin’s value/setting doesn’t change. I get it, duh!
But: What I meant was, if you change an unmapped parameter via a dialog editor in one variation, it then will have that same (new, changed) value in every other variation, changing that variation’s setting too for that parameter. This was my one major misunderstanding of how rackspaces work and cause me a lot of pondering, if not headaches, using GP.
I might end up using GP script to create widgets for every parameter that isn’t already mapped to a widget in a panel. This would be a “panel development” script, not runtime. It’s a hack though. Those widgets would also be hidden. How would an extension be a better solution?
So while GP Script was designed to allow functionality to be added if not already built into the product, it’s not a panacea. If you create an extension, then you have the full power of a programming language such as C++ behind you. So, for example, since you can get callbacks whenever a widget changes (or a plugin parameter changes) and of course you can set said items to new values, you could use an std::map (say) to associate a widget with a plugin and parameter number or to break that association, you could easily implement exactly your use case.
