Let’s say you release a plugin (VST3/AU/AAX), and in future you want to add another dial to it.
Do all hosts cope ok with this? Are there any big gotchas to watch for? Should I add a bunch of empty placeholder parameters for future expansion? Anything weird happen with automation?
Thanks!
(I’m already using AudioProcessorValueTreeState and haven’t seen any issues during development on Reaper or Ableton Live, but not sure if other hosts are trickier…)
…found this: JUCE: AudioProcessorParameter Class Reference
anything else I should look into?
can also confirm no problems in bitwig and cubase in regard to adding parameters post release or changing parameter ranges
firstly - consider not doing that. Because it can be very disruptive, destructive even, for an artist to load a session and then have your plugin output a different sound than it did last week.
secondly - if you have to change the functionality of your plugin, ensure that when you load an old preset that the new parameter is initialised to some default value that does not alter the sound in any way compared to the old version of the plugin.
good to know, thanks!
oh, no intention on changing the sound of any existing plugin feature after release! this is for exclusively new features.
i have some ideas i’ve run out of time to implement that i’m pretty sure i’ll add at some point. in one plugin, i’ve gated those behind some switches that are already in the parameter model but not exposed in the UI. if they do somehow get set (through an automation parameter or FL Studio randomize params or something) i have a little warning that shows up on the UI saying a hidden parameter is set and that sound may change in a future version. in my other plugins i’ll just add them as needed, from the sound of things.
If you are releasing an AU for use in Logic or GarageBand then make sure you increment the version hint to your new parameters! (see more info here JUCE: HostedAudioProcessorParameter Struct Reference)
The other thing to consider is both backwards and forwards compatibility. Imagine customer A starts a new session with the version of your plugin containing the new parameter. They save the session and send it to customer B. Customer B has the older version of your plugin, they open the session, maybe even try to change the parameters, then save it and send it back to customer A.
There’s a couple of ways I can think to deal with this.
When Customer B open the plugin they are informed it was saved using a newer version and are promoted to update. In this case you’ll need to make sure the latest version is compatible with all the same OS versions as the older version or the user may be stuck with an annoying message that they can’t act on.
The older version is able to load and save the new parameter even though it will obviously ignore the parameter in use.
I’ve always gone with option 2, but both cases require some forward thinking to ensure the originally released version can handle this.
Can’t highlight this bit of advice enough!
Another advice: store the version in the preset files and include the date in the version number (eg. 20250623). I find it very useful to deal with old presets later on and to understand which binary opens what version.
Also : using audio processor parameter groups ( AudioProcessorParameterGroup ) will affect your ability to add new parameters plugin release without breaking automation in many hosts as the new parameters will not be appended to the end of the linear parameter list, but somewhere in the middle.
I’ll just rely on a regular update check, I think.
And yep, thanks for the note on the version hint!
Just using AudioProcessorValueTreeState and ParameterLayout here - didn’t even know about that AudioProcessorParameterGroup functionality, guess I’ll dodge it! Thanks.
