Re: gain-mapping - was Re: OSC next

On Wed, 18 May 2016, Felix Homann wrote:

> Len Ovens <[email protected]> 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
>       incoming
>       message. Adding things like path having channel embedded or value
>       being
>       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
 		happens.
 	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.



--
Len Ovens
www.ovenwerks.net

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org