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 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 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
    • 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!