[Ardour-Dev] gain-mapping - was Re: OSC next
len at ovenwerks.net
Wed May 18 09:37:25 PDT 2016
On Wed, 18 May 2016, Felix Homann wrote:
> Len Ovens <len at ovenwerks.net> schrieb am Sa., 14. Mai 2016, 21:39:
> On Sat, 14 May 2016, Felix Homann wrote:
> I like the: send any message with no value means send me an update.
> However, that would mean a complete rewrite I think. Right now, liblo
> does a direct call to a function based on it's own parse of the
> message. Adding things like path having channel embedded or value
> present or not breaks that. That may or not be a bad thing.
> I wouldn't say it would break the way liblo dispatches messages. It just adds
> something on top of that. But sure, with current liblo, you'd need to at least
> partially bypass liblo's built-in dispatch mechanism.
> You'd need to implement one or several generic lo_methods to handle those
> parametrized paths, though. Handling the path parameters is fairly easy with
> C++11's regex support. But you would loose automatic handling of OSC wildcards
> when a message is received, so you would have to handle them yourself.
I have played with this some more and have already set somethings to use
either /path or /path 1/0 to do the same thing. I realize it would not be
hard to use /path param to set and /path to query. The biggest problem is
that there are a large number of /path commands right now. If the PTBs are
willing to drop all of them in favour of /path 1 to set or toggle and
/path to query, I have no problem doing that. It will take some time is
all as really the OSC code was not set up for feedback from the start. It
has just been patched on as people felt like it. This can be seen from the
Ardour manual for OSC which is all commands and no feedback. If you have a
list of things you like to be able to query in this way and you don't feel
you want the DAW to send you values as they are updated send it here. The
code is already in place to treat different surfaces in a different manner
even when both are being used at the same time.
I am finding various ideas about what kind of feedback would be nice.
There are two main ideas:
1) don't give me feedback unless I ask for a value. I haven't really
touched this at all.
2) send me feedback when something happens. This can be subdivided into:
A) I am a dumb surface send me each LED or variable value as it
B) I am a smart surface, tell me what speed the transport is
moving and I will figure out the rest.
I have no opinion of one over the other and realize that each has it's
place. There is already some code in there for 1). I haven't used it
because I personally don't want my surface to be constantly polling the
DAW. I would prefer to tell the DAW what feedback I want and have it send
it when it happens. The polling option would be most useful for smart
surfaces that want a one time capability check. For example, send a list
of plugins for strip 5, then send me the list of parameters for strip 5
plugin 2. So that would be both 1) and 2).
A lot of people want to use their tablet/phone as a remote control. This
is a very big use because lots of people have them sitting around. The
available applications/libraries available for iOS/Android are pretty dumb
and generic. They could really be easily served by midi-MCP but linux does
not have a good rtpmidi setup (think iOS/OSx style) and so OSC is the
thing we do have that works. This is the 2)A above. Right now, this is
mostly what I am working on because it can be used by any control surface
even a smart one, and I think it will serve the most people (I could be
wrong too). Also, I have a controller that works this way so it is easy to
test. In the long run, I have middleware I am writing that will combine
what I have now with more stuff and inteligence.
More information about the Ardour-Dev