[Ardour-Dev] OSC changes/updates

[Melanie Bernkopf]

Hello,

I am new to this list leaked for several months and at the moment building
myself a control surface for ardour.
This post made me get an account it addresses several problems I found to
be hard to get working on micro controllers.

I will try to comment this in between the lines hopefully as clear as
possible.


> Just started working on some middleware for OSC control with Ardour.
> Here are some things I would like to work on in the Ardour code to make
> OSC use better. I would normally talk about this on IRC, but it is easier
> to put a clear idea of where I am going in this format.

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

> Feedback:
>      sending /routes/list starts Ardour sending some feedback about
> each channel. There are:
>      a) some things missing (such as pan or trim)
>      b) some things that are not as useful as they could be
>          - gain is abs only. Fader or dB would both be more useful.
>          - SOLO is SIP only, Listen does not work.
>      c) None of the master kinds of things get feedback turned on
>          - master gain or mute
>          - monitor anything
>          - Transport controls
>          - even though /routes/list returns PH position it is not
monitored
>      d) metering
>          - I would suggest dB and positional metering
>              (0-1 based on meter position in GUI)

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
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 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.

Metering well I prefer to have it on the Monitor but the best Meter is the
ear, 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().


> Banking:
>      Feedback is already by server (the server that sent requests),
> Banking should therefore follow. Each server should have banksize and
> current_bank. Banksize = 0 means no banking for that server. So a
> controller would use banking by first sending a banksize command. Any
bank
> type command should return an error if banksize = 0. On error, the
> controller should resend banksize if it wants banking. For a server
> receiving Banked info, all of the commands would be strip based instead
of
> rid based. OSC code in Ardour would translate strip <=> rid for each
> transaction. I think this would be better than adding an /ardour/bank
> namespace. Effectively non-banked would be infinite bank size/bank 1.

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.

> This is a far from full list of things that could help OSC. I am thinking
> that starting with the banking code would mean less work later on adding
> bank code to more functions (less work finding where it needs to be
> added). From what I can tell, most OSC controllers are tablet based with
> minimum internal smarts. Middleware could make up for that, but the
person
> who downloads and uses a tablet app is likely to find that troublesome.
So
> from their POV, Banking and positional control/feedback are probably most
> important.

Don´t forget if a Fader is touched I think it is important for the software
to know about
this. Humans are the big unknown variable and they don´t like it if the
Fader runs away.

Comments? Maybe I am full of it :)

If I can help with some things regarding how Hardware works please feel
free to ask.

Regards

Melanie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20160430/a99447b0/attachment-0001.htm>