Pro Tools calls setStateInformation between processor & editor construction with some default state

I’m facing a strange behaviour under Pro Tools.

Our plugins read some preferences regarding a default editor layout from a preference file on processor construction. If a first fresh instance is loaded in an empty project, this works well. If I change the default preference through the first instances editor, the preference gets successfully written to the preference file.

Now if a second instance of the plugin is added to the same track, I see the following behaviour with the debugger attached:

  • Processor gets constructed. It reads the correct state from the preference file and sets an according state in the ValueTree used to manage our state
  • Now the Pro Tools automation thread kicks in and calls setStateInformation. There is no previous call to getStateInformation, so it seems to apply a cached “default” state. This state contains the previous preference the first instance read when being created
  • After this is done, the editor is constructed and reads the preference state from the ValueTree. Result: It does not read the state the processor just wrote to the value tree but an outdated state.

So what’s happening here? I’m extremely confused as this behaviour doesn’t make that much sense. Anyone that came across the same?

That is correct. Avid, for some reason, decided that Pro Tools would query and cache the session state of the first instance of the plugin to be created, and apply that state to every subsequent instance, even though plugin developers set their own default state, sometimes based on a preferences file (as you and I are both doing).

A couple ways to deal with that. Knowing that (in AAX) the first call to GetChunk() (the AAX function that leads to getStateInformation() in JUCE) is always the call to get this supposed “default” data to be cached and applied to subsequent instances, you can add a boolean flag to the data that says whether this is the first “defaults” chunk data (based on a shared global variable that says whether the GetChunk() function has ever been called in any instance yet).

You can use that information to tell subsequent instances whether to ignore the rest of (or some of) the SetChunk() data when loading that data later. You can also, in GetChunk(), set the content of the returned data to be the defaults that you DO want to use across all subsequent instances, if there is data like that you want to preserve rather than ignore. We do that, ignoring some data but using certain global defaults from this “default” chunk when reading in the data.

But I have not implemented this in JUCE yet. You need to be sure that this applies only to AAX instances. And if Avid ever decides to change that behavior, this fix would break.

1 Like

There is also apparently an AAX property that you can set to prevent Pro Tools from loading its own cached “default state” for a plug-in. However, the JUCE AAX wrapper doesn’t currently have a macro to set this property (as it does for, say, JucePlugin_AAXDisableDynamicProcessing).

Looking at the AAX wrapper, it looks like it would be easy enough to add, but since there is a non-disclosure agreement to the AAX SDK, I don’t think I should post that here.

1 Like

We also read this announcement from the Avid Developer Newsletter and we’ll be definitely adding this flag to our in house JUCE fork to finally get AAX plugins behave consistently with the other formats in the long run. Would be great if this option made it into the main JUCE repository

1 Like