Hi, I’m using a OSC In CHOP to get skeleton data from a Kinect (30 samples/sec) and parameter values from Max/MSP (not very frequent). OSC In CHOP is taking a ridiculous amount of time to cook: 16.5ms
I tried using the OSC In DAT but failed at getting meaningful data from it. Any suggestions?
16,5milliseconds equals 60 frames per second. What is the issue exactly?
That’s a good point. However, I have many operators running at 60fps and none of them take 16.5ms to cook. A quick look at a Resample CHOP @60Hz shows a cook time of 0.012ms. What this means in practical terms is that my total cook time can be doubled from 15ms to 30ms because of a simple OSC in CHOP.
16ms is super high. How many channels are you sending and how often are the packets being sent?
I’m sending 79 channels. Half of them at ~30fps the other half are one-time triggers. This picture shows the oscin1 panel as well as the preferences. The next picture shows the performance monitor.
Try setting the maximum queue to 1 or 2 frames. Certainly seems like a bug of some sort though
So OSC In CHOP is reaching an absurdly high cooking time. I don’t mind using a DAT if it’s more effective. I just could not get it to work 100%. The snippet doesn’t show much. Does anyone have a useful example they can share?
Ok I want to revisit this post because I noticed something else. Aside from the OSCin bug making it take ~10ms to cook, short UDP messages might not be picket up by a CHOP. If I send shot 20ms on/off messages, only a fraction of them get picked up by a Trail Chop following a OSCin chop. 100ms long messages in the other hand all get picked up. OSC/UDP DAT objects have the same behavior.
What is interesting is that the messages are still going thru, because I can see the ‘line connector’ between operators flashing every time a message is sent. However, the trail chop does not pick them up. Is this a sampling problem? Maybe the on/off message is happening in between frames?
Yes, CHOPs have the inherent limitation of sample rate, so fast incoming events may not be represented in trail histories, etc.
For continuous slider type data where discrete events are not relevant,
CHOPs are often sufficient.
DATs on the other hand, are event driven, and provide callbacks and row entries for each event as they arise.
“OSC/UDP DAT objects have the same behavior.”
To be clear, DATs are retaining all the data correct?
In terms of speed, my simple test passing 200 channels in about a msec, on my specific setup,
with your parameters.
Is it possible you are sending very long arrays for each channel value shown?
