# NormalisableRange suggestions

NormalisableRange needs an option to store a normalized logharitmic value (e.g. for Frequencies)

Here is some sample conversion code from my internal library to store frequencies in a normalized range between 0.f and 1.f

``````class LogFrequency_normalized
{
public:
LogFrequency_normalized(double minFrequency_, double maxFrequency_)
{
setMinMaxHz(minFrequency_, maxFrequency_);
};

void setMinMaxHz(double minFrequency_, double maxFrequency_)
{
minFrequency=minFrequency_;
maxFrequency=maxFrequency_;
minFrequencyLog=log(minFrequency_);
maxFrequencyLog=log(maxFrequency_);
};

double getFrequency(double normalizedLog)
{
return exp((normalizedLog*(maxFrequencyLog-minFrequencyLog))+minFrequencyLog);
};

double getNormalizedLog(double frequency)
{
if (frequency<=minFrequency)
{
return 0.;
} else
if (frequency>=maxFrequency)
{
return 1.;
} else
{
return (log(frequency)-minFrequencyLog)/(maxFrequencyLog-minFrequencyLog);
};
};
private:
double minFrequency, maxFrequency;
double minFrequencyLog, maxFrequencyLog;

};``````
3 Likes

Hi chkn,

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!

Ed

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

0=100Hz
0,2=200Hz
0,4=400Hz
0,6=800Hz
0,8=1.6 kHZ
1,0=3.2 kHz

How to achieve something like that with NormalisableRange?

1 Like

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.

Try
y=mx+b
equation

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.

1 Like

bump, bump, bump… and bump

1 Like