-
Notifications
You must be signed in to change notification settings - Fork 4
Minuit 0.2 Specifications
Specifications for a query system over OSC. They have been discussed and refined by the protocol workgroup of the Virage platform on november 26th 2008. The last features have been added in Junary 2010.
It has been decided that queries and replies should be separated from the address for optimization’s sake. The type of message is then possible to filter based on tree specific characters into the first word of the message :
a slash at start ( / ) indicates an OSC “standard“ command to the specified address (this includes addressing attributes…) a questionmark ( ? ) indicates a query. a colon ( : ) indicates a reply to a query, and duplicates the query’s syntax (colon is also used further to separate attributes from address) It turns out that the namespace can be handle using 4 differents operations :
discovering (using namespace) : asks for the names and types of nodes, values and attibutes on the next tree-structure level. getting (using get) : gets the value of a particular attribute of a node or leave of the tree. setting (using the standard OSC style) : sets the value of a particular attribute of a node or leave of the tree. listening (using listen) : enable or disable listening of the value of a particular attribute of a node or leave of the tree. When a listening is enabled, the value would be sent as a reply to the application which ask for. Hereafter we consider an application A (IP, port) and an application B (IP, port) which knows themself on an the network.
B would talk to A like that :
B?operation /whereTo … (the rest depends on the operation)
A would replies to B using :
A:operation /whereTo … (the rest depends on the operation)
B?namespace /WhereToDiscover
A:namespace /WhereToDiscover nodes={ some nodes below } leaves={ some leaves below } attributes={ some attributes of this node }
note : the leaves field contains all nodes which have a value attribute. This field is really usefull in order to optimized the namespace discovering avoiding over crowed network. Using this field, we don’t look at the attribute to know if a node have a value (so we don’t need to ask the namespace of a leaf before to get the value).
B?get /WhereToGet:Attribute
A:get /WhereToGet:Attribute value
/WhereToSet value (this standard OSC)
no reply from A.
B?listen /WhereToListen:Attribute enable (turn on the listening) B?listen /WhereToListen:Attribute disable (turn off the listening)
A:listen /WhereToListen:Attribute value (each time the attribute change if the listening is turned on)
For the time being the generic attributes managed by the pre-protocol are restrained to the list below
gives information about the kind of leave : is it a getter or a setter, or getsetter (both) ?
getter means that the leave could answer to a get request (because there is a getter mecanism). setter means that the leave could receive a value (because there is a setter mecanism). getsetter means the two mecanism describe before exist.
the possible types are :
integer, decimal, string, anything, boolean, none, enum (a.k.a. enumerated list), array (a.k.a list)
this a number used to order the recall of a snapshot. Smaller the number is the later it would receive the value. 0 means this leave don’t care about order.
the value attribute is implicitly linked to the address, and then can be ommitted.
an array of two values of the specified type.
0 or 1. Is the value could be ramped by the Sequencer ?
textual description of what is the node (or leave) for in the application.
A translator needs to be placed at the network input/output of the environments in order to translate this syntax into the environment “dialects”.
Don’t put a ‘/’ before the name of your application to do not create confusing with standard OSC.
For now, the sequencer listens to replies to its request on port 7002.
A default Minuit device is automatically created when Virage starts. This device is named MinuitDevice1 and is expecting at 127.0.0.1 on 9998 port.