[PD] bi-directional OSC over TCP from liblo

Roman Haefeli reduzent at gmail.com
Sat Nov 10 11:24:45 CET 2012

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)

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.


More information about the Pd-list mailing list