Rate-limiting led messages


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 time. I suspect this since the visually oriented app I work on lets the arc2 control all 64 grid leds with various brightness, each encoder “enc/delta” message practically gets transformed into a “/grid/led/level/map” and as you might know the optical arc2 encoders are very sensitive.

Another interesting observation is that I’ve only gotten the grid to error out while turning both encoders on the arc2. It never happens when I use one encoder solely.

I’ve tried searching for similar reported issues but cant find any. Does the fact that I need to reattach the grid imply that the monome firmware crash? If anyone else is doing rate-limiting, how do you go about? What rate is reasonable?

If anyone of you with an arc and vari-bright monome want to try my SuperCollider code out let me know and I’ll post the code.


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-- then does a refresh if needed. this way execution is much more predictable, and you’re saving a ton of cycles.

note that you can clog the OSC pipes, which is a totally different but related issue.

would be good to see the code to assess your methods.

1 Like

This sounds like it could also be a power issue. What kind of computer / USB ports are you going through? Using a hub?

@tehn i’ve noticed the same thing on the 2012 series, but with led/level/set messages. sometimes the first quadrant will completely crash, requiring re-pluggling the device.

for example. this crashes the first quadrant 100% of the time


Yeah it’s event.driven with super-insanely-fast LED refresing. I considered a timing based solution but as I’m writing documentation for SerialOSCClient I did not want to make code too complicated.

I’m a bit worried on the device crashing. It sounds like @elquinto is experiencing the same thing. I do not use Max/MSP anymore though so I cant try the patcher code above.

My code:

  • Drop new version of SerialOSCClient into the SuperCollider Extensions folder overwriting any previous sc file, and recompile SuperCollider class library. SerialOSCClient.sc (31.2 KB)

  • Plug in a grid and an encoder - this should work for all sizes.

  • Evaluate the code in this Gist:

Grid presses in first top left quadrant positions a dot that may be resized with encoder 1. Encoder 2 let user control transparency. Using both encoder 1 and 2 simultaneously mostly crashes the grid for me (both on Windows 10 and OSX Snow Leopard). There is no sound. I wrote this code when toying around with “/grid/led/level/map” and vari-brightness.