New grid - LEDS stops working / SerialOSC-overload

So I just got my new Grid and I ran into something.
It seems like it can get overloaded with messages, which makes the leds stop responding.
Buttons still work.

It seems it happens MUCH easier with the /grid/led/level/set message rather than grid/led/set message.

I have included a video and a patch to demonstrate the problem.
I can not remember this happening so easy with any of my other grids (earlier models)

Any idea what’s going on here? The biggest problem is that I have to unplug and replug the device to get it to work again.

LEDDEMO.maxpat (20.7 KB)

Video: Video 30 07 2021, 12 23 15 - YouTube

Hope it is ok that I tag @tehn

Edit: Macbook pro M1, newest version of Serialosc (downloaded yesterday).

1 Like

Hey! At the risk of jumping the gun, this behaviour has been observed recently in relation to control:

Hope that’s helpful! I’m not sure if @dan_derks has any other updates from that post :slight_smile: I thought I’d just share that now in case this was time-sensitive!

3 Likes

correct— there’s a firmware bug in the new grid that i’m working on now. this is the same case demonstrated by the control patch linked above: wickedly inefficient use of the serial bus, which max patching sortof encourages by its very nature. a quick fix ahead of the firmware fix is to use the hotpatch that @dan_derks made— it accepts /led/level messages and packs them into /led/map which is extremely more efficient.

(@dan_derks do you want to post the patch individually as a little howto?)

5 Likes

mornin’ y’all :slight_smile:
@Fardles , good eye! thanks for linking! :gem:

here’s the abstraction + the relevant JS file: led_array.zip

how to use it:

  • the led_array patcher collects single LED messages into quad-segmented map messages, which draw 64 LEDs in fewer bytes than 64 single LED messages
  • the patcher also mimics the LED drawing approach that norns scripts adhere to:
    • each time an LED is updated, a grid_dirty flag for that quad is flipped to true
    • every 15ms, the grid_dirty flags are checked
      • if a quad’s flag is true, then that quad’s LEDs are redrawn
      • if a quad’s flag is false, that quad is untouched
  • the led_array patcher will output these messages as:
    /monome/grid/led/level/map X Y Z
    so if your patcher requires a different formatting, just use a [route] to strip the message down to the X Y Z and [prepend] your own formatting to the X Y Z, as demonstrated below

so here’s LEDDEMO re-formatted to use this approach: LEDDEMO.zip

i let it run for 5k iterations before the rapid flashing made me feel wiggly, but that ought to work, @KristofferLislegaard !

5 Likes

20 char of fantastic!

1 Like

Hi.
Looks like this is still an issue? Either way thought I would post my fix for SuperCollider here in the hopes that it is helpful to someone. Maybe not the best solution but it has worked for me.
Would love get back to using MonoM.levset.
Later.

~state = 128.collect({0}); //current state of grid as 1d array

(
~lights = Routine({ //breaks single array of 128 values into two 8x8 blocks of 64
	var left, right;
	left = Array.fill(64, {0});//left half of grid
	right = Array.fill(64, {0});//right half...
	loop {
		for(0,127, {arg n;
			var i = n.mod(8)+((n/16).asInteger*8);//0..7, 0..7, 8..15, 8..15, ... etc.
			if (((n.mod(16)/8).asInteger == 0),//0x8, 1x8, 0x8, 1x8, ... etc.
			{
				left[i] = ~state[n];
			}, {
				right[i] = ~state[n];
			});
		});
		~m.levmap(0, 0, left);
		~m.levmap(8, 0, right);
		0.1.yield;
	}
});

~lights.play;
)```