<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello,<br><br></div>yes HUI is dead but the Hardware lives on as MCP ;)<br><br></div>Meter is for me something like this: <a href="http://www.sweetwater.com/images/closeup/750-MBM7CL_detail1.jpg">http://www.sweetwater.com/images/closeup/750-MBM7CL_detail1.jpg</a><br></div>and Fader is this: <a href="https://www.conrad.de/medias/global/ce/4000_4999/4400/4420/4420/442094_RB_00_FB.EPS.jpg">https://www.conrad.de/medias/global/ce/4000_4999/4400/4420/4420/442094_RB_00_FB.EPS.jpg</a><br><br></div>So i think we are talking different things but meaning the same.<br><br></div>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.<br><br></div>Those alps fader well found them in most consoles those are even mounted in the MCP<br><br></div>The logic I am implementing right now is the following:<br><br></div>osc comes in routed fader updated set to position.<br><br></div>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.<br><br></div>Update done on Fader variable set is touched value will be sent.<br><br></div>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.<br><br></div>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 ;)<br><br></div>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 .........<br><br></div>Regards<br><br></div>Melanie<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-01 3:26 GMT+02:00 Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 30 Apr 2016, Melanie Bernkopf wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wonderful if this is the GitHub ardour branch osc I like what I have seen so far.<br>
</blockquote>
<br></span>
Great! just started though.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes feedback is good but on micro controllers we face problems with some things<br>
that get sent as<br>
float which takes a hell lot of place we don’t have. For example if you send the<br>
Fader position as float<br>
an we have 32 of them even on the big ATmega2560 all is eaten up just by those<br>
variables so no space left<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for the actual code to position the Fader. Which brings me to the next thing<br>
those faders usually are not<br>
log Faders they are linear in the Mackie HUI schematics you find a 2.2KOhm<br>
resistor between wiper and<br>
positive Voltage to make it act logarythmical. I came to the same conclusion<br>
</blockquote>
<br></span>
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)<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after trying to make it<br>
in software which made it slow. Fastest would be to go linear and use percentage<br>
of way eliminating the<br>
need of threshholds to compensate jitter ( looks horrible when the Fader is going<br>
fast up down 20mm of way<br>
somewhere). Depending on feel it should be possible to get higher resolution<br>
anyway it is just a number<br>
that is sent.<br>
</blockquote>
<br></span>
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)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Metering well I prefer to have it on the Monitor but the best Meter is the ear,<br>
</blockquote>
<br></span>
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).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but if wanted same as above<br>
maybe for performance reasons a binary code would be best which could be piped<br>
through to the shiftregisters<br>
directly. If thinking hardware hacking Meter-bridges are just led´s so no need to<br>
process something just index<br>
and binary code maybe micro controller sending how many led´s he has and directly<br>
going meterIndex.shiftOut().<br>
</blockquote>
<br></span>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Banking:<span class=""><br>
<br>
Yes definitely less traffic less messing around with things not needed.<br>
But please do those with micro controllers a favour Channel1 index 0<br>
easier to work with when using arrays making code faster and there will be<br>
arrays.<br>
</span></blockquote>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Don´t forget if a Fader is touched I think it is important for the software to<br>
know about<br>
</blockquote>
<br></span>
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.<br>
<br>
Anyway more later.<br>
<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" rel="noreferrer" target="_blank">www.ovenwerks.net</a><br>
<br>_______________________________________________<br>
ardour-dev mailing list<br>
<a href="mailto:ardour-dev@lists.ardour.org">ardour-dev@lists.ardour.org</a><br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org" rel="noreferrer" target="_blank">http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org</a><br>
<br></blockquote></div><br></div>