Re: gain-mapping - was Re: OSC next
Melanie Bernkopf <[email protected]> Sat, 14 May 2016 16:27:17 +0200
| Newsgroups | gmane.comp.audio.ardour.devel |
|---|---|
| Message-ID | <CA+L_jCtTgoEQREh22GkETj3x4YEzjZcXXv5P=7S32-Tjb5ZipQ@mail.gmail.com> |
1260 is doable that´s no problem. Problematic it get´s when floating point needs to be done but that is the problem with all micro controllers. 2016-05-14 14:40 GMT+02:00 Robin Gareus <[email protected]>: > On 05/13/2016 08:53 PM, Len Ovens wrote: > > On Fri, 13 May 2016, Melanie Bernkopf wrote: > > > >> yes I can only give a full ack to this it is just mimic of the > >> position and not about gain or DB. > > At first thought, I think this is not a good idea. > > It would limit the control surface to the same fader-deflection which > Ardour chose and does not expose any actual relevant numerics. > > But the lack of a well defined "no gain" 0dB point is the most obvious > flaw. > > > > Internally Ardour uses a floating point gain-factor (coefficient) for > both: state and processing. Resetting a fader sets it exactly to 1.f and > the control has a detent (in the GUI) because it is impossible to > otherwise reach this point (With integer ratios 41 bits of precision are > required for the power law to result in exactly 1.f). > > > Yes and no. With either gain or dB I can remotely say I want x amount of > > gain. It is easy to put a button in that zeros a fader with either dB > > (send 0) or gain (send 1.0). It is impossible to do that with 1023 INT. > > 800 comes closest at 0.006990539841353893 dB. (Using two surfaces one > > with int1024 and the other with dB, setting position to 799, 800 or 801 > > and seeing what Ardour sends to the other surface) > > +1 for testing the whole system. That's very good practice and pretty > much the simplest way to find out how rounding (and float > parsing/precision) behaves. > > Here's the math for completeness: > > With fader position 0 <= p <= 1.0, Ardour calculates the gain as follows: > > $g = 2^{\frac{1}{6}(-192 + 198 \sqrt[8]{p})}$ [1] > > The inverse of which is > > $p = (\frac{1}{198} (6 \log_2(g) + 192))^8$ [2] > > > At unity gain, [2] evaluates to (192/198)^8 = (32/33)^8 > > You'll need to add a factor much much larger factor than 1024 to > represent unity gain with an exact integer. > > <details> > As you can read in the source [3], the gain/fader-position relation is > derived from measuring a console fader. The intended range is 0..2 > (-inf, +6. dB) which is reflected in the base of the logarithm, but the > actual range is configurable(!). > > The initial polynomial fit (old gain math) had a problem that inverse > function had a large error and f(f^{-1}(x)) was off by a few dB for > smaller values of x. The power-function is a close approximation of it > though. > > $ gnuplot > set key horizontal top left > set ylabel "dB" > set xlabel "% fader" > set samples 250 > plot[0:100][-200:6] 20 * log10 (2**((198 * (x / 100)**(.125) - 192) / > 6)) t "Ardour fader" > > > Also note that granularity of the fader position p is not fixed in > Ardour. Fader length scales with the GUI, and the fine-grained mode is > constrained by a gtk adjustment. Default GUI granularity is 250 * > ui_scale (rounded to px), hence "set samples 250" in the plot, With > "Keyboard::GainExtraFineScaleModifier" Ardour increases granularity by > a factor of 200 to a total of 50K steps with default GUI scaling. > </details> > > > > So with dB, I can on > > the surface enter as text an exact gain in dB. Also, the text value on > > the surface shows the value in dB which is much more useful to the user > > than some number from 0 to 1023. > > exactly. > > > However, are there any OSC controllers out there that can provide a > power-law fader? > > As far as I know the answer is no. Furthermore neither log-scale (dB) > nor linear (coefficient) are appropriate for a fader. > > > One way would be to add a *new* interface specifically for OSC with the > following properties: > > - power-scale - similar to Ardour's Fader > - 0dB can be represented by an integer fraction with small denominator. > - the range is independent of Ardour's max_gain configuration > - relatively simple relation to dB. > > One candidate that fulfills these criteria is > > $g = (1.26 p)^3 ; 0 \leq p \leq 126; p \in \mathbb{Z}_{\geq 0}$ > > with x = 100 / 126 this results in a gain = 0dB > and x = 126/126; gain ~= +6dB > > This could also be mapped to MIDI 0..127 with a small overshoot (1.26 * > 127 / 126)^3 = 6.23 dB and OSC could use 0 .. 1260 with unity at 1000. > > > This interface would be available in *addition* to a dB interface (two > in total). > > ciao, > robin > > > > The equations in text (non LaTeX) are: > > [1] g = 2 ^ ((198 * p ^ (1/8) - 192) / 6) > > [2] p = ((6 * log(g) / log(2) + 192) / 198) ^ 8 > > [3] > https://github.com/Ardour/ardour/blob/master/libs/ardour/ardour/utils.h > _______________________________________________ > ardour-dev mailing list > [email protected] > http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org > _______________________________________________ ardour-dev mailing list [email protected] http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org