Forums > MaxMSP

Comparing subsequent matrixctrl states?

December 19, 2012 | 8:57 am

Hello all!

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 16×16 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.

Thanks in advance!


December 19, 2012 | 9:18 am

Sounds like a job for jitter…


December 19, 2012 | 10:12 am

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

– Pasted Max Patch, click to expand. –

December 19, 2012 | 6:06 pm

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… >.<

Thanks so much guys!


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