The NormalisableRange class is designed to be used in an arbitrary manner with templated values and leaves the implementation of specifics, such as logarithmic values, up to the user. Thanks for the suggestion though!
Sorry not sure if you really understand the usecase?
If i look into NormalisableRange it seems the value is transformed into some kind of polynomial(?) (fixed exponent) way (when using skew Factor), which is transformed into a normalized range, but for frequencies we usually need to transform the frequency into a logarithmic (fixed base) way, so that e.g. every octave has the same distance
An example, we want to store a frequency which we know is always between
between is 100Hz and 3,2KhZ.
the normalized logarithmic representation would be
I don’t think it’s possible. You can get the center frequency right, but the rest is still off. I really liked the suggestion made by Anthony_Nicholls here: Suggestion: Replace skew with lambdas
Lambdas would be great. I know, it’s a problem with backwards compability. But I liked the JUCE_COMPILER_SUPPORTS_LAMBDAS solution.
Well the math is not the problem, in the first post there is the solution. I thought this is just missing in the NormalisableRange. I already use custom classes for parameter storing, but for the long way I may switch to AudioProcpsserparametetValueTree so I think this could be a nice addition.