On Sun, Nov 15, 2009 at 10:03:24AM +0100, Karl Hammar wrote: > fons@xxxxxxxxxxxxxxx: > ... > > OSC does two things: > > > > 1. It encodes packet type in textual strings, which > > can be structured in the same way as pathnames in > > file system are. > > > > 2. It defines a way to describe and encode the data that > > follows, so you are not limited to a set of predefined > > formats. > > > > Both are done in a way that make the conversion from/to > > a textual representation very simple, which is some > > cases is a desirable feature. > > As an unix guy, I'd skip the encoding and send the whole thing as > space separaed text, since then you could simply do a telnet to the > other host and run it by hand. Compare e.g. to smtp. > The performance loss of printf() and scanf() at sending/receiving > sides are minimal, and plain text is much easier to debug. > But, this is of cause moot, since OSC is already there. This 'telnet style' has existed for almost as long unix has, and clearly there was a need for something more efficient in some types of application. A typical use for OSC is as an the interface between a composition language and a real-time sysnthesis engine. For example SuperCollider works this way. If you send 1000 messages per second to 25 granular synthesis channels each (i.e. 25k messages/s) then the printf(),scanf() overhead is not trivial at all. And you certainly don't want to read all of them. In many cases (if only a limited set of commands is required, no wildcards, no timed commands) OSC encoding/decoding can be done almost 'zero-copy' and using just a few lines of very simple code. The biggest error you can make in such cases, if efficienty is an issue, is to use a general purpose 'full' implementation such as e.g. liblo. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
