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.
[packOSCstream] implements this standard by use of [slipenc].
i don't know, how liblo packetizes the data for tcp/ip, but if it is no
t SLIP, then this is a bug in liblo (if you want a "standard" behaviour).
if it *uses* SLIP, then the bug would be in [unpackOSCstream].
check the obvious, e.g. whether [slipenc]/[slipdec] are correctly
instantiated in the *packOSCstream abstractions.
in order to find the real cause of your problem, it would be great if
you could send the output of [tcpserver] when sending a single simple
OSC-message (like "/foo") from liblo.
gmdsart
IOhannes
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
