i read a few discussions about doing complicated calls in osc, and obviously everyone refers to things like xml-rpc, and so on. right off the bat it's clear that osc isn't anywhere near optimal for general control of a complicated system, but if we are using osc for some other clearly specified reason, it will be easier to live with the limitations.

the current system specified the class and method in the osc address. the first arguments are used to select the specific instance of the class to invoke the method on, and the remaining arguments are the actual arguments to that method.

this resulted in calls like:

/KeyFrame/setRotation animation-name track-handle keyframe-index w x y z

where animation-name, track-handle and keyframe-index are used to select the particular keyframe on which to call setRotation with the arguments w, x, y and z.

this can cause problems when the same class is used in different ways , or if there are different ways of selecting the same object.

we currently have one situation that almost shows the limitations of this method, but we are conveniently saved by a differing number of selector arguments:

/AnimationState/setEnabled animation-name bool

/AnimationState/setEnabled entity-name animationstate-name bool

this is actually both of the problems (almost) happening at the same time. the AnimationState class is used in two different ways here. in the first use it is referring to one of the animations inside ogre for moving around scene nodes. in the second use, it is refering to an animation stored within a mesh (for animating a model).

while a real clash hasn't occured yet, these near misses make the protocol confusing, and highlight a poor (or lack of) design.

my current thoughts for a new naming system work something like this,

the address part of the osc message contains a combined reference to an object in ogre and a command to execute on it. the rest of the message contitute the arguments.

the address part is arranged like

/<object>[/<selector[/arg]*>]*/<method>

<object> would be one of the singleton objects in ogre, since everything in ogre is reachable starting with one of these. the most commonly used ones are SceneManager and ControllerManager.

the [/<selector[/arg]*>]* part is a chain of methods to apply on specified object, that will return a new object.

it gets tricky to allow a variable number of arguments. however, one way would be to use some syntactic marker to differentiate between mathod names and argumetns. the period character is allowed in osc addresses [1]. so, as ugly as this looks it would be possible to do something like:

/object/.selector_with_arg/arg/.selector_with_no_args/.selector_with_two_args/arg/arg

it's only necessary to do this if the restriction of being able to determine the number of arguments from the method name are too great. i think this restriction is something i could live with, and this notation looks horrid.

for the record, most selectors that i can think of at the moment are 0 or 1 arguments.

wildcards could be supported in args where possible, but this would be mostly at the whim of ogre.

the final method is the method to call on the selected object. and the arguments of the OSC message are the arguments to that method.

in the arguments, i am considering requiring the same /object/selector arrangement where arguments are an object.

the /KeyFrame/setRotation message from above becomes:

/SceneManager/getAnimation/animation-name/getTrack/track-handle/getKeyFrame/keyframe-index/setRotation w x y z

and the two AnimationState examples above become:

/SceneManager/getAnimation/animation-name/getAnimationState/setEnabledAnimationState/setEnabled bool

/SceneManager/getEntity/entity-name/getAnimationState/animation-state-name/setEnabled bool

for an example of an object reference in an argument:

/SceneManager/getAnimation/animation-name/getTrack/track-handle/setAssociatedNode

/SceneManager/getRootSceneNode/getChild/node-name

obviously this method is much more verbose. i have considered a few abbreviations, but these would really be shortcuts, and i think it would make sense to implement those shortcuts additionally as indicated necessary by useage. some obvious shortcuts are:

/SceneManager/getRootSceneNode → /root

/root/getChild/child1/getChild/child2 → /root/child1/child2

or perhaps even

/child1/child2

1. http://cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html

– PiX - 14 May 2005