On Mar 16, 2006, at 8:42 PM, cdr wrote:
OSC does not specify the transport specifically but it was designed around UDP, so its not a trivial spec:
the spec is really simple, anything that can stream binary data can
move it. Om-synth has added OSC patching this to its CVS version..
how Om handles types is: the cables dont care what theyre carrying,
and will only connect xlets with matching typetags (eg control,
signal, OSC, MIDI). they can carry 'chockfoo' or 'OSCviaJSON', as
long as you have a plugin (aka object) to handle it..afaik nobody uses timetags
imagine for a second you are writing OSC data to a file on disk
instead of a UDP socket - when you are reading back later
on..timetags would be quite useful. the most basic step of
implementing an OSC sequencer (without converting a limited subset
of the OSC types to say, pd types, and incurring further precision
penalties when writing to disk via [textfile]) would be to store
and load OSC from a file, do any apps do this yet?liblo is nice, but would be an extra library dependency, plus its C+
- both eschewed by the pd core ethos..the more idiomatic
solution? generalized transport mechanisms and OSC implemented as a
set of data-parsing abstractions..there was a proposal from matju on how to implement this, here it
is again:ack..cant find it. i think it was using some pointer tricks so the
cables didnt actually have to carry OSC and other objects could
somehow reference the id of the UDP or TCP object? i read it and
didnt quite understand..
Timetags would be really useful, too bad no one has implemented
them. As for liblo, there are already so many dependencies to Pd-
extended, what's one more ;).
Seriously, if someone wrote some objects based on liblo, managing
that lib would be easy enough. The liblo source could go into the
section for external sources aka "imports".
.hc
http://at.or.at/hans/