Re: OSC changes/updates

Hello,

yes HUI is dead but the Hardware lives on as MCP ;)

Meter is for me something like this:
http://www.sweetwater.com/images/closeup/750-MBM7CL_detail1.jpg
and Fader is this:
https://www.conrad.de/medias/global/ce/4000_4999/4400/4420/4420/442094_RB_00_FB.EPS.jpg

So i think we are talking different things but meaning the same.

Those encoders give just a clockwise/counterclockwise signal so all doable
in software with changes if lights are there well up to software. Didn´t
think someone could think about moving them.

Those alps fader well found them in most consoles those are even mounted in
the MCP

The logic I am implementing right now is the following:

osc comes in routed fader updated set to position.

if it is touched the MPR121 chip used to sens (i2c bus) pulls a pin to
ground microcontroller reading MPR121 an disabling the H-bridge for that DC
motor.

Update done on Fader variable set is touched value will be sent.

On a microcontroller converting a float range from 0-2 means round it to
int leaving me with 0 1 2 on the alps fader that would be a reading of 0
511 1023 ( all way down, mid, all way up). Maybe i can find a mathematical
way to do better but i have not yet searched. I have to get some testing
going with PD extended to see if it is doable.

Flame war is not my thing. Nobody thought icinga would be usable in a Load
balanced Cluster until I made a prototype but that´s something different.
as for indexes well there is always the possibility to do variable+1 ;)

And for Midi well it is in a dying state  as was the Mackie HUI once.
Keeping it alive is not useful specially with such a limiting thing as Midi
is. Let it die and move on to osc there we have bundle transmission the
option to say delay this osc command for X microseconds .........

Regards

Melanie

2016-05-01 3:26 GMT+02:00 Len Ovens <[email protected]>:

> 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
>
> _______________________________________________
> ardour-dev mailing list
> [email protected]
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>
>

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org