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.

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!

Next step for my project, were the Button Pad Controllers. There are two boards, SPI slave board, and a USB master board with USB API. Should be straight forward, or so I thought..

The USB board had two JST connectors, one for the USB cable and one for 5V Power. To make my life slightly easier, I also got a USB breakout board and finding out which was the right way to solder the cables was matter of reading through the product comments since it was not documented.

With the board oriented with the LEDs down, and the ICs facing up, turn it so that the USB JST connector is on the left side
The pins (from top to bottom) are:
USB Data -
Vcc
Gnd
USB Data +

Now the tricky part was that each board had to be individually configured for the number of boards in the whole system, for the USB, big deal, just send $0302\r over serial and job done. Now the SPI board is a different story. The documentation showed a waveform diagram of signals it had to receive to activate the command mode. After blankly staring at it for a while, I finally realized that it showed the bit sequence, 1 followed by 0×01 which is the set board command followed by 0×02 which is the command parameter ( in this case 2 boards)But the bits had to be sent in Least Significant Bit First order.

After aimlessly looking for more specific documentation or code examples, I started poking around with Arduino’s SPI library and shiftOut() command and successfully came up with this:

#define CS 10
#define MISO 12
#define SCK 13

void setup()
{
  pinMode(CS, OUTPUT);
  pinMode(MISO, OUTPUT);
  pinMode(SCK, OUTPUT);
  digitalWrite(CS, LOW); 

  delayMicroseconds(10);
  shiftOut(MISO,SCK,LSBFIRST,0b01);
  shiftOut(MISO,SCK,MSBFIRST,0b10000000);
  shiftOut(MISO,SCK,MSBFIRST,0b01000000);
}  

void loop(){
}

Now the actual USB API is quite generic, and not very usefully in my purpose. The device just sits there doing nothing, waiting for a command. So you have to manually call for buttons status and manually set led colors by sending different commands and it again, every time it would return the buttons status. Now this created a great deal of latency.. I made a Processing sketch to drive the whole thing, but it is slow, by slow I mean SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOW…

The idea was to analize the receiving button status, send back a set color command to light up the pressed button, and then transform the parameters into MIDI data and forward it to the virtual MIDI port. Here is how all this worked out:

Part II: