[PD] Re: [PD-dev] We've got to undo the MIDI revolution! - Where isOSC?!

[cdr]

> 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..