On Fre, 2012-11-09 at 17:19 +0100, IOhannes m zmölnig wrote: > On 11/09/2012 02:51 PM, Jamie Bullock wrote: > > > > So, it seems like [packOSCstream] and [unpackOSCstream] are (un)packing > > message in a format that can't be used with external clients/servers. Is > > that correct? > > > from your experience with liblo, you seem to conclude that: > a) all "external clients/servers" are build on top of liblo. > b) liblo handles OSC over TCP/IP correctly > c) [(un)packOSCstream] handles it wrongly. > > > anyhow: > originally OSC did not define how to transmit OSC-packets over a > stream-based protocol like TCP/IP (that has no notion of ending packets). > implementations that wanted to transmit OSC over stream-based protocols > had to find solutions for themselves. > > a few years ago, the OSC specs have been extended, to explicitely > mention "SLIP" encoding as the means to packetize streams of OSC-data.
This was added to OSC 1.1, iirc. OSC 1.0 proposed to prepend to each OSC packet a 4 byte header that contains the byte count of following OSC packet. Old versions of [packOSCstream]/[unpackOSCstream] implemented this proposal. The 4-byte-header has the big disadvantage of once being out-of-sync, it never catches up again. One would have to re-establish the connection from scratch > [packOSCstream] implements this standard by use of [slipenc]. Exactly, in order to comply with OSC 1.1 (and while breaking compatibility with OSC 1.0) @Jamie I don't know liblo so well, but you might want to check if it is using the 4-byte-header for OSC-over-TCP. Roman _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
