We are removing AudioProcessor-based parameter management

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

7 Likes

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

Are you using AudioParameterChoice without calling addParameter (yourChoiceParameter)?

1 Like

Well, those are the two different ways of asking the same thing!

2 Likes

addParameter() is being used to add the parameter(derived instance of AudioParameterBool/Int/Choice). This got me the functionality of providing choices and on/off in the host.
I’d used the old parameter system before moving over to this one (about a year ago??) and that was using setParameter to process updates from the host. This still worked after moving over to all addParameter() so this is how things have stayed. I guess at that point I should have reworked that but everything I needed worked. With the latest pull the calls to setParameter() are no longer being made so I’m just trying to get that up and running quickly (dirtily? :slight_smile: ) - I probably should take the time to sort out the hashed approach I’ve had since the last set of parameter processing changes

Will we receive a removeParameter() as well then?

Which hosts support dynamically adding and removing parameters again?
I think, somebody mentioned once one…

removeParameter() is, unfortunately, a huge can of worms and not well supported by hosts. The proposed change would make it a little easier, but it’s not something we’ll be working on anytime soon.

We’re hitting this issue with the current ordering of parameters in AU (especially the list of 8 “Smart Controls” presented in Logic Pro). We need to strategy to fix this while also being able to merge the suggested changes above in related to parameter IDs.

I’d like to fix this by patching our copy of JUCE while being able to remove this patch at a later date without breaking customers projects! Can the JUCE team offer any advice?

Plugins like Kontakt and Reaktor re-organise the parameter list every time you load different ensembles, instruments etc and these are picked up happily by Live, Logic and I presume other DAWs.

There doesn’t appear to be anyway to easily provide this kind of functionality with JUCE?

4 Likes