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?

Roman