[Ardour-Dev] OSC changes/updates
len at ovenwerks.net
Sat Apr 16 10:23:15 PDT 2016
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
> 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.
More information about the Ardour-Dev