AU parameter order vs. VST and VST3; JUCE_FORCE_USE_LEGACY_PARAM_IDS

I have a plugin where I am creating VST, VST3, and AU versions. JUCE 5.4.7. It uses an AudioProcessorValueTreeState to declare and manage some parameters.

For example, the first parameter specified is Tempo, followed by 6 “Replications” parameters (for 6 different “modules”), then 6 different “Note Sort” parameters and so on.

I notice that in the AudioPluginHost, for example, when you right-click and select “show all parameters”, the VST and VST3 versions have them exactly and logically in the order that I created them .

However, the AU has the parameters in some sort of random order, bearing no relationship to the order in which they were declared - all mixed up and jumbled.

Is there anything that can be done about this?

So I enabled JUCE_FORCE_USE_LEGACY_PARAM_IDS in the Projucer, and lo and behold - now the AU parameters are in the same order as the VST/VST3 - the order of creation.

However, I’m worried about the description for this:

/** Config: JUCE_FORCE_USE_LEGACY_PARAM_IDS

    Enable this if you want to force JUCE to use a continuous parameter
    index to identify a parameter in a DAW (this was the default in old
    versions of JUCE). This is index is usually used by the DAW to save
    automation data and enabling this may mess up user's DAW projects.
*/

"enabling this may mess up user’s DAW projects"

Can anyone provide any more information on what that means and whether it’s dangerous to use this?

I think it refers to the case of changing JUCE_FORCE_USE_LEGACY_PARAM_IDS between different versions of a released plug-in.

If you release version 1.0 with JUCE_FORCE_USE_LEGACY_PARAM_IDS disabled, and then decide to enable it in a subsequent version 1.1, then it’s very likely that DAW projects created by users with plug-in 1.0 will not load correctly to some extent after they update to 1.1: from automation lanes ending up disconnected, to failing to load their state entirely depending on how the host uses automation to reload it.

But as long as you keep your JUCE_FORCE_USE_LEGACY_PARAM_IDS consistent from the start, then no problems should arise

2 Likes

It’s worth being aware that the legacy JUCE method of reporting parameter IDs was to use the parameter index, so if you want to add any new parameters in the future you have to add them at the end of the parameter list or automation will be messed up. It is much more flexible and future-proof to use the current JUCE method of reporting IDs for VST3 and AAX!

The reason AudioUnit (certainly in Logic Pro, although I’m surprised the JUCE host is doing the same) is showing you the parameters in a different order is because it lists them by alphabetical ID, rather than in the order declared by the plug-in. This also adds the restriction that any new parameters added must list “alphabetically higher" than existing IDs (e.g. “aaaa”, “aaab”), otherwise your automation will be messed up. So Logic will introduce this problem for you either way, unless you create some space between the IDs you use (e.g. “aaaa”, “bbbb”, etc.).

We’ve have to deal with a lot of legacy compatibly…

3 Likes