We are removing AudioProcessor-based parameter management

  1. Might be nice to have exact timeframe for a release it’ll be removed (eg. with removing 10.6 support).

  2. In the meantime if you want to keep it functional but be more agressive in warnings jassertfalse on those calls would be fine.

  3. Removing this code would be wise only after some time and feedback. A nice example is AudioProcessorValueTreeState .

  • it has been here for few years now.
  • it still got some quirks with thread-safe (some was ironed out on latest dev) issues.
  • undo/redo isn’t fully reliable.
  • it took some time to get Category and Meta-Parameters to be supported by it.

It might be nice to get it started on dev branch and get feedback as you go before completely removing it.


I agree. The removal will not be sudden and without notice - this is just the first warning that things will be changing.

The first thing to do is to implement “managed” parameters from the host’s perspective. At the moment there’s no other way to access parameters, so I’m reluctant to mark the methods as deprecated until that’s done.

1 Like

I think it goes the right direction. What is to be expected in the VST3 and VST2 hosting code? That they will use the void addParameter (AudioProcessorParameter*) and const OwnedArray<AudioProcessorParameter>& getParameters() methods instead of overriding all the setParameter(int) getParameter(int) … methods?

Yes, that’s the general idea.

Will this work also include splitting the concept of a parameter and a meter?
As much overlap as there is between the two, I think it would make more sense to have a separate meter object which the wrappers can handle separately from the parameters.

And is there any chance of extending/replacing the isOrientationInverted() method so that we can give AAX hosts more specific orientations?


Sorry this should probably be a seperate thread but I would second the work of separating the meter and parameters, it’s annoying that getting the number of parameters is really the number of parameters plus the number of meters, in my mind they are separate concepts.

Sorry to jump on the band-wagon but while we’re making such suggestions, I would also suggest some ability to mark a parameter as a bypass parameter. The Wrappers could check if any of the parameters are the bypass parameter and pass that one to the host as the bypass parameter rather than the wrappers always adding their own one. This is particularly useful when you are porting plugins to JUCE.

I realise this work would be a step or two on from the work being proposed here, but while your in that area of the code I think these could be some worthwhile improvements.

1 Like

So as of today, is AudioProcessorValueTreeState still the recommended way for plugins and parameters?

Is fixing AudioProcessorValueTreeState (regarding undo/redo for instance) your top priority regarding plugins, or are there other improvements/new features that are prioritized before fixing the current bugs?

1 Like

Fixing some AudioProcessorValueTreeState issues is at the top of the todo list.


Wouldn’t it make sense, if the Attachements directely refer to AudioProcessorParameter… that makes them generally usable

Hi, is a side-effect of this change that setParameter() is no longer called when the host changes a parameter? A bit confused

Yes. The setParameter (index, newValue) method will, ultimately, be removed from the AudioProcessor class. Instead the host will call setValue (newValue) on the parameter at position index in your array of AudioProcessorParameters.

If you want to restore the old behaviour you can add a set of parameters which simply forward these calls back to your AudioProcessor

struct WrapperParameter   : public AudioProcessorParameter
    void setValue (float newValue) override   { yourAudioProcessor.setParameter (getParameterIndex(), newValue); }

and the same with all the other methods.

1 Like

got ya, thanks

i was also wondering if there will be any way for a host to access the parameter id. it might be beneficial for storing/restoring.

1 Like

Hi @t0m - if we do override in this way we can’t call the base functionality as it’s all private - should these functions be changed to be protected or am I missing something? thx

What base functionality? All of those methods are public.

Hi - I’ve derived from AudioProcessorInt etc. in my code, not from AudioProcessorParameter.
However, looks like theres a valueChanged() override which I can use to achieve the same thing, although in valueChanged() I get a version of the parameter that has gone through a call of convertFrom0to1() and I can’t call convertTo0to1() to get it back into a float as it’s private.

Maybe I’m going to have to rework things.

I don’t think you want to do that in this case, just derive from AudioProcessorParameter. It’s just forwarding the calls from one to another, there’s no need to use things like AudioProcessorParameterInt because presumably your AudioProcessor is already reporting all the right information anyway.

Thx. I’ve been using AudioParameterChoice so so I can get the host to display choice strings instead of numbers. I’d have to implement this functionality myself if going direct to an AudioProcessorParameter.

With alot of the derived helper classes being private it seems there’s work to be done somewhere along the line.

So were you overriding setParameter() despite adding AudioProcessorParameter objects?

1 Like