Breaking Change: Hosted AudioProcessorParameter improvements

This commit

populates the AudioProcessorParameters of a hosted plug-in with all the information available when you are implementing an AudioProcessorParameter. This means that it is much easier for hosts to present a more comprehensive interface to a plug-in’s parameters. We’ve used this extra information to improve the GenericAudioProcessorEditor class, as shown in JUCE’s Demo Host below:

For an example of how to use hosted AudioProcessorParameters you should have a look at the source code in modules/juce_audio_processors/processors/juce_GenericAudioProcessorEditor.cpp.

This commit also deprecates all the AudioProcessor class methods which take a parameter index as an argument (such as const String AudioProcessor::getParameterName (int parameterIndex)) when hosting plug-ins. No changes are required if you are implenting a plug-ins. Unfortunately it is impossible to deprecate these methods and issue only a compile-time warning, so a single assertion is fired the first time you use one of the deprecated methods. To continue to use the deprecated methods you’ll need to push past this assertion in your debug builds, or temporarily disable in by modifying JUCE’s source code.

The motivation for this change is reduce the size of the AudioProcessor class. Not only will this improve the interface, it will also make ongoing development much easier; as it currently stands any changes relating to parameters needs to be duplicated in the AudioProcessor and AudioProcesssorParameter classes. Even now some functionality is only available through the parameter classes and the gap between the two ways of doing things is only going to widen when we add things like parameter groups. This is the first step towards this goal; the next is to deprecate the same AudioProcessor methods when implementing plug-ins too.

Summary: When hosting plug-ins you should use the AudioProcessor::getParameters() method and interact with parameters via the returned array of AudioProcessorParameters. If you don’t you’ll need to push past an assertion in debug builds.


The above commit also includes parameter information parsed from .vstxml files accompanying VST2 plug-ins.

Just stop.

This is the FOURTH JUCE attempt in about as many years at getting plug-in parameters right and at this point I have ZERO confidence in it doing anything except breaking a lot of code and creating headaches for people who have legacy plug-ins to support. As lalala said:

Don’t give us another 90% “solution” and forcibly break things for those who have rolled their own custom classes that work 100%.


perhaps if the JUCE team were willing to publish the proposed changes to an experimental branch, as it was done for the (second) implementation of the multibus support, that will give developers a better chance of testing with their code, raise concerns, propose solutions etc.


I think you’re being a little hyperbolic. Can you provide an example of something that wouldn’t be possible using an AudioProcessorParameter base class?

If you look at the implementation of all the parameter based methods in AudioProcessor you’ll see that all the arguments are forwarded to the corresponding parameter class; there’s a one-to-one mapping between the two. If the soon-to-be-deprecated methods were removed you could even have an empty parameter class that simply forwarded the parameter methods back to your AudioProcessor subclass, recreating the old methods.

Adding proper support for hosted AudioProcessorParameters involved a lot of new functionality (not previously available), but now that’s in place deprecating the AudioProcessor methods is more a reorganisation than anything else.


curious if you found any plug-ins that use .vstxml ? don’t think I saw one in the wild

None directly from the plug-in developers.

1 Like

also worth considering - cockos have some extensions to vst2 that make automation editing nicer in reaper -

Added last week!

… which is also a great example of a development which is not possible using AudioProcessor based parameter methods.

We’ve not yet added the host-side version though. It’s something I’ll be looking at shortly.


See this thread for an example: New Parameter API: potential big problems arising

Curious why you think this is “not possible” using AudioProcessor based parameter methods. Imagine my surprise to find out my custom parameter classes do the impossible!

What I should have said, much more carefully, is that if you provide a simple implementation of all the virtual AudioProcessor based parameter methods then you would have a functional plug-in, but you would miss out on the Cockos VST extensions - you would have to provide these yourself as it’s not possible for JUCE to supply this information using the old interface. You can, of course, do all sorts of things if you are handling VST opcodes yourself, but as a JUCE development it’s not possible to handle these inside the framework.

If, however, you use the AudioProcessorParameter interface then you get the Cockos extensions automatically, without having to know anything about the VST communication protocol.


For in-service plugins that get updated to newer Juce SDK versions, is the advice to just leave them as they are because any removal of support for the old approach following deprecation is a long way off, or should an attempt to transition to the new way be made reasonably soon?

If it’s the latter, a simple transition guide could be useful.

It feels like the sort of thing that will likely end up having a lot of peculiar little corner cases come up in some hosts presenting complications with old saves for some users, etc etc, so could require a lot of time consuming testing. Being able to keep old projects on the old technique feels quite appealing, so understanding the roadmap here would be great.


I would also like to hear some advice from @t0m regarding @hill_matthew 's questions.

Yesterday, I just updated an older project to Juce 5.3.1 (last version I worked with was 5.2.0) and I’m seeing lots of “declared deprecated” warnings for the base methods getNumParameters, getParameterName, beginParameterChangeGesture, etc…

The plugin appears to work, but as @hill_matthew I would like to know if functionally anything could be wrong if I leave the warnings as they are?
Can I safely release a plugin like this, or are there things that must be changed (and if so: what)?

I read the “breaking changes” file, but that only seems to talk about “hosting plugins”:

When hosting plug-ins all AudioProcessor methods of managing parameters that
take a parameter index as an argument have been deprecated.

Possible Issues
A single assertion will be fired in debug builds on the first use of a
deprecated function.

Are there things plugin developers must change since 5.3.1? Or can we still keep using the “classical” parameter methods in all safety?

Thanks for clarifying!

1 Like

It’s completely safe to continue using the deprecated methods, and you can even disable the warnings with the JUCE_NO_DEPRECATION_WARNINGS macro (with some obvious downsides).

There’s no firm timeline for the removal of these methods; we’re conscious that this will affect a significant number of people and we’re going to give people plenty of time to adapt.

1 Like

@t0m with index usage being deprecated, will AudioProcessorEditor::setControlHighlight be updated to pass in the parameter ID instead of the parameter index? In turn, will the counterpart AudioProcessorEditor::getControlParameterIndex soon return a parameter ID?

I guess the index itself isn’t deprecated, because you can still quickly reference the parameter by index using the OwnedArray from AudioProcessor::getParameters() internally. VST2 for example only uses the index.

The ID is currently important for saving/load the current state, so theoretically in the very far future, if you don’t use a plugin format which is using the index like VST2, you may reorder the internal parameter-positions from one version to another, and the ID makes sure that after restoring or while using parameter automation the values stay correct.

The future is already here: AU Parameter Order
Unfortunately not in our favour, since AU hosts (at least logic) seem to sort by the hash value of the paramID.

I don’t know, if anything has improved… the forum doesn’t really support tracking issues that well…

1 Like

yes, but if you generate multiple plugin formats including VST2, you can only use the smallest common denominator, which is in VST2, so fixed internal parameter ordering.

yes, I got the intention, but the feature turned into a problem… excuse my sarcasm in the previous post :wink: