Re: OSC changes/updates

On Sat, 16 Apr 2016, Johannes Mueller wrote:

> I definitely want the possibility to set automation states by OSC.
>
> I recently submitted a PR on github, to set the gain automation state.

Took a look.

> Paul then said it should be more generic like
>
> /ardour/route/automation_state "gain" "w"
>
> thus allowing for
>
> /ardour/route/automation_state RID "solo" "m"
> /ardour/route/automation_state RID "mute" "t"

Wow, this is a departure from where things are now for sure. If normal 
controls where to follow this same trend, one would have:
/ardour/route/control RID gaindB value.

All of this breaks almost anything out there right now. This is 
particularely true for most if not all tablet OSC applications.

All of your modes make sense except for T (touch) unless your controller 
has another message to send for touched or not. While this makes sense for 
MCP use where there is already such a signal, I would suggest that touch 
could just as easily be achieved with W and P controlled on the controller 
by the local touch sense. This would leave m,p and w.

In other words I don't think your patch as is would work for touch. Touch 
mode would be entered ok and touch on the GUI control would work, but 
touch on the surface would not because there is no touched event set up.

Another advantage to using P/W for touch operation, is that it means there 
is only one controller doing touch automation. If touch is turned on for 
the route, any controller sending touch info will write even though the 
operator of that controller did not set touch. (it would also be possible 
to only accept touch events from the control surface that turned it on... 
but there are other problems with that too)

> I implemented this against 4.7 in my local installation, as I really need this
> feature.
>
> I haven't submitted a new PR because I want to wait until things get settled
> after the vca2 merge.
>
> BTW: I looked into the vca2 branch and admittedly I don't understand what it
> is about. Is there some "white-paper" or some archived discussion on it, so
> that I can get to know what is the actual goal of vca2?

VCAs on their own do not affect surfaces... but, to make VCA work as 
desired required changing how routes are accessed internally. That will 
affect all of the surface code in some ways though perhaps not in a way 
that is that vissible.

I am also waiting for VCAs to hit main before I do any more actual code 
changes for surfaces. There is more work to do in mackie control code and 
OSC needs work too. My reason for writing is to find out what is the best 
way forward. From your conversation with Paul it appears that there is 
some willingness to "start over". (ie break existing OSC controllers 
operation with Ardour)

All feedback (of the OSC kind) is linked to the senders url/port right 
now. This means more than one controller can be used at a time. One of the 
things that would make this easier (maybe) is to keep a set of parameters 
for each remote server. (like a struct or object) This would allow 
refering to each controller by an index rather than url. This would 
allow (aside from setting automation modes) setting gain modes (ie this 
controller likes it's gain to be abs or dB or positional). The other big 
plus is the ability to do banking for more than one controller at a time 
with different bank positions and sizes. In my mind banking is one of the 
big things missing in Ardours OSC right now.

Making Ardour's OSC control accessable to people with not much programing 
ability (like MCP and generic_midi do now with preset mapping) is one of 
my goals. Make it easy for someone to make a working map with any of the 
existing OSC apps for tablets.

So really I would like see us with a set of paths and method of operation 
that covers the greatest user base possible.

--
Len Ovens
www.ovenwerks.net