Forums > MaxMSP

Comparing subsequent matrixctrl states?

Dec 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 object, but I didn’t get very far without a good way to delay the comparison of the two batches.

Thanks in advance!

Dec 19 2012 | 9:18 am

Sounds like a job for jitter…

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

Dec 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)

Forums > MaxMSP