Parameter ranges


I am evaluating the various juce::Parameter classes.
So far I like the juce::AudioProcessorValueTreeState but it has several limitations.

  • I need several ranges with differing step values, (in audio processing most values are non-linear: static step values are only of limited use here),
  • I need several ranges of scaling curves,
  • I need a generic way for text2float/float2text translations, but the function are static, without any possibility to parametrise those for specific needs. It would be great if class methods could be given, or if there are virtual methods in the parameter class itself which could be overridden.

The reason behind that is that my parameters are coming well defined in an xml description and the plugin itself just generically scan those and builds its set of parameter representations and connects those parameters with GUI elements defined in an .svg file.
This all works, except for those limitation.



We will, eventually, be adding lambdas to the NormalisableRange class to allow arbitrarily scaled ranges. When we do this we’ll also look what other improvements we could make.


Thanks t0m,
lambdas for what? And how would that be allow to be more generic?

But more importantly: what would be the best parameter class to choose as base class right now?



See my suggestions here Suggestion: Replace skew with lambdas

Hopefully that will explain how lambdas can be used to allow for customisable curves.

@t0m can I ask if there is a specific reason why what I posted in the link above can’t be added now? I used an ifdef to prevent problems with backwards compatibility and as far as I am aware it all works correctly. ROLI / JUCE are more than welcome to have and use that code however they see fit.


Thanks Anthony,
yes, lambdas are better than a simple skew factor. But still, lambdas alone cannot be parametrized.
How would you tell these lambdas to use different scalings for different parameters? I understand that you can define different lambdas but that doesn’t allow to be generic.



and more, if those lambdas would be generic you wouldn’t have to fiddle around with the ifdefs since the parameter class could internally use a standard lambda parametrized by a skew factor.


I don’t think that ifdefs were meant as a necessary part of the functional implementation of these lambdas, as I see it they are referenced only as the mean to disable the code that uses lambda for compilers that currently don’t support them


OK. I see. correct. Thanks!

and here additional garbage chars to make this web interface happy.


To deal with the XML I assume there are a set number of curves you want to use. Maybe have a function that can be passed an id (matching the one presumably stored in the xml?) that returns the corresponding NormalisableRange object.


Thanks, Anthony,
thats the “workaround” we are using during development for now. But its not generic to have to write a different function for every use case. Beneath the fact I can’t predict any scaling requirement we have multipart scalings, which have different cross-over points for different parameters. This cross-over is just a value, and does not rectify a new function.
At least those functions/lambdas would need to have a parameter: preferably to the param class itself so they can request whatever parameter property they require. Now with that it actually becomes a parameter class member. So I actually ask for virtual member methods for both “skew” replacement functions and the text2float() and float2text() functions.