Possible OSC support in Jamoma

We are currently considering changing syntax for control messages in Jamoma to be OSC-compatible. (Jamoma is a proposition of a clear structure and common features for building max patches, reducing the amount of time needed to create new performance systems, and enhancing the interchange of patches amongst max users). One of the issues we could need some help clarifying is how to best translate current syntax into OSC-compatible syntax.

With the current syntax, you would send the following message to an audio module in order to instantly change midi gain:

gain_midi 127

For relevant parameters it is possible to ramp to a new value over a specifiec amount of time. E.g. to ramp to midi gain 127 in 3 secs. you would send the following message:

gain_midi 127 3000

If we decide to change the syntax to be OSC-compatible it is pretty straight forward what syntax should be when instantly changing midi gain:

/gain_midi 127

What syntax would be recommended in the case that gain instead is to ramp to a new value over 3 secs?

The following would be the most straight forward translation:

/gain_midi 127 3000

Then again I'm wondering if a separate namespace would be required/preferred for ramp time. This might be easy to read, but could possible require more and less intuitive typing in cue scripts (e.g. should ramp always be reset to 0?):

/gain_midi/ramp 3000
/gain_midi/value 127

In his presentation at the 2004 OSC conference, James McCartney seems to indicate the use of a single level name space, and hashed commands in SuperCollider:

/gain_midi 127 ramp 3000

Are there any official guidelines to inform us on what of these possible syntaxes would be recomended?

Thanks,
Trond

I tend to use optional

I tend to use optional arguments for cases like this, because "ramp time for gain_midi" doesn't quite seem like an independent feature of its own, but an option to the gain_midi feature.

Another way to think about this is in terms of stateless protocols, the classic example being NFS, in which every single message/response pair is totally self-contained information-wise. In other words, the meaning of a given message depends only on the contents of that message, not on any "state" that's left around from the handling of previous messages. Stateless protocols are nicely robust to message loss and other forms of confusion. Unfortunately, it's usually not practical to have completely stateless protocols for realtime sound control, but I like to make my OSC protocols "as stateless as possible", which in this case would also argue for making the ramp time be an argument to the gain_midi message instead of a separate message.

-Matt

Re: Possible OSC support in Jamoma

Thanks Matt,

you are bringing up some issues that are well worth considering. It definetively makes sense to consider ramp time an optional argument. It is also how it is currently implemented, and I hoped that it would not be contrary to the philosophy of the OSC protocol to keep it that way.

Without being very versatile in programming languages I would assume that the question of keeping the protocol stateless gets more difficult for object-oriented languages and compelx modules.

With the introduction of attributes to a number of externals in Max, they are becoming more object-like in the way that they do contain an internal state (attributes) in addition to be responding to incoming messages. As externals and modules grow in complexity it becomes more and more likely that the responce to a message will be more and more depending on the internal state of the object when receiving the message. Still, the idea of making the protocol as stateless as possible makes a lot of sence to me as well, and seems to be a good guideline for further development.

http://www.bek.no/Members/lossius/lostblog/