[OSC_dev] Adding OSC support to VLC
Stephen Sinclair
radarsat1 at gmail.com
Mon Nov 24 18:29:25 PST 2008
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.
Steve
More information about the OSC_dev
mailing list