[Max] Arc Patch Programming Tips

[ppqq]

In exploring the new arc via max, I’m coming up against some surely familiar territory. For example, I can easily overwhelm it/serialosc with too many update events.

Digging in to some old threads, I see folks have tackled similar issues before. From the archives:

• arc-patching-troubleshooting-thread
• arc led trail - issue or normal?
• arc-osc-etc…

and more recently:

Rate-limiting led messages

Hi, Is anyone of you rate-limiting the led messages you send in your apps to the serialosc server? While working on a SuperCollider app (example code for documentation purposes) using an arc2 2012 edition and a monome 64 2012 edition all leds on the grid often stop working and black out. Restarting serialosc does not help. Reattaching the grid seems to be the only way to fix the problem. The problem could have to do with the app sending too many messages ("/grid/led/level/map") in too short t…

Arc questions: Input overload? bitmask?

Im doing some dev for the arc, and I’ve found it’s pretty easy to overload the input. If I send one osc message to serialosc on each turn message from serialosc, many of the messages do are lost somewhere in transmission. Has anyone tested what the maximum reliable rate is for sending osc messages to the arc? I’m using a Walnut edition, from (I believe) 2011. One other question – In the docs on the grid, there is a serialosc protocol for sending a bitmask to explicit set many LEDs simultaneo…

Any new wisdom? Other threads of potential interest?

Besides using the more efficient map commands, are there are other approaches to avoid dropping messages?

Thanks in advance for any pointers!

(FWIW: I’d be happy to start collecting advice in a shared wiki if the interest is there.)

[jah]

Hi,

In that referenced thread I used “/grid/led/level/map” commands and I still overload the monome device (or serialosc) to the point that the device crashes. See tehn’s reply on using a timer and working with “dirty” flags to limit output rate:

Rate-limiting led messages

it sounds like your app is event-driven, ie. refresh happens on new key/encoder data. this indeed may lead to super-insanely-fast LED refreshing, which you actually can’t even visually distinguish. a different approach (that used in the module firmwares, and MP js in max, for example) is timer-driven. basically “events” like key presses etc set a dirty flag if they do something that requires a visual update. then the refresh routine operates on a timer (30ms is plenty) and checks the dirty flag…

I haven’t tried it but I’m quite sure it will make a difference.

One interesting reflection is also that I only seem to be able to crash the device when both encoders on my arc are rotated simultaneously. Each rotation in that code updated the grid with map commands.

/Anton

[ppqq]

In that referenced thread I used “/grid/led/level/map” commands and I still overload the monome device (or serialosc) to the point that the device crashes.

Good to know. FWIW, liberal use of the change object (to avoid redundant refreshes) helped a lot for me in addition to map but I can reliably make things crash nonetheless.

As for @tehn’s suggestions, they sound spot on. If I make any useful headway, I’ll report back.

Cheers!

[ppqq]

@Leverkusen’s questions about new arc experiences on the new arc recipients thread reminded me that I never followed up here. Anyway, the TL;DR is that rate-limiting via a timer (a la @tehn’s suggestion), worked great.