On Sun, Aug 17, 2014 at 06:34:25PM -0700, Len Ovens wrote:
> I would think ((Gain+54)/64)*7f uses a lot less CPU time than a real
In the equation you mention, 'gain' is in dB, it doesn't make any
sense otherwise. So after applying the inverse of that equation
you need to convert from dB to a linear gain value.
If M is the value sent by the controller (0..127) and G the gain
in db then
G = (64 * M / 127) - 54
which will be in the range -54..+10 dB. M = 0 is probably interpreted
as 'off' instead of -54 dB as a special case. Step size is 64 / 127
dB or 0.504 dB.
A slightly better mapping would be 80 step of 0.5 dB for the
range +10...-30, then smoothly increase the step size to arrive
at a minimum gain of -70 dB or so. Even for this the calculations
There is no problem with CPU use. On the sender side you transmit
0..127 which is just 7 bits of an ADC measuring the voltage from a
linear fader or pot, there is no mapping at all.
On the receiver side, the conversion needs to be done just once
per 25 ms or so and only when the gain changes. Then interpolate
linearly in between, or not at all if the value hasn't changed.
The resulting CPU load is absolutely irrelevant compared to what
has to be done anyway.
As an example, my 4-band EQ LADSPA does this sort of calculations
for each of its 13 parameters. And calculating the internal filter
parameters is a bit more complicated than dB to linear. It makes
no difference at all in CPU use which is dominated by the per-sample
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Linux-audio-dev mailing list