One of our plugins has a user preference that influences the default value of a parameter right after the creation of a new instance, so that it might be different from the actual parameters default value. The parameter is set to the possibly desired value in the first prepareToPlay callback.
This didn’t work in Pro Tools and after some debugging I found out, that Pro Tools sets all individual parameter values via invoking AAX_CEffectParameters::UpdateParameterNormalizedValue in an initialization routine, shortly after EffectInit returned, which will emit the initial prepare call for AAX plugins. We have AAX_eProperty_Constraint_DoNotApplyDefaultSettings enabled to block Pro Tools from setting a default state but this does not seem to avoid the host setting each individual parameter to its default value for whatever reason.
While chatting with the AI, I was suggested to just update the parameter default value at runtime via SetParameterNormalizedDefaultValue but that didn’t seem to have any effect.
I now have a “fix” in place that involves a bool flag in the JuceAAX_Processor that is toggled in an async callback which is triggered at the end of EffectInit. If calls to UpdateParameterNormalizedValue arrive before it has been toggled, the function just returns with AAX_SUCCESS without doing anything. This way, these initial parameter settings are not applied and it seems to solve my problem. Still this feels a bit wrong.
Did anyone here come across the same problem and has a solution to that? Are there any thoughts from the JUCE team on a good solution to this, as I’m not feeling super confident adding such logic to the JuceAAX_Processor without having a good overall picture.
As mentioned in my initial post, we already set that, JucePlugin_AAXDisableDefaultSettingsChunks actually sets AAX_eProperty_Constraint_DoNotApplyDefaultSettings as it can be seen in the code snippet you posted.
What that setting does is basically avoiding that Pro Tools calls setStateInformation after instantiating the plugin to apply some cached default settings. The issue here is that it still sets every single parameter to what it believes are the correct default values so that the plugin revieces a parameter change callback for all of them.
This seems to be in the category of linked parameters, since you want the value of the parameter to be changed by a setting. In these situations, I normally recommend finding a way to unlink the parameter values. For example, you can have the affected parameter be an offset, rather than an absolute value. If the user setting is just a toggle, you could have two parameters, and ignore one when the toggle is set to the other position. You can also consider having a layer between the parameters and the coefficients that go into the DSP, where the parameters are interpreted/translated according to the rest of the state of the plugin.
