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