On 10 Nov 2012, at 17:10, Martin Peach <martin.pe...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
