j_kusel

I'm trying to adapt a Conway's game of life patch for use with my Monome 256. I've been sending coordinate dumps from a 16x16 matrixctrl object directly to the Monome, but it can't handle 256 led state updates at the same time. In order to remedy the problem, I would need to send only crucial updates to the Monome, meaning I have to filter out all redundant coordinate messages every time there is a matrixctrl dump.

Is there an efficient way to compare two states of a matrixctrl object (essentially, two different sets of 256 coordinates) to eliminate redundancies? For example, if the previous iteration had the button in the 4th column, 5th row turned off (4 5 0), ensure that the next batch of data did not send (4 5 0). I tried the zl.compare object, but I didn't get very far without a good way to delay the comparison of the two batches.

comparing-subsequent-matrixctrl-states

this is what I came up with-- it's ridiculously convoluted for such a simple operation, but seems to work

(only did it for a 4*4, so you'll need to modify the / and % boxes)

Edit-- duh! of course like steve says would be simpler it in jitter

this is what I came up with-- it's ridiculously convoluted for such a simple operation, but seems to work
(only did it for a 4*4, so you'll need to modify the / and % boxes)

Terry: I see the logic here, and I was messing around with [zl.reg] as a storage system as well, but I couldn't get anything more efficient...

nicolas: Your jitter patch worked, thank you so much! Still trying to understand the logic here... I was trying to eliminate the [delay 50] object that staggers the two states, and miraculously enough, it worked when I deleted it and the solitary [t b] in the subpatch. I have no idea how the timing works on that... >.<

Comparing subsequent matrixctrl states?