[LAD] Fader mapping - was - Ardour MIDI tracer

[Len Ovens]

On Thu, 21 Aug 2014, Fons Adriaensen wrote:

> On Wed, Aug 20, 2014 at 07:37:43AM -0700, Len Ovens wrote:
>
>>> 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.
>>
>> Yes, I liked the idea of that: real easy to build. Probably fine for
>> static mixing too.
>
> The only function of the encoding is to represent the fader position
> in the best possible way. How that is interpreted later and mapped to
> dB (or anything else) is a separate matter.

Really, the whole discusion on fader mapping is very useful and what I say 
here is based on all of it. I chose this message because it has all the 
ideas grouped together.

The last point first: "The only function of the encoding is to represent 
the fader position in the best possible way." This should be taken as the 
starting point. So I am looking at a complex mapping in any case for best 
use.

It appears this: "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." Is not true... or at least not usable as we would end 
up with some areas of our fade with giant steps from controler tick to 
controler tick. It seems that for proper information transfer we need .5db 
per step for 50 to 60 db travel no matter how it is mapped.

So there are a number of separate issues:
fader position to db mapping
db to midi mapping
midi mapping to a gain value

Fader mapping to db: this requires a physical control with a greater 
resolution than the midi signal to make mapping possible, or something not 
quite linear where the physical taper does the mapping for us.

db to midi mapping: This depends on the use. On the receiving end is SW 
that I have no control over and will have to feed what it wants. The least 
amount of work is to feed it something it knows already. Seeing as my 
project (this first one anyway) is likely to run inside the same computer 
as the DAW, it does not make any sense to use an intermediate coding, but 
rather to mape directly from physical control to the mapping the DAW 
expects.

In the end, the physical controler I have has limited ability to send 
info to the computer (no analog input) and I will be using rotary 
encoders. I will not have high resolution input and so I need to map ticks 
directly to db. Rather than have two different log based sections, I will 
have one. Based on the software I am controling (Ardour), I will have .5db 
from +6 to about -40 (though I may go a lot farther as my input is 
continuous). The output will be mapped to 10bit linear for MIDI and the 
DAW will add it's own mapping to that. I will do the mapping on my end to 
match. A full fade will be more than one full turn. I think this is ok 
because the rotary aspect already makes manual fading unlikely. Because 
there are no markings on the controler, the mixing point for any channel 
will always have the same feel even if is 40db down or 3 db up. Because my 
output has 1024 possible ticks, it will be possible to have a "modifier" 
button for finer control (or coarser), however, the resolution the fine 
control can provide will not be in DB but to the limit of the transport 
protocol which varies over travel. An unmodified movement after a fine one 
will of course jump to the nearest 127value.

For my next project, I will use motor faders and analog input to allow 
better position to level mapping. In the end, the control board in the 
controler is the smallest cost, so going from $3 to $40 is not such a big 
deal. The cost of switches, encoders and faders plus case is much more. I 
may be better off starting with a prebuilt control surface and developing 
middleware for that.

On the other hand, I might get used to mixing with rotary controls. I will 
try various knob sizes and feel.

--
Len Ovens
www.ovenwerks.net