# AudioParameter versionHint in updated product - does this work? **URL:** \ **Category:** General JUCE discussion\ **Created:** [October 3, 2022, 10:57am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232 "2022-10-03T10:57:27Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![gustav-scholda](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gustav-scholda/32/4172_2.png) [@gustav-scholda](https://forum.juce.com/u/gustav-scholda)\ **Post date:** [October 3, 2022, 10:57am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/1 "2022-10-03T10:57:27Z")
We have an existing project build with JUCE 6 and no version hints in the parameters of course. Now we upgraded to JUCE 7 and got an assertion that we should set the versionHint to be non 0 for AU plugins. If we set this to 1 and release an update to our existing product, will this break automation in existing projects? Also wondering why that assertion is only for AU and not for AUv3? Thanks! ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [December 26, 2022, 11:47pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/2 "2022-12-26T23:47:25Z")
I’m running into this same assertion on MacOS using the standalone PluginHolder. does the MacOS build of the Standalone Plugin Holder load the AU build of the plugin and not the VST3 build? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [January 3, 2023, 10:25am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/3 "2023-01-03T10:25:27Z")
> [@gustav-scholda](#): > > If we set this to 1 and release an update to our existing product, will this break automation in existing projects? This should be safe as long as you don’t add any new parameters during the update. Any new parameters _must_ have a higher version hint than any old parameters. > [@gustav-scholda](#): > > Also wondering why that assertion is only for AU and not for AUv3? At the moment, there’s no way for us to adjust the parameter order exposed to the host by an AUv3 plug-in. As a result, the version hints don’t really have any effect in that format. > [@matkatmusic](#): > > does the MacOS build of the Standalone Plugin Holder load the AU build of the plugin and not the VST3 build? The standalone wrapper doesn’t load any plug-in. It is statically linked with a shared-code library containing all of the non-format-specific plug-in code. When this library is built, flags (such as `JucePlugin_Build_AU`, `JucePlugin_Build_VST3`) are defined, depending on the formats that are enabled in the project. In the context of this question, this means that you’ll see the version hint warning in all plug-in formats (VST3, AU, Standalone etc.) as long as the AU format is enabled for the project. This is useful because developers are much more likely to debug the Standalone format than the AU format, especially with the out-of-process hosting changes on M1 machines. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [October 18, 2023, 10:27am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/4 "2023-10-18T10:27:27Z")
Okay, this causes a bit confusion after updating to JUCE7 and reading the comments in the AudioProcessorParameter. So the best practice is, to update all version hints to “1”? But the comment in AudioProcessorParameter raises the next question, because it mentions “parameters in AUv2 plugins are sorted first by their version hint, and then by the hash of their string identifier.” (which is imho not true, because in the AU-Wrapper actually not the hash is used, only the identifier, which I guess also results in the alphabetically sorted parameters in the logic controls-view) … in order to “ **recall of automation data will work as expected** ” BUT When I check in JUCE6, there seems no parameter sorting at all? So the big question is? **Is that guaranteed that the order for logic automation will be exact the same after updating from JUCE6 to JUCE7 in general?** PS: (I’m very sensitive to these issues after my personal “kAudioUnitParameterFlag\_IsHighResolution” disaster, which in order to solve I needed a custom modification, because It was never addressed for plugins who already used JucePlugin\_AUHighResolutionParameters in conjunction with JUCE\_FORCE\_LEGACY\_PARAMETER\_AUTOMATION\_TYPE, but thats another topic.) ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [October 18, 2023, 11:40am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/5 "2023-10-18T11:40:13Z")
> [@chkn](#): > > “parameters in AUv2 plugins are sorted first by their version hint, and then by the hash of their string identifier.” (which is imho not true, because in the AU-Wrapper actually not the hash is used, only the identifier, which I guess also results in the alphabetically sorted parameters in the logic controls-view) I believe this _is_ true in JUCE 7, though it depends on whether you are using `JUCE_FORCE_USE_LEGACY_PARAM_IDS`. Parameter IDs are reported to the host by `GetParameterList`. In the implementation of this function, we can see that the IDs are generated by calling `generateAUParameterID`, which internally calls `LegacyAudioParameter::getParamID` to find the String ID of the parameter, and then calls `String::hashCode` to generate a hash from this string. When `JUCE_FORCE_USE_LEGACY_PARAM_IDS` is off, this hash is used as the parameter ID; when the setting is on, the JUCE parameter index is used instead. > [@chkn](#): > > So the big question is? **Is that guaranteed that the order for logic automation will be exact the same after updating from JUCE6 to JUCE7 in general?** Yes, provided: - no parameters have been added/removed - no parameter IDs have changed - no JUCE parameter indices have changed - all version hints are set to the same value - JUCE\_FORCE\_USE\_LEGACY\_PARAM\_IDS has not been changed If you want to be absolutely certain that parameters appear in a certain order, you could use the version hint for this. The first parameter would have hint “1”, the second parameter hint “2”, and so on. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [October 18, 2023, 2:18pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/6 "2023-10-18T14:18:35Z")
Aha! Thanks 🙂 I did a bit research in the forum and old juce code. Speaking to myself, and for all others at the same point, this problem has a loooong history, and the versionHint is the fix, for the messed up parameter access deep down in logic or the audio unit sdk. It also means for existing plugins, renaming even a single parameter identifier, can mess up the whole logic automation, if I understand this right. The sheer complexity of things sometimes makes it difficult to keep track of that right away. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 18, 2023, 3:46pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/7 "2023-10-18T15:46:36Z")
VersionHints didn’t really work for us, and we got many reports of them not working in several hosts/formats. The only way we’ve found that works across all formats/hosts is to add new parameters at the end. FR: Please add non-owning ParameterGroups so we could add new parameters to groups even if the new parameters are added to the processor in a different order than the order the groups are added in. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [October 18, 2023, 4:05pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/8 "2023-10-18T16:05:01Z")
> [@eyalamir](#): > > The only way we’ve found that works across all formats/hosts is to add new parameters at the end. But this is also problematic, and version hints are the solution, to not mess-up logic automation. Because the parameters are sorted after the hashed id in logic, and if you just add new parameters without an incremented version id, the position of all parameter can change, which then can mess up logic automation. PS: I think the name version hint is misleading, it should be called orderIndexBecauseOfMessedUpAUParameterHandling 😏 ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 18, 2023, 4:35pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/9 "2023-10-18T16:35:00Z")
This is not what we experienced. In fact using VersionHint failed for us in Logic and parameter ordering did work. We did have to remove groups as that was the cause of parameters going out of order for us. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [October 18, 2023, 4:47pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/10 "2023-10-18T16:47:40Z")
Which version of Logic did you test? I spent a bunch of time investigating this, and came to the conclusion that when Logic stores automation, it always uses the index of a parameter (as returned by GetParameterList) to identify each automated parameter - and this was confirmed by an engineer at Apple. > [@Adding parameters post launch to a plugin?](https://forum.juce.com/t/adding-parameters-post-launch-to-a-plugin/47502/19): > > We’ve now heard back from Apple on this topic. This is a known limitation of Logic, but not one that is likely to be fixed. We’ll add some sort of workaround to JUCE, but this will need some careful thought to ensure that the parameter system remains intuitive, maintainable, and consistent between plugin formats. I’ll update this thread once we’ve made some progress. > [@eyalamir](#): > > using VersionHint failed for us in Logic This is surprising. The whole reason that VersionHint exists is for Logic/GarageBand compatibility. Any chance you could post an example of the code you tried? If it’s a bug on our side, we should fix it. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 18, 2023, 5:04pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/11 "2023-10-18T17:04:05Z")
> [@reuk](#): > > This is surprising. The whole reason that VersionHint exists is for Logic/GarageBand compatibility. Any chance you could post an example of the code you tried? If it’s a bug on our side, we should fix it. Sure, unfortunately this was several months ago and we’re gearing for a release now and can’t take too long away from it. The basics of what happened was: 1. We had parameters in groups using nested subgroups as well. 2. We added a parameter with VersionHint = 2 and immediately got a report from a Logic user. 3. After a bit of experimentation we’ve found some way that works with Logic with flat groups, but that broke sessions in all other DAWs. 4. After some trial and error we’ve found the only way that works across all hosts and formats, including AUv3, VST2, etc is to remove groups and add parameters at the end. To do it logically using structs/vectors we’ve also added a “ForwardingParameter” class so that our parameters could still be logically organized but there’s one flat list of forwarding parameters that report to the host. > [@reuk](#): > > I spent a bunch of time investigating this, and came to the conclusion that when Logic stores automation, it always uses the index of a paramete This is exactly what we experienced. The problem as I understood it at the time was that if you’re using ParameterGroups, which in JUCE are owning the parameters and forcing the parameters at certain index position, it’s very difficult to find a way to force the index to be in order, especially if you have 5 new parameters coming in at version #2 and not just 1 new parameter. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [October 18, 2023, 5:28pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/12 "2023-10-18T17:28:45Z")
> [@eyalamir](#): > > We had parameters in groups using nested subgroups as well. What do you mean by “nested subgroups”? The docs for AudioProcessorParameterGroup explicitly mentions that a group may not contain inner groups when building for AU: ```auto @param subgroupSeparator A separator string to use between the name of this group and the name of any subgroups if this group is flattened. AUv3 and VST3 plug-ins can have multiple layers of nested subgroups, but AU plug-ins cannot have any subgroups. ``` I just tested out the DSPModulePluginDemo\_AU in Logic 10.7.9: - I built the plugin, loaded it in a project, and then saved some automation using parameters from multiple groups: ![Screenshot 2023-10-18 at 18.15.41](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/4/0/40e448306625b20dc06f92ef358d993bd4c4ed9a.png) - Then, I modified the DSPModulePluginDemo.h to add a parameter named “Dummy” with a version hint of “2” to every parameter group. - Finally, I rebuilt and loaded the DSPModulePluginDemo, and confirmed that the same parameters were automated in the new version of the plugin: ![Screenshot 2023-10-18 at 18.20.43](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/2/8/281ca56ff1be0bacb64223fcb0cdd575d56bb590.png) So, it looks to me like the version hint does work as expected, even with parameter groups. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 18, 2023, 5:48pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/13 "2023-10-18T17:48:17Z")
Our real plugin had something that looked like (simplified) ```auto Kick Group: Volume (V1) Pan (V1) Mono (V2) Snare Group: Volume (V1) Pan (V1) Mono (V2) Master Group: Filter Cutoff (V1) Filter Reso (V2) ``` So V2 had more than one parameter added, and that’s where things got confusing/buggy. Also, as I said earlier - in some combination of groups and version hints we did get version hint to work and be stable in Logic (don’t remember which one it was). But it then failed in Cubase and failed in VST2 hosts. Because we deliver our plugins to multiple formats from a shared codebase, a solution that won’t work with AUv3, won’t work with VST2, etc is not a viable solution for us. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [November 10, 2023, 9:02am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/14 "2023-11-10T09:02:53Z")
To get back to the point. The whole fuss is because Logic relies on the index instead of the ID in the automation? Yes? Then it would be cool if that was fixed in Logic. @mfritze ---
**Author:** ![gustav-scholda](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gustav-scholda/32/4172_2.png) [@gustav-scholda](https://forum.juce.com/u/gustav-scholda)\ **Post date:** [November 10, 2023, 11:10am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/15 "2023-11-10T11:10:57Z")
I don’t think this is going to happen soon though… The only way you can avoid any issues is sticking to index and ID. It’s not hard to add parameters to the end, and it doesn’t hurt. ---
**Author:** ![mfritze](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mfritze/32/9008_2.png) [@mfritze](https://forum.juce.com/u/mfritze)\ **Post date:** [November 10, 2023, 11:46am UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/16 "2023-11-10T11:46:41Z")
The issue is backwards compatibility and from the plugin side it is avoidable: you can avoid changing parameters in a way that the index changes – annoying, but possible and most plugins have no problem with it. ---
**Author:** ![dev1am](https://avatars.discourse-cdn.com/v4/letter/d/6f9a4e/32.png) [@dev1am](https://forum.juce.com/u/dev1am)\ **Post date:** [December 22, 2023, 3:01pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/17 "2023-12-22T15:01:09Z")
The trouble is the backwards compatibility also from the plugin side. For flat parameter list, it’s easy to add new parameter to the end, but for more complicated architecture, this isn’t so easy. Currently, every time we add new parameters, we broke the compatibility with param automations of previous version. ---
**Author:** ![gustav-scholda](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/gustav-scholda/32/4172_2.png) [@gustav-scholda](https://forum.juce.com/u/gustav-scholda)\ **Post date:** [December 22, 2023, 3:16pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/18 "2023-12-22T15:16:35Z")
No matter how complex the architecture, it shouldn’t be hard to add parameters to the end. Otherwise the architecture needs refactoring. I’d rather have a bad sorted list of parameters than breaking compatibility. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [December 22, 2023, 4:13pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/19 "2023-12-22T16:13:36Z")
What annoys me the most is that the newly introduced IDs were supposed to simplify maintainability. Now it’s the other way around, it’s even more complicated and cumbersome. Renaming or adding a parameter can mess up the automation in Logic. And since Logic is very important, you can’t ignore that. If we had just stuck with the flat parameter list it would be less of a problem. The VersionHint “fix” has an unsatisfactory workaround to the original problem @mfritze I understand the problem, but Logic could also save the ID (or hash) and prioritize it in newer versions. So there is the chance we can one day forget this problem 😉 ---
**Author:** ![mfritze](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mfritze/32/9008_2.png) [@mfritze](https://forum.juce.com/u/mfritze)\ **Post date:** [December 22, 2023, 4:32pm UTC](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232/20 "2023-12-22T16:32:59Z")
Yes, supporting everything AUs can do is clearly better, but Logic, etc. simply do not support everything. Maybe in the future, but realistically almost no existing AU requires it and with the limited amount of engineering time, as we all know, it is tricky to pay for this, especially that this has impact on the file format. [Next page](https://forum.juce.com/t/audioparameter-versionhint-in-updated-product-does-this-work/53232.md?page=2)