I’ve recently been trying to workaround a problem in my AAX build which is caused by a Default Settings Chunk. After some searching I found I should set the JucePlugin_AAXDisableDefaultSettingsChunks flag, but it appears to not disable the default settings chunk.
So I inspected the comments in the JUCE code and found this:
Support for this property is not guaranteed; the plug-in must be able to handle default settings chunk application even if this property is set, or clearly document the plug-in’s host compatibility.
I don’t fully understand what I’m supposed to do with this information. Does it just mean that trying to disable default settings will not always work and that’s just how it is, or is there an additional step I can take to ensure that disabling default settings always works?
Maybe I’m missing something obvious, but I’m feeling a bit lost.
JucePlugin_AAXDisableDefaultSettingsChunks maps directly to AAX_eProperty_Constraint_DoNotApplyDefaultSettings=true. Unfortunately I can’t provide much more guidance than the docs for this property. It seems like this is a hint to the host that the plugin can initialise itself and doesn’t need to be supplied with a default state, but the host may ignore this hint and supply a default state anyway.
Thanks for the response. That’s what I figured was going on based on the code comments, I was just thrown by the “…or clearly document the plug-in’s host compatibility” part - thought that might be a clue to something else.
It’s a bit frustrating to have the ability to ask to disable something, but not have it actually disable that thing. It’s like having a light switch that has two “on” positions.
But frustration seems to be an integral part of the AXX/ProTools experience, so it’s very on brand for Avid.
I believe that’s meant to indicate that the flag is supported only starting from a certain version of Pro Tools, and that earlier versions of Pro Tools will still load your plug-in in projects that contain it, even if that flag is set.
That means that, if you load a project containing your plug-in in an earlier version of Pro Tools, your plug-in will receive the default chunk even if it asked not to.
If you want to avoid that, you don’t really have a way to prevent that from happening so you must resort to clearly state that your plug-in only supports being used from a certain version of Pro Tools onwards.
Hey so i faced the same issue very recently and tried to enable this flag.
clearly state that your plug-in only supports being used from a certain version of Pro Tools onwards.
I wish you were right, but unfortunately i still notice the issue in my recent version PT developer (2024.6.0). I suppose this has been reported to Avid, does anyone know?
I have also been testing using the latest version of Pro Tools Intro (the free version) and have had no luck getting this flag to do anything. But perhaps this flag has been depreciated or something?
I’ll contact Avid and see what the deal is. I just thought I’d try here first to see if anybody had experience with this and had a potential solution.
I also noticed that somehow having this flag turned on messes up the ability for the user to have “Default Setting” for your plugin so i decided to turn it off…
Maybe the plug-in is still receiving the default values for the automated parameters and that is enough for your plug-in to set itself into an undesired default state?
Pro Tools has two “default” informations stored: the state that your plug-in returns from getStateInformation() as soon as it is instantiated (which is stored in the default chunk), and also the default state of each automated parameter
I had read this and it seems to end with the conclusion that the flag does nothing and we just have to create a clunky workaround to deal with the problem. I will admit I have been struggling with workarounds because fixing one scenario easily breaks another and my priority is that the users saved settings recall correctly without exception. There’s also the worry that Avid could make small changes that would break any workarounds in the future.
I just wanted to dig deeper into the flag itself and see if anybody had better experience with it, but it looks like that isn’t the case.
