On Mit, 2014-05-14 at 12:35 +0100, Jamie Bullock wrote:
> Hi,
> I'm trying to understand a problem I'm having with unpackOSCstream...
> I am receiving a series of OSC messages using mrpeach/tcpreceive, the
> first outlet of which is connected to mrpeach/unpackOSCstream
> unpackOSCstream wraps mrpeach/slipdec with a default packet size of
> 65536
> With the default packet size I get an error "slipdec_list: input
> packet longer than 65536" for the OSC message "/send 236 cc62 0" and
> subsequent messages are dropped.
> If I double the slipdec packet size to 131072 then everything works
> fine.

Assuming that [slipdec] works as designed, one possible scenario is that
the sender packs many OSC packets into one SLIP packet, thus the SLIP
packet length is actually longer than 65536 although none of the
contained OSC packet is of that size.

If you assume a bug in [slipdec], you'd have to inspect more deeply the
data it is receiving. This basically means: How many floats do you count
between the start byte 192 and the end byte 192?

> This seems a bit strange as I am not sending any packets longer than
> 65536. 

How are you generating the OSC-in-SLIP packets? With Pd? With
[packOSCstream]? Or with some other software? Are you sure the other
software adheres to the OSC 1.1 standard?


Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 

Reply via email to