# Workaround for Pro Tools initialising all parameter values to their defaults

**URL:** <https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376>\
**Category:** Audio Plugins\
**Created:** [August 27, 2026, 4:10pm UTC](https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376 "2026-08-27T16:10:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [August 27, 2026, 4:10pm UTC](https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376/1 "2026-08-27T16:10:03Z")

</div>

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.

There was this topic quite a few years ago bit it doesn’t contain too much helpful information, mainly a dead link [Parameters reset by UpdateParameterNormalizedValue(..)](https://forum.juce.com/t/parameters-reset-by-updateparameternormalizedvalue/10041)

---

<div class="post-metadata">

**Author:** ![AdamVenn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamvenn/32/17023_2.png) [@AdamVenn](https://forum.juce.com/u/AdamVenn)\
**Post date:** [August 27, 2026, 9:59pm UTC](https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376/2 "2026-08-27T21:59:39Z")

</div>

Does `JucePlugin_AAXDisableDefaultSettingsChunks` do it?

> <https://github.com/juce-framework/JUCE/blob/7aae7d8e8deb8413bb01633d2795ef9974a181c5/modules/juce_audio_plugin_client/juce_audio_plugin_client_AAX.cpp#L2510>

> <https://github.com/juce-framework/JUCE/blob/7aae7d8e8deb8413bb01633d2795ef9974a181c5/modules/juce_audio_plugin_client/AAX/SDK/Interfaces/AAX_Properties.h#L881>

---

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [August 28, 2026, 6:58am UTC](https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376/3 "2026-08-28T06:58:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![AdamVenn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamvenn/32/17023_2.png) [@AdamVenn](https://forum.juce.com/u/AdamVenn)\
**Post date:** [August 28, 2026, 4:42pm UTC](https://forum.juce.com/t/workaround-for-pro-tools-initialising-all-parameter-values-to-their-defaults/69376/4 "2026-08-28T16:42:26Z")

</div>

Oh whoops sorry for the noise.

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.

Hope those ideas help.
