I have a lot of updates on the project since last time, tons of changes made mostly on driver application. I discovered that one of the main sources of latency was the serial port class of Processing, so I decided to re-implement the driver in C#, since Max/MSP and Ableton Live are not running under Linux anyway.

Also this gave me the opportunity to implement monome applications compatibility and it works pretty much flawlessly with any Max patch I threw at it, tough I did not implement AutoConfig protocol so its limited to the monomeOSC version of applications that run with OSC extensions. Also further more, worked on reducing latency and read/write buffer bottlenecks with pleasing results, now I can finally enjoy mashing on mlrV

Also made some silly Processing sketches, like displaying 8×8 3bit image files on the pad.

Plus designed more plywood face plates for the pad and other devices.

This gives me the opportunity to introduce my new device [k]ontrolPad. This controller consists of 4 faders, 8 knobs, 8 buttons with LEDs, XYZ accelerometer and an infrared proximity sensor. But for now unfortunately only the buttons and LEDs seem to work properly. The rest of the analog values are quite unstable and must be normalized, also I have to figure out a way to send their values synchronously and only when it changes, instead of just sending a bunch of redundant data over the serial port, which by the way dead-locked my serial port in Linux..

And finally, since a lot of people asked me for, I have released the firmware and drivers, also some processing sketches. You can find everything on my Bazaar repository, just browse the code and you will find a zip/rar file to download. Or use the following direct links:
Driver
Firmware
Testing

And a bit older video just to demo it working with Live in MIDI mode.

This is the third part of my epic journey through the world of micro-controllers, MIDI/OSC controllers and all that stuff, and finally I can say that I see pleasing results.

The pad now is enclosed in a plywood case which I designed and cut with some help from Eva. Though the individual boards can be only connected serially, this means that a square 8×8 grid was technically not possible as the first USB board can be only connected to one board in the output port. To solve this I physically arranged the boards in a square, but bent the connectors and connected them with jumper wires in the right order.

Here is the board and buttons layout

I managed to come up with a more workable protocol for the button pad with some good tips from Yiannis. Every time a button is pressed, the board sends a signal of the form #010AFF and #010A00 on release, where the leftmost byte is the board number then the button number and release or pressed state.

To set the LEDs the board receives a command that sets the entire board a specific color if the frame has changed state from the previous cycle. The frame command starts with a command code, followed by the color code and then 8 bytes of frame data. The frame data is split into 4, 2 byte for each board. Then we check each bit to determine if we set the corresponding led on or off. Something similar is going on with the color code to determine which color frames to set. For example $1FFFFFFFFFFFFFFFF sets the whole board blue, and $40001000000008000 sets the lower left and upper right corner LEDs to red. Here is a more detailed diagram for the command.

The color is determined from the color code in this way.

And the frame for one board looks like this.

To run the show I wrote two drivers, one that uses OSC protocol and one with MIDI for Duplex in Renoise and Ableton. You can see a small demonstration in the video. I am also developing the [r]otary encoder panel but i will post about it later on ) Enjoy.