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