Forums > MaxMSP

To much OSC data over wifi to the Lemur causes omissions(?)

June 9, 2013 | 10:44 pm

I am not so sure about this: I have created a large template with max and the iPad Lemur app. Both interact with each other and in Max I change the user surface with a button within a split second, hiding, relocating or resizing controller objects. However, although everything seems to work, sometimes some objects, that should be hidden or resized, stay as they are. But it’s totally random! Most of the time everything is ok, other times this object does not get changed, other times another one … and then it works again.
I have checked the messages going to the udpsend object, and they were definitively sent! On the iPad, I do not have an input monitor.
To my understanding this could only have to do with either my Wifi network omitting data or the Lemur app (iPad 1) suffering from to much data in a short time. I highly doubt the second alternative, though. What would you guys look into first, to hopefully solve this issue?


June 10, 2013 | 4:18 am

It’s not like I’m really answering your question, but there is something more suited for using Max/MSP with iPad as controller, it’s Fantastick by Pink Twins, as far as I know there is no such performance issues at complex patches.


June 10, 2013 | 6:32 am

when sending lots of messages very quickly, some of them *may* be lost…
one solution :
try sending bundles of messages using the OpenSoundControl external.

Mathieu


June 10, 2013 | 7:11 am

I have this problem as well, and it’s not just with Lemur, it happens with any of my apps that use UDP. It’s not necessarily related to sending a large amount of data either.

I send both continuous messages (slider moves, say) and one-off text messages (to change the label of a slider)

As long as there are a few slider changes in one go, most of them will make it, but every now and again, a text label doesn’t get changed and I have to resend it.

I wish those apps would allow both UDP and TCP messages to be received (and sent)


June 10, 2013 | 7:45 am

Thank you, guys! So I am not crazy … ;-)
About that OpenSoundControl external: I have it installed, but I can not really wrap my head around its functionality. Let’s say, I have a "send OSCtoLemur" object that collects all data for the Lemur and a "receive OSCtoLemur" object. How do I connect that OpenSoundControl external, "receive OSCtoLemur" object and the "udpsend 192.168.1.1 8000" to make it work. OpenSoundControl does not have a help file, so I don’t really understand how it is used.

@DHJDHJDHJ: It is not really a few seldom omissions, more like quite a few and frequent ones!


June 10, 2013 | 8:49 am

I have found that the quality/strength/distance of the wifi system impacts this significantly. I did quite a few experiments when I first ran into the issue, including sending OSC data from Max on one computer to another computer using both wifi and ethernet.

When my laptop started to get far from the wifi router, the quantity of missed messages increased dramatically.


June 10, 2013 | 8:59 am

That was also my thinking. Maybe I get a better wifi router and try getting it closer to my workspace.
Regarding the OpenSoundControl external: who knows what it does and is it of any use in this case? Mathieu suggested sending bundles using this object. That sounds like a solution, as it would either send everything or nothing at all. I am just not sure how to do that, as sending OSC messages into that object and watching the output via print, nothing really happens …


June 10, 2013 | 11:45 am

From the help file: "Bang closes all open bundles, sends out the buffer and resets."

In other words, when you send a bunch of OSC messages into OpenSoundControl they are parked in a buffer. They are sent out all at once when you give OSC a bang as input.


June 10, 2013 | 3:56 pm

The attached file does it! Setting the delay value to about, I don’t get any omissions any more! Thanks for your input, guys!

Attachments:
  1. DelayOSC.maxpat

June 10, 2013 | 3:57 pm

The attached patch does it! Setting the delay value to about, I don’t get any omissions any more! Thanks for your input, guys!

Attachments:
  1. DelayOSC1.maxpat

June 13, 2013 | 6:12 am

Setting the delay to about "what?"

I’d love to try this to see if it fixes my issue, which I had just about given up on solving.


June 13, 2013 | 6:43 am

To 8 in my case. This patch delays proportional, depending on the number of OSC messages sent per second. When there are omissions, just set the delay up, until they disappear.


June 13, 2013 | 6:45 am

ok — in my case, I was seeing the problem (missed updates) even if I just sent a single message from time to time, so not sure this will help.
But I’ll give it a shot.

Thanks


June 13, 2013 | 6:50 am

Also, what’s the reason for the bang object underneath the OSC-timetag? Is it to make the object run at low priority?


June 13, 2013 | 12:11 pm

You can leave out either the bang object or the trigger bang bang. I just had this in for testing manually. It is important, however, that you send a bang to both inlets of the timer!
The timer then determines how much time elapsed from one OSC message until the next one. If this is more than one within a millisecond, the if module (if $f1<=1. then 1 else 0) sends a 1 (true), otherwise a 0 (false). Then a count starts for every further OSC message more, that has been sent within less or equal than a millisecond. Hence, for every such OSC message within a millisecond the delay is set proportionally higher (by the 10th of a millisecond).
It does work! However, if you even have dropouts with single OSC messages, this might not help you. My omissions only occured with a large number of OSC messages sent at the same time (dumping a collection).


June 23, 2013 | 11:49 am

this hasn’t worked for me unfortunately. I’m still seeing the same lost-packet behavior as I was before. I tried a value as high as 50 (I’m sending 264 OSC messages to the lemur in one go).

has anyone had any luck sending a bundle to lemur? I tried making 8 bundles out of the 264 messages. Each bundle contains ints, floats, symbols, and lists of symbols. Unbundled, and aside from the lost packet problem, everything makes it to lemur correctly. Now, once bundled, only the values that are floats get through. Everything else is ignored.

I have increased the OpenSoundControl object’s buffer size, and tested to ensure that if I dump the individual OSC messages inside of the bundle that they look right in the print window. I could live with converting all values to floats, but converting the ints to floats didn’t help. Even if it had, I’m not sure how I would have converted symbols to floats… could it that only lemur faders and pots know how to decode osc bundles correctly? I’m stumped.

I feel I may be barking up the wrong tree here if it is a lemur limitation, but I thought I’d throw a dart in the dark in case there is something I’m missing.


June 23, 2013 | 4:54 pm

IIRC there’s some stuff you can do with deferlow in this situation, too?

I’ve done some heavy-duty things with brute-forcing things in place on Lemurs and ipad-Lemurs in the past, and that usually did the trick, if I’m not mistaken.


June 24, 2013 | 11:39 am

I’m still troubleshooting, so take this with a grain of salt. The behavior in my case is that if I command the data dump from Max by sending an OSC message from Lemur to Max, there are virtually no packets lost. Now if I dump the data to Lemur without any prior Lemur-to-Max messages, the packets lost are substantial. As such, I feel there may be an issue with Lemur or maybe the iPad where it is not actively listening, and it seems that making Lemur speak forces it to listen.


Viewing 18 posts - 1 through 18 (of 18 total)