On 10 Nov 2012, at 17:10, Martin Peach martin.peach@sympatico.ca wrote:
On 2012-11-10 05:24, Roman Haefeli wrote:
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?
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 latest version of liblo does exactly this. See liblo-0.26/src/send.c at line 411. It actually sends a packet containing only the length of the OSC message that is sent next.
Thanks everyone, for the helpful suggestions and insights.
It turns out that liblo-0.26 does indeed use the 4-byte header "extension", however the current liblo git revision also contains functionality for using SLIP instead. I tested this with [unpackOSCstream], and I am now able to correctly receive OSC messages over TCP from liblo just fine.
In case anyone finds this thread, looking at a similar issue, the solution on the liblo side is (with liblo from git), to add a call to lo_address_set_flags() on your lo_address before calling lo_send_*, i.e.:
lo_address_set_flags(address, LO_SLIP);
best,
Jamie