[Ardour-Dev] gain-mapping - was Re: OSC next
Len Ovens
len at ovenwerks.net
Sat May 14 11:35:20 PDT 2016
On Sat, 14 May 2016, Felix Homann wrote:
> I must admit I have missed the start of this conversation which is a bad thing to
> begin with. Nevertheless, it might be interesting to know how some common OSC
> controllable hardware is handling faders. So here's how the Midas M32, Behringer
> X32 and X Air mixers handle fader/dB values over OSC:
I would hesitate to call the x32/air "Common" :) The tablet OSC controller
seems to be by far the most common.
> 0. The faders range from -90/-oo dB to +10 dB.
-90 = inf is somewhat limiting (perhaps not in practical terms) as Ardour
can handle db values to less than -200... but we have limited OSC to -192
with -193 or less as inf due to round trip calculation errors below -192
dB.
> 1. Internally fader values are represented as "index" values within [0, 1023].
> 2. The mapping from "index" idx to dB is piecewise linear like this
> dblevel = 40 * idx / (steps - 1) - 30; if idx >= steps / 2
> 80 * idx / (steps - 1) - 50; if idx >= steps /
> 4
> 160 * idx / (steps - 1) - 70; if idx >= steps /
> 16
> 480 * idx / (steps - 1) - 90; if idx > 0
> -144; if idx = 0
> with steps = 1024. The -144 representing -inf.
-144 makes more sense being inf for 24bit int audio.
> 3. Fader values are being send from the mixer as float "level" values with level
> = idx/1023.f.
> 4. Fader values can be received from the mixer as
> 4.a) floats within [0.f, 1.f]. The value is being rounded to one of the allowed
> values.
> 4.b) strings representing the dB value e.g. "-2.3" for -2.3 dB.
> 5. The OSC address for dB and level values is the same. The mixer decides
> depending on the parameter type.
Actually, that level would come close to position... It is close enough to
Ardour's position for dB value that paralax for viewing angle would be
more of a problem. (Ardour has -10 at 50%, -30 at ~ 25%, -60 is close to
6%.... top of scale is +6 not +10 would be the most notable difference)
However, the x32 /ch/<stripnumber>/processor/parameter value is
problematic. First strip number is limited to 99 strip (two digets) and
while the x32 only uses 32, Ardour may be expected to handle more if
banking is not used (16 bit int). For example a smart controller that
wants to form it's own banks may ask for all strips and choose which ones
to display in what order (for example two operator positions with
strips/busses/vcas).
The other thing is that as pointed out before there is no standard for OSC
paths. What works here may not be good for everyone else. Middleware would
be easy for the x32 though.
--
Len Ovens
www.ovenwerks.net
More information about the Ardour-Dev
mailing list