[OSC_dev] OSC Questions regarding Protocol

[Adrian Freed]

>Matt Wright wrote:
>
>>> Greetings all
>>>
>>> I am writing a paper about using OSC for gesture based interfaces -
>>> pros and cons.
>>
>>
>> I'd be interested to hear this list of pros and cons.
>>
>
>I was wondering if there is a PDF available of
>http://archive.cnmat.berkeley.edu/ICMC97/papers-html/OpenSoundControl.html
>so I can reference page numbers in my quotes

Here is the biblio entry for that paper:

http://cnmat.berkeley.edu/publication/open_sound_control_new_protocol_communicating_sound_synthesizers

It has the page numbers and an XML, BIbTex and Endnote export. THe PDF will be up their soon too.


Since you are writing a paper you might be interested in my own criticisms (some of which are being addressed in the next version of OSC):

1) We shouldn't have said anything at all about transport and somehow this paragraph slipped in:
"In a stream-based protocol such as TCP, the stream should begin with an int32 giving the size of the first packet, followed by the contents of the first packet, followed by the size of the second packet, etc."

This technique works of course but now we recommend slip encoding for stream oriented protocols. This arose from more experience as OSC was implemented on cheap microcontrollers and slower point to point transports such as USB. Since slip works just as well over a reliable TCP link why have two recommended encodings?

2) Types turn out to be very useful and the OSC coding is efficient but encoding all the optional types people use in their private adaptations of OSC  in a single character is tricky. Part of the problem is that OSC is  commonly used in languages like PD and Max/MSP which don't have a flexible type system so many useful types cannot be easily mapped. For the next release I  would like to push some of the really useful "optional" types into the "required type" category but will only be able to do this for types that can be easily mapped into native types across all the OSC language platforms.


3) Timetags and the requisite clocks and  scheduling are hard to implement in modern operating systems. THe core algorithms were built-into the software kit Matt released but largely went unimplemented because the dominant operating systems don't have deadline scheduling primitives needed. This situation will improve in coming years due to the recent release of new IEEE timing standard and new vigor from the key players for media computing scheduling needs. It turns out that timing and scheduling is easier on the microcontrollers used for gesture acquisition and the upcoming OSC hardware kit will implement time tags and scheduling.

4) We have been asked why we didn't do all this with XML or JSON. They weren't mature when we started.
Although encoding efficiency was not a primary concert of OSC XML and JSON require parsing of data values and would therefor be both time and space  inefficient on small microcontrollers. IF you were starting OSC today you might build on a binary representation of XML: e.t. EXI: http://www.w3.org/TR/2007/WD-exi-20071219/


5) I am aware that the popularity of a protocol creates a barrier of entry for new protocols and better
ideas and I worry that this is the reason critical papers of OSC are hard to find. I hope these lost ideas surface. Some we can build into improvements to OSC which is still small and lightweight enough to embrace refinements. Others will just have to be the basis of the replacement for OSC.