[OSC_dev] namespace best practice?

[pascal baltazar]

Hi !

Well, I'm not sure that's a "best practice" (I'm not even sure it's a  
good one, but it exists ;-)

You can have a look here : http://www.jamoma.org/wiki/NameSpace
where we have described the common namespace for Jamoma (which is a  
framework for MaxMSP)

amongst the addressed points, there is the question you mentioned  
about "instances" and numerical containers :
our (current) proposal for this kind of problem uses the dot as a  
separator :

"/control.0/control.1/uosc_dev.2/pwm.3 ,i 255"
to recycle your example

there's also a discussion about addressing methods rather than values,  
using the colon separator. This was extensively discussed in a paper  
we published at last NIME (the link is on the webpage above...)

we're also (theoretically) investigating the use of a reserved  
character for queries (could be "?") - but that's not mentioned in the  
above webpage...

hope this helps....

Best,

pb

Le 29 juil. 08 à 21:10, mart a écrit :

> Hi All,
>
> i am new to OSC and I am pretty much stuck:
> i want to setup a distributed system with several (a lot) of nodes.
> This could be uOSC-devices or so.
> Defining the namespace of methods of one node is pretty much straight
> forward to me:
>
> "/device/id"
> "/device/status"
> "/device/firmware"
> etc..
>
> cool.
>
> I know that the OSC-spec does not provide a namespace convention
> and it is all up to me
> but when it comes to trees of higher orders I don't know what to do:
>
> "/control/0/control/1/uosc_dev/2/pwm/3 ,i 255",
> "/control0/control1/uosc_dev2/pwm3 ,i 255"
> or just
> "/pwm 0 1 2 3 255" ?
>
> it doesn't matter to the specs...
> but containers just called "1" seem ugly to me
> same time "name+id" also doesn't feel right
>
> monome solves the problem by flatting the tree:
> /40h/led [x] [y] [state]
>
> although they could have as well
> put each pixel of the matrix in the path:
>
> /40h/row/1/col/2/pixel/state ,i
>
> and when i got 100 monomes?
> /40h/100/row/1/col/2/pixel/state, i
> or just
> /40h/led [dev] [x] [y] [state] ?
>
> (actually i would be  happy if I had one 40h :)
>
> supercollider seems to do the same:
> "/group0/group1/group2/synth/set"
> seems to be representing the setup best, but instead
> something like
> "/n_set <value> <value> <value> <value>"
> is used...
>
> Is OSC here only another network transport layer?
>
> Main problem is that pattern matching does not work anymore.
> Imagine i have a mixer-device with 16 channels
> and another one with 16 channels.
> Don't ask me why, but i want to mute all channels all together:
>
> /mixer/*/chn/*/volume ,f 0
>
> possible?
>
> or only:
>
> /mixer/1/chn/*/volume ,f 0 ?
> /mixer/2/chn/*/volume ,f 0 ?
>
> surely not with a flat representation:
>
> /mixer [id] [chn] [volume]
> /mixer * * 0
>
> I like to use OSC instead of XML.
> I like the idea of publishing OSC-Servers
> via zeroconf in a distributed system (like SC).
> And I like the idea to query a namespace
> by sending "/"  (like make controller)
> and getting values by just sending /container/method
> without parameters (like ?)
>
> but i don't know how to nest
> and somehow automatically name
> my units...
>
> so how would look a  well-designed namespace of an
> OSC-based distributed system of (u)OSC-entities?
>
> all the best
> mart
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Pascal BALTAZAR
pb at zkrx.org
http://www.zkrx.org