[PD] bi-directional OSC over TCP from liblo
jamie at postlude.co.uk
Sat Nov 10 21:59:55 CET 2012
On 10 Nov 2012, at 17:10, Martin Peach <martin.peach at 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?
>>> 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.:
More information about the Pd-list