9.08.2007

hacking the monome 40h

While waiting for the new xenome/stribe driver circuit board to arrive, I've spent a couple days digging into the monome serial protocol, trying to understand it better and determine if I can use it for the xenome/stribe.

Couple things:

1) my device is upside down and backwards relative to the monome. See, when writing my firmware I started counting at the lower left corner and went up and right from there. My thinking was the xenome is essentially a bank of bargraphs, where 0 is at the bottom of each one, and they're numbered left to right. Then, when designing the led board, I saw that I would have to do a lot of fancy routing to treat each 64-led column with one MAX7221. But if I addressed the leds as a grid of smaller 8x8 grids all stacked together, it simplified wiring considerably. Basically I just made a grid of wires and was able to wire it as a 2-sided board with only a few strategic vias. So now my 0,0,0 is the lower left corner of the lower left 8x8 portion of a 64x16 grid, and 1, 0, 0 is the one on top of it, and so on. But the monome firmware starts with 0,0 at upper left, like a data array:



2) The monome firmware and serial protocol are super-clever. In fact everything about the monome is really kind of this brilliant compact jewel, the firmware and the software and the hardware all conceived as one. The design seems like an art thesis or a manifesto on computing, more than a way to simply make buttons blink on and off. It uses bitwise operations to build and parse the OSC messages, in a similar way to how you address the MAX7221 itself. The firmware sends and receives only 2 bytes in each direction, the monomeserial software does the rest.

As a semi-rusty C/C++ programmer it's been challenging for me to learn all this. It seems very custom-made for the specific device (an 8x8 grid of buttons that light up, driven by a MAX7219/7221 and an AVR chip), and the code is lightly commented. On the other hand, it's designed to scale to treat multiple grids, accept input from additional pots or encoders, and of course the real bonus: it's openSource, there's a community, and Brian has been super responsive to my many noobish questions on the monome forum.

So I'm learning a lot from this exercise, and there's certainly a lot I can borrow, but I might have to stick to my own firmware and a similar protocol. I can still make it compatible with monome apps via OSC.