We are removing AudioProcessor-based parameter management

Audio Plugins
1

This is some advance warning that we will be removing the old way of managing audio parameters.

Methods such as

AudioProcessor::isParameterDiscrete (int parameterIndex)
AudioProcessor::beginParameterChangeGesture (int parameterIndex)

and all the others which act on a specific parameter will be stripped from the AudioProcessor class.

If you are a plug-in developer you should create your parameters and add them to the processor using AudioProcessor::addParameter, or use the AudioProcessorValueTreeState.

If you are a plug-in host developer then this change will affect you more. Currently most host-side parameter interactions rely on these deprecated functions, and we will be rolling out functionality to fetch an array of parameters from an AudioProcessor (similar to the case on the plug-in side of things). In places where you are currently doing things like

processor.beginParameterChangeGesture (parameterIndex)

you will need to switch to the new system, which will have an interface similar to

param.beginParameterChangeGesture()

where you will have fetched param from the list of parameters.

The aim of this bit of work is to both remove some bloat from AudioProcessor and make it much easier for the plug-in wrappers and hosts to obtain information about the parameters. The AUv3 wrapper has a few problems which can only be addressed in this way, and things like exposing parameter groups to both hosts and plug-ins will be simplified.

If anyone thinks this is a really bad idea then please let us know. This is a sizeable chunk of work so it’ll take us a while to get everything implemented.

6 Likes
2

not afraid with the api-changes itself,
the problem is mostly with legacy plugins, which need to be updated, and then again -> unwanted side-effects or very subtle behaviour changes which can create new bugs.

I just want to say, please be very careful :slight_smile:

2 Likes
3

i really appreciate the change! will the new parameter system support IDs?

4

I was secretly hoping this day would never come :slight_smile:

Note that those methods have the following comment :

NOTE! This method will eventually be deprecated!

So before you remove them you may want to actually mark them as deprecated for some time.
Last year I did a poll about plugin parameters (here), and 26% were still using custom parameter classes not inheriting AudioProcessorParameter. When using such custom parameters classes you can’t simply call addParameter(). Changes are much bigger, do not underestimate them please.

4 Likes
5

This will be a huge amount of work for some of us… and a longer lead time would be appreciated. My plug-in includes about 15 or so AudioProcessors and AudioProcessorValueTreeState wouldn’t really benefit them. Of course, until I see what you’re going to change… this may not affect me as much as I imagine it will

Can we get a “dislike” button?

Rail

2 Likes
6

Also keep in mind what we’ve been through :

  • Custom parameters classes.
  • Then AudioProcessorParameter.
  • Then AudioProcessorParameterWithID.
  • Then AudioProcessorValueTreeState.

Now after a year or two that the recommended way is AudioProcessorValueTreeState, it still does not work properly. I know you do your best, but understand that this is a bit annoying, and that people are still reluctant to drop their custom classes until they see a lasting stable solution. When such a solution is here, then only you can consider to mark those methods as deprecated imo.

11 Likes
7

This is a really bad idea.

1 Like
8

What would need to be added to the AudioProcessorParameter class to enable a seamless transition?

We will add a virtual method for generating a parameter ID, so that your parameters can be correctly recalled by a DAW.

Here’s a related topic: AU Parameter Order

1 Like
9

  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.

2 Likes
10

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
11

Hi
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?

12

Yes, that’s the general idea.

13

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?

3 Likes
14

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.

3 Likes
15
1 Like
16

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
17

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

7 Likes
18

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

19

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

20

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