[Ardour-Dev] OSC changes/updates

[Len Ovens]

On Sat, 30 Apr 2016, Melanie Bernkopf wrote:

> Wonderful if this is the GitHub ardour branch osc I like what I have seen so far.

Great! just started though.

> Yes feedback is good but on micro controllers we face problems with some things
> that get sent as
> float which takes a hell lot of place we don’t have. For example if you send the
> Fader position as float
> an we have 32 of them even on the big ATmega2560 all is eaten up just by those
> variables so no space left

I will have to think about this. The biggest use of OSC right now is (if i 
like it or not) tablets. All of the tablet SW uses floats. A slider is 
linear 0 to 1 float. I would suggest converting incoming floats as they 
come in and using int to store. Or using MIDI directly. If we ever get to 
this it will be as a part that banking setup.

> for the actual code to position the Fader. Which brings me to the next thing
> those faders usually are not
> log Faders they are linear in the Mackie HUI schematics you find a 2.2KOhm
> resistor between wiper and
> positive Voltage to make it act logarythmical. I came to the same conclusion

HUI is effectively dead (besides protools), the mackie control surface is 
linear. The Ardour mackie code converts linear to gain. In OSC there is 
/strip/fader that will use 0 to 1 linear values and have the fader 
position match the fader position in the GUI. (I had already added that 
before branching)

Right now, feed back is all three (gain, dB and position), but when I add 
banking I will/ have to keep current bank for each surface anyway and I 
think I will also keep the prefered math for the faders as well. That way 
I will only be sending feed back in the type used. Something to remember, 
is that a float is the same number of bytes as an int... at least in 
ardour code. If things are as tight as you say, you will be wanting char 
(8 bit int) variables, like MIDI. It may be easier to use ipMIDI in that 
case and actually set it up using MCP which is much more complete than osc 
at this time. I used MCP in my first surface and found it very easy to 
program and set up.

> after trying to make it
> in software which made it slow. Fastest would be to go linear and use percentage
> of way eliminating the
> need of threshholds to compensate jitter ( looks horrible when the Fader is going
> fast up down 20mm of way
> somewhere). Depending on feel it should be possible to get higher resolution
> anyway it is just a number
> that is sent.

I am not really sure what that is about to be honest. I am not using 
resitive faders or motors in my case, but encoders. So far there is no 
feedback loop as the mcp code requires. I would like to keep it that way. 
So your fader sends a value, Ardour sets the fader. Or Ardour sends a 
value your surface moves the fader till it agrees with that value but does 
not send ardour any of the fader info untill after it,s value has settled 
(preferably no value is sent to ardour unless there is a touch signal). 
Ardour already does smoothing of these values. (I think, MCP does for 
sure, I will have to check OSC code)

> Metering well I prefer to have it on the Monitor but the best Meter is the ear,

metering will always be optional. Any surface that wants it will have to 
turn it on. Same with play head movement (bars/beats or time code).

> but if wanted same as above
> maybe for performance reasons a binary code would be best which could be piped
> through to the shiftregisters
> directly. If thinking hardware hacking Meter-bridges are just led´s so no need to
> process something just index
> and binary code maybe micro controller sending how many led´s he has and directly
> going meterIndex.shiftOut().

Not all meters are "just LEDs", if fact most are not. The surface will 
have to be responsible for taking a possition or dB value and changing to 
LEDs. Even if I were to set up for LEDs... how many? Even in the Mackie 
world look at the difference from the mackie (no LEDs 13 level) to the 
Xtouch with 8 LEDs.

> > Banking:
> 
> Yes definitely less traffic less messing around with things not needed.
> But please do those with micro controllers a favour Channel1 index 0
> easier to work with when using arrays making code faster and there will be
> arrays.

We could I am sure, start a flame war on that one :) Be assured that the 
way things happen to work in one controller is not the way it works in 
another. Might be settable... but will probably start as 1 based.

> Don´t forget if a Fader is touched I think it is important for the software to
> know about

touch is on my list. A controller should use touch internally too to turn 
the motor off or disabled.... but the DAW should not send movement while 
control is touched either.

Anyway more later.


--
Len Ovens
www.ovenwerks.net