AAX / ProTools - plugin states persistent over multiple sessions?

Hi,

i have a Plugin that stores a specific ID for certain purposes in the plugins MemoryBlock. Now consider the following steps:

  • start Pro Tools (12.8.2 Developer)
  • create an empty session
  • create a track and add a plugin instance
  • create a new empty session
  • again, create a track and add a plugin instance

Now, i’d expect that nothing should be restored in the new session when setStateInformation is called. Instead, the ID stored in the first session gets restored.

This seems to be rather annoying … is there an explanation for this behaviour, and can it be changed ?

EDIT: It seems that, when i start with a clean slate, the add two instances, the second instance loads the memory block of the first instance, which is probably related and equally annoying.

Best,
n

1 Like

Are you sure the old ID is restored by the host application calling setStateInformation? There is no static or global variable involved in the plugin?

Hmm, now that you say it, the Identifier instances to address the id in the AudioProcessorValueTreeState that i use to save and load stuff are in fact static (as proposed by the ValueTree tutorial).

But they only should be relative to an individual plugins ValueTreeState, no?

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

Yes, the old plugin id is restored in the setStateInformation method from the ValueTree that is de-serialized from the MemoryBlock, together with all the other
parameters of the plugin.

No static or global variables that are mutated, the AudioProcessorValueTreeState as well as the plugin UUID are non-static members of the PluginProcessor.

I tested VST2, VST3 and AU with several other hosts, and none of them shows the same behaviour.

Hmm, could it be related to the way the ValueTree is stored/serialized ?

I initialise the ValueTree like this:
parameters.state = ValueTree (Identifier ("myPluginName"));
(where parameters is a AudioProcessorValueTreeState instance)

If i initialize it like this:
parameters.state = ValueTree (Identifier (Uuid().toString()));
the problem doesn’t occur, but i can’t reload the state of the plugin (including the id) either.

Could it be that ProTools somehow uses the Identifier globally, internally ?

I’d find that strange, esp. given the fact that i store the state in binary form …

Also, it only affects the parameters that are manually injected, like so:
parameters.state.setProperty(propertyID, pluginId.toString(), nullptr);

Plugin created using createAndAddParameter(...) are not affected …

Could this be due to the way Pro Tools caches the state information when you first instantiate the plugin? This post describes it in a little more detail: Pro Tools "Compare" button

This only happens with Pro Tools so may well explain this behaviour

Hmm assuming this is handled the same way in AAX, this might explain the confusing behaviour, yes …

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 …

1 Like

@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…

???

Yes, as far as i remember, this will happen until you remove the plugin completely once (so Pro Tools “forgets” about it) and then re-install it.

But the workaround (ignore the first call to setStateInformation) didn’t change, and so far does the job …

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.

Yes, that sums up my experience. I didn’t encounter the last part though, never checked with empty setStateInformation and getStateInformation.

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).

Search the AAX docs for DigiOptionsFile

Rail

1 Like

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:

parameters.replaceState (ValueTree::fromXml (getDefaultStateXml()));

(here, parameters is the name of the APVTS)

Hope that helps…