After Native Instruments announced its new controller, Traktor Kontrol F1 (a very colorful grid controller (with some faders and knobs), designed for the new Remix sample decks in Traktor 2.5) and also heavily inspired by a local DJ friend of mine, I decided to make a mapping for my button pad.

The idea was to test/demonstrate the use of different colors on my device and see whether it was possible to fully operate Traktor with just one grid controller. I believe I covered all the major controls apart from scratching (sorry guys), I think it works best with prepared sets and hot-cues.

Traktor’s MIDI-mapping options are very powerful and flexible, really amazing job from Native Instruments there, BUT there is completely no automation for this very repetitive manual task. Basically you have to manually chose all the GUI elements, signal types and note values from drop-down boxes, no “click-n-press-key” mappings that are found in DAWs and you have to map everything twice, for input and output. It took me 4 freaking days to finish the mappings.

The device is split in half for Deck A and Deck B, so all the controls are mirrored on both sides. On the top there are FX controls, then Volumes and X Fader, Play and Cup buttons, all of the above are constant controls. Then I used modifiers to create “pages” or tabs for the rest of the things like tempo, loops, cues, EQ, and loading tracks. At first everything looks like a rainbow-puke, colorful mess, but actually everything is organized in a logical manner. I have prepared some diagrams to help you visualize how everything is layered.

So here are the constant controls.

Track progress and Tempo control pages.

Hot-Ques and Loops pages.

And finally the EQ page.

You can download my mappings from here.

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.

Since things didn’t work out as smoothly as I expected, no proper information on the net, nor anyone wrote a library for it; spent few sleepless nights trying to figure it out, things seemed doomed.. I decided to contact Spark Fun for more technical info. Within an hour they answered me, was really helpful but tried to answer as much as he could and gave me a fresh set of ideas.

After going through the schematics of the board and its original firmware code, I realized that the USB board has two ATmega328 micro-controllers. As opposed to the ISP board that has only one that controls the LED and button matrix . Basically the USB board acts as an ISP board with a built in “Arduino” to control it. So the idea was to burn an Arduino bootloader onto the Master controller and just use it as an Arduino, easy I thought.

Not so much as it  turned out. I needed an AVR programmer, which of course I did not have. But fear not, to the rescue came the Arduino Mini Pro boards I got earlier, they can be rigged and used as programmers (sounds like a fun party). Furthermore, I had to do a small dirty trick to disable reset on the Mini Pro, basically put a capacitor between the Reset and Ground pins. But none of the boot loaders worked properly and I was getting desperate again. Also the board lost its USB API so I tried to re-compile and restore its original firmware.  And so it struck me, why not just modify the existing firmware to send midi data directly whenever a button is pressed and also light up that button. Of course this would be the optimal solution as I would not need a driver application to run the whole thing, just route the MIDI traffic through to my applications.

After more than 5 days of less than 3 hours sleep per day, endless testing, trial by error and just aimlessly poking around I finally get a MIDI signal and a led on! Victory! The firmware still needs a lot of optimization but at least now I know I’m on the correct track, and can finally get a good night’s sleep without commands and diagrams on my mind!