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.
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?
Are you using AudioParameterChoice without calling addParameter (yourChoiceParameter)?
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.
Usine also supports the dynamic parameter lists from Kontakt and Reaktor quite seamlessly.
But Reaper shows 1000 parameters for Reaktor, even if most are unused. That suggests that there is a way to just hide parameters, but some hosts donāt respect it? Reaper does rename the parameters just fine.
I am looking for a reference implementation to handle plugin parameters in Juce. Plugins Examples from the Projucer seem to use a few different methods (AudioParameterFloat, ValueTree, AudioProcessorValueTreeState, ParameterLayoutā¦).
Is AudioPluginDemo the reference code to follow ?
@t0m, do you know when old AudioProcessor-based methods (e.g., setParameter (index, newValue) ) will be definitely removed from Juce ?
Thanks
