Goto ROSCL Sourceforge Home

SourceForge.net Logo

Proposed Open Sound Control Amendments

When working on ROSCL I came upon a problem: Let's say I have a method "getvolume" and it returns a 32 bit floating point value when invoked; how can the OSC Method reliably return the four bytes of data to the invokee? One solution is to provide a mechanism which allows the invokee to uniquely identify each OSC Message. This id can in turn be used to uniquely identify the return value.

First Draft:
http://roscl.sourceforge.net/proposed_amendment.html

When proposed to the OSC developer's list this draft was found to be too complicated and and only solved a subset of the desired uses for an OSC ID. In my opinion this draft suffers from the "kitchen sink" syndrome. It is too complicated and tries to solve too many problems with compromises.

Second Draft:
http://roscl.sourceforge.net/proposed_amendment2.html

This draft proposal is much simpler. It makes no assumptions about the transport, the implementation or the communication model used (client/server, peer to peer). It uses already defined OSC Types.

Third Draft:
http://roscl.sourceforge.net/proposed_amendment3.html

This revision fixes the accidental omission of section 1.2.


© Copyright 2005 Richard Healy. All rights reserved.