Juce 3.2 AudioProcessorParameter, and deprecated methods

I am new to juce, and few weeks ago I'm testing it, surely I'll buy a license for my new products. I have written some own classes for params and others stuf...

Today I updated to Juce 3.2, and I noticed that PluginProcessor::setParameter, getParameter, getNumParameters, etc, will be deprecated.
I would like to use my own ParamManager class in the future, this class has an array of params, handle normalized and human readable values, enum params, etc... 

So my question is:  PluginProcessor::methods_for_params will be removed in future versions? alternative methods will be added?

Thanks.

 

The old methods will probably be removed eventually, but there's no need for any more alternative methods - the new AudioProcessorParameter class gives you all the functionality that the old methods provided, and more too.

You might just be able to make your own parameter objects inherit from (or contain an) AudioProcessorParameter.

Thanks Jules,

I've created clases for float, enum, bool and int params... I like this way :)

If I may intervene, each one of us is ending up having his our own implementation of the parameter classes… this might, at some point, make things difficult to change, either from the JUCE users we are (upstream code changes breaking things), or from the JUCE maintainers (fear of breaking user code).

To the JUCE maintainers: what about sharing the same parameter implementation at the JUCE level? e.g. optional parameter classes?

Best,

We've got a bunch of new almost-finished utility classes for plugin parameter handling.. Not sure if they'll be released before V4 or not, but won't be too long.

This will include stuff like a ValueTree-based parameter list and some typed parameters with ranges, skews, etc.

@fbecker, it would be great, but as an optional usage. Some other frameworks do all the work, and when you need to do someting specific thing is a mess... for this reason I am moving to juce.

 

 

I'm curious to see the utility classes you mention.

Please consider not deprecating the "old" parameter methods unless/until the AudioProcessorParameters provide a complete implementation of each plug-in format's parameter characteristics.

Right now, the implementation is close to the minimal required subset; that's great for quickly prototyping something but not so great for fully supporting the format-specific parameter characteristics in AU, AAX, etc. as one needs to do in a professional commercial plug-in.

Many of us have built out our own parameter handling classes to support all of the idiosyncracies, and many of us did it before the AudioProcessorParameter classes were added.  It would be a headache to have to redo and revalidate that all a second time if use of AudioProcessorParameters became required, and yet remained incomplete.

Thanks!

Sound promising!

Will the new parameter stuff also include thread-safety (setting/getting parameters from both the audio processing thread and the GUI thread)?

In the current example, param->setValueNotifyingHost is called which directly changes the float value of the parameter, and in the audio thread the processing just uses gain->getValue(). I've done this for simple floats as well, but shouldn't this actually be made thread-safe somehow (or at least copying existing param values at start of processBlock call and working with these, or using FIFO queues for inter-thread communication, or other mechanisms...)? It would be great if this would also be included in the new parameter handling stuff, so that we can just use it without having to worry about this ;-)

 

Yes, our ValueTree-based utility class will take care of all the threading issues (this is actually the same class we use to implement the ROLI Equator synth).

There are other simpler parameter wrapper classes that don't add any thread-handling, but we may add more functionality for that in the future.

Please don't remove the old parameters, otherwise updating old plugins is almost impossible. Just keep them marked as deprecated :)

IMHO the best way it to have free functions that don't care about thread safety and stuff that jwich the KISS interface.

And  then some classes that uses those function in a thread safe manner with some nice object and syntaxic sugar.

 

my 2 pennies

Well, we want to offer a collection of different types of class that people can use in different ways. From simple bare classes that people can combine in custom ways, up to things like the ValueTree-based wrapper that takes care of the whole thing for you.

Thanks! Sounds good to me!

I also understand the worries from people already having built their own true and tested systems, in case the basic/raw parameter functions get eliminated.

The abstract base classes will always be there if people need to do something really customised.

Was this ValueTree-backed AudioProcessorParameter utility class ever published?

Yes! AudioProcessorValueTreeState