AAX / ProTools - plugin states persistent over multiple sessions?


#1

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


#2

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?


#3

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?


#4

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?


#5

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


#6

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.


#7

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 …


#8

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


#9

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


#10

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 …


#11

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 …


#12

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 …