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
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
