<div dir="ltr"><div><div><div><br>Hello,<br><br>I am new to this list leaked for several months and at the moment building myself a control surface for ardour.<br>This post made me get an account it addresses several problems I found to be hard to get working on micro controllers.<br><br>I will try to comment this in between the lines hopefully as clear as possible.<br><br><br>> Just started working on some middleware for OSC control with Ardour.<br>> Here are some things I would like to work on in the Ardour code to make <br>> OSC use better. I would normally talk about this on IRC, but it is easier <br>> to put a clear idea of where I am going in this format.<br><br>Wonderful if this is the GitHub ardour branch osc I like what I have seen so far.<br><br>> Feedback:<br>>      sending /routes/list starts Ardour sending some feedback about <br>> each channel. There are:<br>>      a) some things missing (such as pan or trim)<br>>      b) some things that are not as useful as they could be<br>>          - gain is abs only. Fader or dB would both be more useful.<br>>          - SOLO is SIP only, Listen does not work.<br>>      c) None of the master kinds of things get feedback turned on<br>>          - master gain or mute<br>>          - monitor anything<br>>          - Transport controls<br>>          - even though /routes/list returns PH position it is not monitored<br>>      d) metering<br>>          - I would suggest dB and positional metering<br>>              (0-1 based on meter position in GUI)<br><br>Yes feedback is good but on micro controllers we face problems with some things that get sent as<br>float which takes a hell lot of place we don’t have. For example if you send the Fader position as float<br>an we have 32 of them even on the big ATmega2560 all is eaten up just by those variables so no space left<br>for the actual code to position the Fader. Which brings me to the next thing those faders usually are not<br>log Faders they are linear in the Mackie HUI schematics you find a 2.2KOhm resistor between wiper and <br>positive Voltage to make it act logarythmical. I came to the same conclusion after trying to make it<br>in software which made it slow. Fastest would be to go linear and use percentage of way eliminating the<br>need of threshholds to compensate jitter ( looks horrible when the Fader is going fast up down 20mm of way<br>somewhere). Depending on feel it should be possible to get higher resolution anyway it is just a number <br>that is sent.<br><br>Metering well I prefer to have it on the Monitor but the best Meter is the ear, but if wanted same as above<br>maybe for performance reasons a binary code would be best which could be piped through to the shiftregisters<br>directly. If thinking hardware hacking Meter-bridges are just led´s so no need to process something just index<br>and binary code maybe micro controller sending how many led´s he has and directly going meterIndex.shiftOut().<br><br><br>> Banking:<br>>      Feedback is already by server (the server that sent requests), <br>> Banking should therefore follow. Each server should have banksize and <br>> current_bank. Banksize = 0 means no banking for that server. So a <br>> controller would use banking by first sending a banksize command. Any bank <br>> type command should return an error if banksize = 0. On error, the <br>> controller should resend banksize if it wants banking. For a server <br>> receiving Banked info, all of the commands would be strip based instead of <br>> rid based. OSC code in Ardour would translate strip <=> rid for each <br>> transaction. I think this would be better than adding an /ardour/bank <br>> namespace. Effectively non-banked would be infinite bank size/bank 1.<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 arrays.<br><br>> This is a far from full list of things that could help OSC. I am thinking <br>> that starting with the banking code would mean less work later on adding <br>> bank code to more functions (less work finding where it needs to be <br>> added). From what I can tell, most OSC controllers are tablet based with <br>> minimum internal smarts. Middleware could make up for that, but the person <br>> who downloads and uses a tablet app is likely to find that troublesome. So <br>> from their POV, Banking and positional control/feedback are probably most <br>> important.<br><br></div>Don´t forget if a Fader is touched I think it is important for the software to know about <br></div>this. Humans are the big unknown variable and they don´t like it if the Fader runs away.<br></div><div><div><div><br>Comments? Maybe I am full of it :)<br><br>If I can help with some things regarding how Hardware works please feel free to ask.<br><br>Regards<br><br>Melanie<br></div></div></div></div>