[OSC_dev] OSC Questions regarding Protocol

[Angelo Fraietta]

Adrian Freed wrote:
>>Matt Wright wrote:
>>
> 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):
>
I am very interested - thanks

> 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?
> 
In the paper I have, the assumption was that the transport layer would 
delivered a whole packet.

We assume that data will be delivered in packets (a.k.a. "datagrams") 
rather than as a stream of data traveling along an established 
connection. (Although many LANs transmit data serially, they deliver 
the data as a single block.) This leads to a protocol that is as 
stateless as possible: rather than assuming that the receiver holds some 
state from previous communications (e.g., MIDI's running status), we 
send information in larger, self-contained chunks that include all the 
relevant data in one place.


I think you are referring the the OSC specification online. Is there a 
biblio entry for that?

> 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.
> 
I actually disagree on efficiency of OSC and I will be addressing it in 
the paper. As an end to end protocol, I do not believe that it will be 
able to cut it. However, I think that it makes an excellent API and will 
be suggesting that also.

> 
> 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.
> 
It is also hard to not take any criticism personally - so I hope you can 
be tolerant with me.

Would you be interested in giving me some feedback on my first draft of 
the paper when it is done? It is due by 31 Jan, so you would only get a 
couple of days. If the paper is accepted at NIME, I would be able to 
consider in detail any criticism or comments you make.

Thanks

Warmest regards
-- 
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page


http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is 
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
     Bernard of Clairvaux (1090 - 1153)