[OSC_dev] Adding OSC support to VLC

[Andy W. Schmeder]

On Nov 24, 2008, at 6:35 PM, Stephen Sinclair wrote:

>> When using namespaces such as /instance/1/parameter, it's quite  
>> useful
>> for environments such as Max/MSP and Pd which use the OSCroute-style
>> parsing.  However, I've found when doing C programming with LibLo  
>> that
>> it can be quite annoying having this information embedded in the
>> address path, requiring implementing a small parser in the message
>> handler.  In contrast, if it's a parameter it's already represented  
>> as
>> an integer and quite easy to just pick out of the argument list.

A richer set of inputs to the callback should solve this problem, yes?

e.g. a list of the path components, the depth of the current match in  
the tree, and the index of the node at the current level.  It  
shouldn't be necessary to re-parse the address.


> A follow-up: I just recalled that one of the more annoying times I
> encountered this issue was actually when using Max/MSP.  It was a case
> where I could not really predict what the embedded ordinal would be,
> so I could not for example set up an OSCroute object, like:
>
> [OSCroute 1 2 3 4 5 6]
>
> I really needed to parse that value out of the message path.  I can't
> remember the exact context.  Anyways I ended up having to use regular
> expressions on the message path.  It just felt like a totally awkward
> way to be dealing with OSC.


I believe what you are referring to is the problem of destructive vs  
non-destructive routing--- OSC-route is destructive, so once you've  
matched on /thing/*/foo you lose information about which "thing" was  
matched.  This is a major pain in certain situations and we have been  
discussing making the necessary changes, though I can't promise when  
that will happen.


> I used to be a proponent of this style of namespacing, because it
> certainly has an aesthetic quality to it, but after that experience,
> I'm not sure it's really the most practical.

On a technical note the two concepts we are discussing are REST versus  
RPC.  See http://en.wikipedia.org/REST for a succinct discussion of  
the differences.  OSC doesn't really adhere strictly to the REST  
model, of course...

There are legitimate arguments for both.  RPC likely wins in high- 
performance cases, but I see the REST approach as more easily  
integrated because the representation of resources is contained  
entirely in the address, for example by support for path-based query  
syntaxes--the problem of selecting a component of a multi-channel  
stream requires no understanding of the argument structure.

I don't think the issue should be forced either way, but I'd default  
to REST for any project unless circumstances demanded otherwise.


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu