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.
AudioProcessorValueTreeState & UndoManager usage
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
Are you using
AudioParameterChoice without calling
Well, those are the two different ways of asking the same thing!
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? ) - 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?
I am missing support for the ability of AudioUnits and VST3 plugins to group parameters into units. This is to model multitimbral instruments correctly. The DAW, if it supports it (Studio One does) can display automatable parameters in groups then. Juce strips away this information and you end up with the least common denominator.