If it’s constant static data that is only read, that’s OK.
But are you using static or global variables that are mutated (changed)? Those stay around at their current values if the host doesn’t fully unload the plugin dll/dylib before creating new plugin instances. Maybe Pro Tools keeps the plugin dlls/dylibs always loaded? (It’s not entirely unheard of with VST plugin hosts either. Some hosts avoid unloading and reloading the dll/dylib because that already can be a time consuming operation with some plugins.)
You didn’t yet confirm does the old plugin ID really come from the data the host has when calling setStateInformation? If that is the case, could it be a feature in Pro Tools like “use last used plugin settings when instantiating plugins”? It could also be related to plugin presets/banks.
Does the same behavior happen with your plugin with other plugin formats and hosts?
IIRC Pro Tools will keep these statics around. We experienced that with some licensing code, removing your license file wouldn’t prevent new instances from still being activated since the license was previously validated
After some further inspection, i don’t think the AAX behaviour is the same as the RTAS behaviour. setStateInformation is only called once, just not with a clean memory block, like, when creating a new plugin instance …
Anybody got an idea? This is making me somewhat crazy … i thought about storing the ID as an integer in the PluginProcessors’ parameters instead of as a state property, but that’d be anything but elegant …
After some more inspection, it seems like ProTools calls getStateInformation the very first time a newly installed plugin is instantiated (on subsequent instantiations, it is called only on save).
For subsequent instances, setStateInformation is called once on instantiation, with the data stored in the very first call of getStateInformation, as described above.
When restoring a session, setStateInformation is called twice, once with the data stored on the very first instantiation, and once with the data stored when saving the session with that plugin instance.
Thus, as a workaround, it seems to be safe to just ignore the very first call to setStateInformation for AAX, at least if you don’t want to set any host-provided parameters …
What a mess, seriously … i can’t make any sense of that behaviour …
@parkellipsen - Did you make any more sense out of Pro Tools’ behavior?
I’m coming up against some very unexpected plug-in state recall from Pro Tools as well.
Most baffling to me: as part of testing Pro Tools, I removed all the code from within my processor’s setStateInformation method. And Pro Tools is still able to restore parameter values saved in a session. It was my understanding that that shouldn’t be able to happen…
After a closer read of what you’re describing here - seems that “very first” getStateInformation would capture the default values of the parameters, yes? And so, Pro Tools captures this state, and caches it away somewhere, and then attempts to restore that state first, before loading session-save parameter data?
That’s weird behavior if so - why not just let the plug-in itself determine its own default state?
Still, it seems even weirder that, even testing with having setStateInformation and getStateInformation in my code do nothing, that Pro Tools still saves and recalls the saved session data. It’s apparently using some other means to set and get the parameters… I need to investigate more, but in my current project, it’s a problem for me at the moment.
Anyone got any idea where Pro Tools stores the “cached” plugin initial state data and how to clear it? I got a dev system here with an obsolete state from a “work in progress” version and I’d like to clear this. Ideally there would be a way to detect whether Pro Tools is creating a new instance, or if it’s actually restoring a saved state (e.g. loading a session, explicitly setting a preset, user-overriden plugin default preset).
Could it be that Pro Tools also stores the values of automated parameters when you save a session, and when you later load that session, it sends them back to the plug-in?
I seem to remember that behavior from a distant past when I investigated this too, but I don’t remember if there are exceptions to this rule, if it can be disabled and whether the parameters are sent before or after setStateInformation gets called.
Perhaps you could check these things to start with.
Hey, thanks for the ideas - I actually wound up getting deeper into Pro Tools parameter saving/loading in this thread:
Short answer - yes, when Pro Tools loads a session, it does its own recall (like automation, but not dependent on the parameters being armed for automation) of parameter values.
It does this first, and then calls the setStateInformation method (passing it back whatever chunk of data, presumably some XML, that you might have given it from getStateInformation). So you have the option then to overwrite your choice of parameter values.
For setting a “new default” state (like @jcomusic and @parkellipsen are talking about above) you could set that explicity from within setStateInformation, if you detect (by parsing the XML for some telltale values) that it was passed the “old default” XML.
To help with that: In the other thread I linked to here, there’s a helper method I wrote called getDefaultStateXml that pulls the default values from the AudioProcessorValueTreeState into an XML object. So then with that method you can force the current state of the parameters back to defaults with: