How to calculate skew so that theres still a linear scale but differing start / end points on a slider?

General JUCE discussion
1

Im trying to construct a slider where it will move between -18db and +12db, Im using the centred skew calculation but it applies a non linear aspect to the beginning of the range.

Im using something like this:

auto _18db = Decibels::decibelsToGain(18.0f);
auto _12db = Decibels::decibelsToGain(12.0f);
auto range = NormalisableRange {1.0f / _18db, _12db, 0.001f, log(0.5f) / log((1.0f - 1.0f / _18db) / (_12db - 1.0f / _18db))};

I would like the range represented by the slider to be -18db - +12db but in linear increments between them, any pointers on this?

2

Why isn’t the slider configured in decibels directly?

3

Well I can use decibels or gain, that part doesn’t matter as long as the right conversion function displays the labels on the slider correctly (db in this instance), what Im trying to figure out is having an arbitrary range where unity gain or 0db is at the center and min is -18 and max is +12. I can use the setSkewForCentre function on the NormalizableRange:

void setSkewForCentre (ValueType centrePointValue) noexcept
{
    jassert (centrePointValue > start);
    jassert (centrePointValue < end);

    symmetricSkew = false;
    skew = std::log (static_cast<ValueType> (0.5)) / std::log ((centrePointValue - start) / (end - start));
    checkInvariants();
}

but that would mean the increments would be larger on the negative side if I was using -18- +12db on the slider.

4

The other reason, that I just remembered, is so when there is a callback for the parameter changing the value is already in gain rather than db. The db aspect is just for the user whereas IIR filters or other component use a gain parameter rather than db formatted parameter so it makes sense to not have to convert this on the audio side and let the GUI present the value in db on the GUI thread instead.

5

But why do you need to use a normalized range? You can create a linear slider with center skew of any range, and its steps will always be the same.

As for the mathematical problem, it looks complex, maybe someone knows it, but maybe there could be some shortcut to avoid it.