[LAU] open hw soundcard

[fons at kokkinizita.net]

On Sun, Nov 15, 2009 at 10:03:24AM +0100, Karl Hammar wrote:
> fons at kokkinizita.net:
> ...
> > 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.