UDP - oscDecoder bug? data glitches in receiving arrays of numbers over OSC

Hello,
When repeatedly receiving an osc message (’/contours’) followed by an array of ca 1 - 30 random integers of the range of 0-99, at the rate of between 4 and 20 messages per second, it happens at irregular intervals that some of the integers received by vvvv have large values (above 99), that differ from the values sent. The same error occurs if sending an array of floats. It is independent of whether the size of the array sent is constant or if it changes. It may sometimes take several minutes before the error appears, but usually it is quite frequent (several times a minute).

I have tested this by sending such test data from SuperCollider, from Processing, and from PD (Pure Data), all of these running on a Mac. The same error occurs with all three of the above environments, so it is highly unlikely that the error is on the senders side.

I have tried changing the buffer size and the discard/concatenate mode on UDP but this did not have any effect.

Also, I tried testing if all numbers of the received spread are less than (<) 100 with a less-than node object, but it seems to have a bug too: Try running for example a linear spread of 10 or more elements with a range of -8 to 8 and testing for < 10: not all comparisons will return “1”. The range of the spread may have to be different for the error to appear.

The test programs in SuperCollider and Processing and the vvvv patch are included below here, but can also can be downloaded from:

http://earlab.org/uploads/vvvv/osc_receive_bug/

Thanks in advance,

Iannis Zannos

— Processing code: —
/**
Debugging glitches in values sent to vvvv from SuperCollider.
Trying to see if the same glitches will appear when sending continuously arrays
of 16 random integer values from 0 to 99, via Processing.
(as this happens from SuperCollider)

based on:

  • oscP5sendreceive by andreas schlegel
  • example shows how to send and receive osc messages.
  • oscP5 website at http://www.sojamo.de/oscP5
    */

import oscP5.;
import netP5.
;

OscP5 oscP5;
NetAddress myRemoteLocation;

void setup() {
size(400,400);
frameRate(25);
/* start oscP5, listening for incoming messages at port 12000 */
oscP5 = new OscP5(this, 10000);
// address of vvvv here:
myRemoteLocation = new NetAddress(“192.168.5.66”, 9001);
}

void draw() {
OscMessage myMessage = new OscMessage("/contours");

for(int i=0; i<16; i++) {

 myMessage.add(round(random(0, 99))); 

};

oscP5.send(myMessage, myRemoteLocation);

background(0);
}

— SuperCollider code: —

/* iz 080822
send dummy data to vvvv to test connection.

// set the address to the vvvv client’s machine here:
~addr = NetAddr(“192.168.5.66”, 9001);

~rate = 0.05; // this rate sends 20 times per second.
// errors occur earlier that way, but also slower rates will produce this error.

// start a routine that sends to vvvv:
r = {
loop {
~rate.wait;
addr.sendMsg(’/contours’, *Array.rand(16, 0, 99).postln).postln;
};
}.fork;

oscreceivedebug.zip (6.1 kB)

helohelo

*Also, I tried testing if all numbers of the received spread are less than 100 with a less-than node object, but it seems to have a bug too
no. please note that in your attached patch the iobox that says 1000 actually is spreaded and has some more random values set to 15 more slices. see with the inspektor. this explains why you think the < node has a bug.

*When repeatedly receiving an osc message (’/contours’) followed by an array of ca 1 - 30 random integers of the range of 0-99
now i have only tested with your provided pd-patch. note that it actually sends values between 0 and 128! that is what the ‘drunk’ object outputs.

anyway i do get random wrong numbers, but only if the UDP (Server) is in concatenate mode. this is a bug. in discard mode i cannot reproduce your described behaviour though. and the concatenate mode here is supposed to only make sense if you are receiving multiple osc-messages with different addresses (which does not seem to be the case in your case).

  • can you confirm that it works for you in discard-mode?
  • also if you would send in osc-bundles you shouldn’t see the error in vvvv (the osc-decoder discards osc-bundles if there are more than one received per frame)

fixed that a little for beta>17. hope that really works.
now if you have the UDP (Network Server) in concatenated mode you have to set the ‘Delimiter’ pin to ’ ’ (= a single space). like this i hope that concatenated osc-messages can reliably be distinguished.

still using bundles is best practice.

Hello joreg,

Thanks for explaining about the second argument to the < node being a spread.

You are also right about the drunk object sending values 0-128. This is a difference from the SuperCollider and p5 examples that I failed to document.

I have tried the discard mode and got the bug previously. But it may have been that I was not careful about actually setting to discard for some reason. I will try again and also test with bundles, and let you know.

You say:

  • the concatenate mode here is supposed to only make sense if you are receiving multiple osc-messages with different addresses (which does not seem to be the case in your case).

I actually need to send to vvvv messages that have the addresses /contours, /zero_contours and others. Does that mean that I have to use concatenate mode?

Where can I get the version beta>17 that contains your fix? On the vvvv.org website I see vvvv_40beta17.zip (12.11 Mb). Is that the correct one?

Iannis Z

he means beta18, and it’s coming out soon, i hear…

*I actually need to send to vvvv messages that have the addresses /contours, /zero_contours and others. Does that mean that I have to use concatenate mode?
yes, that would need the concatenate mode or better: make sure to send them all in a bundle. also if that is not possible you could send the different addresses on different udp-ports.

right, beta>17 is (as of this writing) still upcomming…

  • yes, that would need the concatenate mode or better: make sure to send them all in a bundle. also if that is not possible you could send the different addresses on different udp-ports.
  1. I do not send all different messages at the same time, but at different times. Do I still need to use concatenate mode?

  2. I tried again with discard mode and made sure this is actually the mode used. The same problems appeared. The strange thing is, the problems appear on SuperCollider and Processing, but not on PD (if my observations are accurate). So that might be a problem of encoding, some low level incompatibility with the encoding of Integers and Floats in OSC implementations between SuperCollider-Processing and PD-vvvv. (I should mention it is out the question that OSC sending in SuperCollider is in itself buggy on that level, because if that were the case practically no performance on SuperCollider would be possible). I still need to make a patch with pd forwarding data from SuperCollider to vvvv, but I have not found the OSC receive object in PD yet to do this.

  3. I tried sending bundles but OSCdecoder could not recognize them. Could you post an example using bundles so that I can use i to test this?

Iannis Z.

  • ad 1) I do not send all different messages at the same time, but at different times. Do I still need to use concatenate mode?
    if you can be sure that they arrive not within one vvvv-frame you can use discard.

  • ad 2) ok, i will try with processing…

  • ad 3) in pd see the helppatch of SendOSC on how to send the message in bundles. how did you try to send bundles and oscdecoder didn’t recognize then? there is nothing to configure on oscdecoder. it will autodetect bundles.

Hello,
After testing sending bundles from SuperCollider, I can confirm that bundle reception is without errors. However, it is certain that reception of single OSC messages contains occasional errors in numeric data. The frequency of these errors makes single OSC message reception practically useless if one is sending a lot of data.

Unless single message reception is corrected in the next version, I would suggest including a comment in the OSCdecoder and UDP help files to indicate that OSC should be send in bundles, not single messages.

Iannis Zannos

still strange that those errors would occur when: not sending in bundles and using discard mode.

anyway please report back when you tested with upcomming beta18

decoding multiple single messages fixed for beta>18. UDP (Server) can now output multiple messages received in one vvvv-frame as a spread (no more need for concatenate), which can be directly fed into the new spreadable OSCDecoder.

also the value-glitches should be gone with this fix.