[OSC_dev] Adding OSC support to VLC

[Stephen Sinclair]

On Mon, Nov 24, 2008 at 9:29 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> On Mon, Nov 24, 2008 at 6:56 PM, Pascal Baltazar <pb at zkrx.org> wrote:
>> Hi !
>> on the question of instances (i.e. here /deck ids), we've been considering
>> introducing a new reserved character in our use of OSC in Jamoma (modular
>> framework for Max/MSP), by using the dot.
>> /deck.1/play
>> /deck.1/pause
>> which hopefully could help as well humans as machines to distinguish between
>> subnodes and instances.
>> This (and more about requests in Jamoma) is documented
>> on http://www.jamoma.org/wiki/NameSpace/
>> Hope this helps,
>> pb
>>
>> Le 24 nov. 08 à 23:29, Forwind info a écrit :
>>
>> Good work !
>>
>> Would it be useful to consider multiple decks ?
>>
>> /deck/$id/play
>> /deck/$id/pause
>> /deck/$id/stop
>
> 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.
>
> Of course it's easy to get around when you can dynamically allocate
> message handlers at the time of instance creation, but when writing a
> general handler where the message path is not predictable, this case
> can sometimes get in the way.
>
> Any ideas on what is the best approach?  I'm not sure information
> should really be embedded in the message path.  In addition, including
> new delimiters such as '.' or '_' just complicates things further.
>
> On the other hand, whatever is the most useful for the largest number
> of applications is what should be done, so if some corner cases of C
> programming call for more complex solutions, that's something that one
> can live with.

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 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.


Steve