Restrictions of AudioParameterFloat/Bool/Choice


#1

One of my favorite new features in JUCE 4 is the AudioParameter classes - however there seems to be a major shortcoming with them. Things like getting the raw normalized value and setting the unit label seem to be arbitrarily made private without any way to access them either during or after construction. It seems like it would make a lot more sense to make them either protected (so I can subclass and set the values myself) or make public methods to set these. As it stands now, it seems the only answer is to copy and paste the classes over to a new file in my own code and change the implementation myself, but obviously this is far from ideal.

I noticed these values seem to be able to be accessed/modified via the AudioProcessorValueStateTree class, but accoring to Jules in another thread (http://www.juce.com/forum/topic/how-use-audioprocessorvaluetreestate-along-audioparameterbool/float/choice) the value state tree and AudioParameter classes are meant to be different ways of implementing audio parameters and aren't really related.

tl;dr Why do the AudioParameterFloat/Bool/Choice classes have so much of their functionality made private for seemingly no reason?

Thanks!


Is AudioProcessorParameter compatible to an AudioProcessorValueTreeState
#2

Well, the rule when writing APIs is that the public interface should be as small as possible! It's easy to change your mind and make something public, but going the other way is harder..

In the case of the bool/float/etc classes, they're designed to be simple, and I hid as much as possible to avoid beginners getting confused over how to use them. If you need to tweak the raw parameter values as well as their normalised values, then maybe you have a use-case that goes beyond their limits, and you should be writing your own class instead? There's very little code in there, and I expect many people will want to use their own classes.

There is an argument for making the getText method public though.

But with the ValueTree one, it's all deliberately hidden away - the point of that class is that your program interacts with the ValueTree, not the parameter objects themselves.


AudioParameterFloat
#3

That clears things up, I was approaching these as being full-featured parameter classes which is why I was getting confused. I'll copy them and complete them to fit my use case.

Thanks Jules!


#4

Actually I was surprised when I had errors because of the private class members. I just need to inherit AudioParameterFloat class. Copy and paste these classes is not the way we shouldn't to do becuase (as you know), when somebody change someting in these classes we need to copy and paste again. Please make them protected. 


#5

I know this is an old thread, but +1 for making those methods public.

Keeping things simple is nice, but I think those private methods are making stuff more complicated. Why?
Consider me a newbie to JUCE who just opened audio plugin demo. There we have a ParameterSlider class which takes AudioProcessorParameter as an argument. AudioProcessorParameter has public getText() method, and this method is used for drawing the name of the parameter in the editor.

Now, I will create something similar called ParameterSwitch (e.g. mute button), but I know I want only AudioParameterBool instances in there. Whoops. I can’t. Why? I can’t call getText() now. After digging into the code I’m literally disappointed why the heck are those methods private and I’am forced to spend a hour copy-pasting all parameter classes just to make those methods public, or I have to write ugly downcasts. (This is actually what I experienced :slight_smile: ).

I think either those methods should be set protected in AudioProcessorParameter (so it’s hidden regardless you cast or not) or made public in the bool/int/float/choice classes (so it’s accessible regardless you cast or not).