Sunday, 27 September 2015

Novation Release Custom Firmware API for Launchpad Pro!

The Novation Launchpad music controller has been around for several years in various form; it is a USB MIDI grid controller which is primarily designed to work with the Ableton Live program but can also be used as a MIDI controller on its own.

I am not a user of Live but I have always seen the potential of the Launchpad as part of a standalone MIDI sequencer, like a cheaper Monome. I bought my first Launchpad years ago and immediately got to work writing code to run against it.

 The original Launchpad showed up as a MIDI device (assuming you have Novations drivers installed) and you could open it using your programming language of choice (I was using C++ on Windows MIDI API).

Then when you press buttons you receive MIDI messages (notes for the grid and CC's for the menu buttons). Sending the same messages back to the controller turns the lights on and off. And it is pretty much that simple!

 My real aim was to get something that could run MIDI sequencers that were not tied to a PC, so I started looking at USB hosting from a microcontroller. The original Launchpad was not USB MIDI class compliant (that came with the Launchpad S) but used a custom interface based on interrupt endpoints. I pulled the descriptors and used an FTDI VNC2 USB host chip to implement sequencer sketches, which did work, but I had some issues with the early versions of FTDI's toolchain for the VNC2 and kind of ran out of steam.

Later on I started working on an Arduino shield where the VNC2 would just have the USB hosting duties, with the Arduino running the sequencer sketch. That project is still in the pipeline, but what I always thought to myself what would be REALLY good is if Novation opened up the Launchpad with a firmware API so developers like me could actually load custom firmware for sequencers, etc, into the Launchpad itself (in fact I've been wishing the same for lots of musical hardware – are you listening Arturia, Korg etc.. :)

 Anyway just last week I heard that they have actually gone and done it a couple of months back, with a custom firmware API for the Launchpad Pro!!! I immediately had the credit card in my hand and was unpacking a brand new Launchpad Pro the next day.

Check out the API here

 I can't quite express the awesomeness of this move my Novation!!! OK it may be a pretty niche thing right now, but I hope it sets a precedent where a creation of custom firmwares for these types of device really takes off.

 Anyway, I got started trying to make a version of one of the sequencers I originally built on the original Launchpad and the FTDI VNC2. Novation 's API provides a simple set of callbacks that you implement in your “app”. These are an initialisation routine and handlers for incoming MIDI messages, button presses etc. Plus there is a simple set of hardware abstraction functions for controlling the lights behind the buttons, sending MIDI etc.

 The architecture is 32-bit ARM and Novation helpfully provide a Ubuntu Virtual Machine image of a configured development environment using Eclipse and GNU C for ARM. A default firmware project is provided which it is pretty easy to start playing with. The make process invokes a utility to convert the output HEX files into a MIDI SYSEX which can be sent to the Launchpad Pro over USB.

In order for the device to take new firmware it needs to be set into a bootloader mode (by holding the Setup button when powering on).  I quickly discovered an issue; after uploading custom firmware, the Launchpad was not enumerating as a USB MIDI device any more (in fact it was lost to USB until put back into bootloader mode). After trying to work out what I was doing wrong, I contacted the Novation development team via Github and raised an issue which they have acknowledged and will hopefully soon fix.

Luckily the LPPro does have a “real” MIDI connection in the form of a pair of 3.5mm jack sockets which break out to standard 5-pin MIDI connectors via supplied cables. This “hard” MIDI connection does work, so I have been able to use this for now to get output from my sketch to play an external synth.

When you load new firmware into the LPPro you are actually replacing the factory firmware. The SYSEX file for the factory firmware is supplied with the SDK so you can easily switch back to it, however there is no source code available for the factory firmware. Maybe this is not so surprising, but it does mean you have to take an “all or nothing” approach to customising the LPPro. There is no option to “tweak” the factory functionality without rewriting it yourself first! I hope Novation address this – maybe it would need the high level functionality of, say, the factory “drum” and “note” modes to be ported to the custom firmware API so the source for those could be released for customisation without having to open up all the proprietary low level stuff.

 I am using a Windows 7x64 machine and I did find that sometimes the VirtualBox VM / VAGRANT package was getting in a funny state such that my VM login could not access the source code projects in Linux (probably something I was doing wrong). Also there was the annoying need to copy the output SYSEX file from VM out to host OS on every build so I could upload it to MIDI. I eventually decided to install the GCC-ARM compiler and Eclipse IDE natively on Windows, but that was not too hard and Novations VM package was invaluable to see how the setup should work.

Another thing that gets a bit tiresome is the procedure for putting the LPPro into bootloader mode (a process which needs a manual power cycle of the LPPro and needs USB to re-enumerate, so the LPPro device needs to be re-selected in MIDI-OX before the SYSEX can be sent). When debugging you do this a lot and it gets annoying, not to mention putting extra wear and tear on the power switch. A nice feature would be a special SYSEX command to put the LPPro into bootloader mode without a power cycle and ideally without any USB re-enumeration. Then the SYSEX loader could set bootloader mode before uploading and all the steps included in a makefile (maybe this bootloader command could be “unlocked” via a physical button combination if there is a worry about unwanted firmware updating)

 Anyway, I am not going to complain any more. I applaud Novation for releasing this API and I hope other manufacturers of music and/or other devices follow suit. Interesting times!

This is my first sequencer project, I expect to be doing lots more like this over the coming weeks and months :)

You can get my code (forked repo) here

Or if you just want the sysex

Monday, 24 August 2015

Hammer Pong's Last Stand?

After several months in storage, Hammer Pong is coming back out for a final moment of glory at the Brighton Mini Maker Faire on 5th September Then unfortunately it'll be stripped down for parts... unless you want it?

Saturday, 29 November 2014

A mini mixer for my lovely Volcas

I heart the Korg Volca range! If you don't know them already then, chances are you never will, however - they are a set of self-contained, affordable and  (mostly) analog synth/sequencer modules. There is a drum machine, 303-ish bassline synth, and a versatile 3-voice synth (they tease us with a currently unavailable sampler unit too). I love 'em .... but this isn't a review of them so Google as required..!

Anyway, if you have Volcas you'll need some kind of mixer to combine their audio output for your listening pleasure, Even if you do have one (and I do own a Mackie mini mixer) the spontaneous mini-scratchpad style of the Volca's really needs something simple and lightweight that does not take a lot of setting up, so I decided to make my own passive mini mixer that I could keep set up with my Volcas. I keep my Volcas set up on a guitar pedalboard case so I wanted something I can keep, ready to roll, in there too.

A simple passive mixer would do trick (i.e. just a bunch of sockets and resistors with no power needed) and a Hammond diecast aluminium stompbox enclosure would fit nicely in my setup.

I used stereo sockets, pots and wiring - although I think the Volcas are all mono, so maybe I overdid it there, still - it keeps options open. My design has 4 stereo input channels which are combined into a single stereo output. The passive design works pretty well with the Volcas (the outputs are for headphones so they are pretty hot, an active mixer would be wasting time I think)

I jazzed up the enclosure using a piece of yellow/black 2-layer acrylic laminate which I laser-etched with a lo-fi pic of a good old C-60 (mix tape / mixer, geddit?)

Monday, 15 September 2014

Sound Art and Non-compliant Seagulls

Just had an amazing day at the Fort Process sound and art festival at Newhaven Fort!

It's the first festival I've seen run at the fort, but with its labrynths of tunnels, staircases, passages and caverns it turned out to be the perfect venue. It was rather like being at a mad scientist convention in the dungeons of some Bavarian castle, all resonating with otherworldly chimes, lush drones and earsplitting bursts of static, never being sure what you'll find around the next corner. Often sublime, occasionally ridiculous, sometimes frankly terrifying.

My involvement was with Sara Jane Glendinning's project; The Landing. The concept was that the local seagulls would get involved by landing on a surface made up of sixteen large switch pads on the roof on one of the old gun emplacement towers, enticed by food of course. The pads were set up to trigger arrays of spoken word samples, field recordings and musical sounds when stepped on. These sounds were mixed with the live sound from a microphone on the roof and played to the audience at the base of the tower. A camera on the roof also relayed live images of the pads.

We used a Teensy (Arduino clone) to read all the switches and send MIDI over USB to a Mac running Propellerheads Reason. And it all seems to be working beautifully... except the gulls didn't want to play ball. We tried chips, fish heads, fish guts, our best gull impressions, but they resolutely stayed hovering high above and didn't come anywhere near our tower. Usually in these parts (or at least on Brighton beach) the gulls will gather round to terrorise any al fresco diner like something out of Hitchcock's Birds, or will swoop out of nowhere and make off with the top half of your ice cream. Not the Newhaven gulls though.. they were a bit crap. Or maybe they were just deeply suspicious of a handout. Or maybe they are so used to doughnuts and burgers they have forgotten what a fish looks like...

It was not all lost though.. it was a windy day and occasionally the pads would trigger by themselves. There was a Dali-esque treat in store for those who wandered over to our monitor screen to see fish heads, arranged over what looked like a big chessboard, apparently chatting to each other ("No No No!", "Over Here!")!

The tower

The crap gulls

No no no no!

Thursday, 3 July 2014

HammerPong #5: We Got There!!

So... I might have gone a bit quiet over Hammer Pong recently, but that doesn't mean it hasn't taken over my life these last couple of months!

I've never been much of a handyman - so the most stressful part of this build for me was putting together
the structure of the thing; Things started going wrong from the start when I bought a couple of large MDF sheets from the local DIY store - before realising they wouldn't fit in the back of the car (OK, they were totally bigger than the car). They wouldn't fit in the taxi minibus I called either - so I had to gingerly wheel them back up to the counter for a refund and then order them online, d'Oh!

I was still having my DIY nightmares a few weeks later trying to paint it all in the back garden (flies, leaves, fur from the pet rabbits getting stuck on everything) as well as trying to find some place to store such the thing in my house  without it getting scuffed, scratched and generally messed up (I can see why proper artists have proper studios!)

Anyway, finally it all came together and after a couple of days getting it installed and operational at Woking Lightbox gallery I can finally breathe a long sigh of relief and let my big clunky baby fly the nest!

So if you are really interested in how it all works, read on, we have a lot of catching up to do...

First off I moved all the game code to an Arduino Due since it had the clout (memory space and instruction clock speed) to drive six WS2812 LED strips in parallel without resorting to assembly language or programmable logic. Although I am not sure it was entirely essential, I also buffered the data lines to the strips through 74HCT541s to get nice solid 5V edges for the WS2812's

The large fairground style LED assemblies are all driven from a 24V supply using power transistors to switch on the low side. The transistors are driven by 74HC595 shift registers. I used TIP120's on the large 7 segment display (each transistor switches 3 LED assemblies) but for the single yellow LED assemblies I simplified things by using ULN2803A arrays instead of the TIP120's (At 24V the current is pretty low)

I also decided to add sound - first off I experimented with the fascinating Mozzi synth library (running on a separate Teensy 2 board that I planned to send MIDI to from the Due). After blowing up one amp module (I don't think class-D amps cope well with unfiltered PWM input signals :\) I tried a different amp and was getting a lot of static (eventually I found out this was because my Mozzi output was very low due to a code issue, and upping the gain on the amp added horrible levels of noise).

Anyway, I had to give up on Mozzi (a reflection on my lack of time, not the library itself which looks amazing) and did some very basic sounds using the Tone library. These still run on a separate Teensy, since the Due spends so much time updating the strips (with interrupts disabled) it can't generate Audio at the same time. With hindsight, basic bleeps and bloops do fit with the feel of the game. The winner even gets rewarded with a very crude couple of bars of "If I had a Hammer"!

So all was looking good - I had several components which all tested fine individually and all I had to do was hook them up. Simple!

Well... first issue - my lovely "audio hit to MIDI" converter worked wonderfully, but when hooked up to the serial input of the Due (yes the one that spends all its time bit banging LED strips with the interrupts suspended) about half the MIDI bytes got dropped at the serial input (since the interrupt to buffer them didn't fire before the next byte came in). Quelle suprise! Well, since I wasn't using the hit velocity anyway (I decided it was a bad idea to encourage any additional violence) I swapped the serial connection for a couple of simple HIGH/LOW data lines.

Except... my PIC that reads the audio input runs at 5V but the Due runs at 3.3V and it's inputs are not 5V
tolerant. So, I decided to configure the PIC output lines as inputs (high impedence) allowing the lines to
float high to 3V3 on the Due's pull-up's and just drive them LOW to signal a hit. Great idea! ...but I managed to mess it up.. when I went to install the piece I hadn't got the latest firmware on the PIC (thats fine I thought, I could flash it from my laptop when I got there)... But the older version of SourceBoost C on my laptop did not support the PIC16F1825 and I didn't have the license key to upgrade it (as it was on my desktop back home) Aaaarghh!!!

I kludged it in the end. At least I had the foresight to take the soldering iron with me and I moved the signal lines to the indicator LED lines (the LEDs were all working fine). By attaching the Due input to the point where the 1.5K series resistor connects to the LED I believe/hope/pray that the voltage at this point when the high side of the resistor is pulled to 5V is going to be something like 2V and well within the safe limits of the Due inputs. Anyway it works...

With those dropped character serial problems in mind, I changed the Teensy sound generation code to expect single character messages to trigger sounds, rather than MIDI messages. I struggled a bit with the Teensy (yes now I know that Serial1 is the hardware port and Serial is USB!) but eventually I have sounds, inputs and it all seems to be working. Woop!

Hammer Pong will be showing (among loads of other cool things!) as part of the Giant Electronic Art Show at the LightBox gallery ( in Woking, Surrey UK

Project source code is available here:

Planning the digits layout (started with a drawing from a data sheet!)

Back board with digits laid out

With base, struts and cylinders

Adding the additional panels

More LED's

The big day, in the back of the van

Backplane wiring and LED drivers

Power supplies, Due, Teensy, Buffer/Level Shifters, Input Board and Audio Amp

Tuesday, 13 May 2014

HammerPong #4: LED Strip Refresh Rate Headaches

So onwards and upwards (and back down the other side) .... Time to have a go at making the LED strips that will provide the display surface for the game. I'd already decided I wanted each game strip to be made up of three 5 metre, 150 LED strings mounted side by side and I thought that it might be nice to stagger the centre strip, placing each of its LEDs midway between the pairs of LEDs on either side. I thought that this might help give an illusion of denser pixels and also make it easier to animate the chevron style shapes I've been thinking about for the game.

I did some eBay surfing looking for suitable construction materials and found an adhesive backed roll of 5mm thick, 75mm wide, solid neoprene rubber tape.. This seemed perfect for mounting the 3 LED strips side by side on the sticky side with the remaining exposed adhesive and LED strips with a layer of clear sticky tape. After a bit more searching I decided to try some signmakers masking tape (100mm wide low-tack adhesive paper tape) instead since I thought this would give a nice diffusion of the LED colours.

Sticking down the LED strips went really well. I didn't remove their backing tape since there wasn't much point, they stuck down fine with the backing still in place and it keeps me a few options open if it all went wrong. Must confess I did get in a bit of an angry mess with the paper tape, which was frustratingly difficult to lay down on top of the adhesive in one go and was all too easy to crease or tear. I did end up with some joins, which I wasn't too happy about, but after applying a layer of clear sticky tape to the whole strip it didn't look so bad after all, and once I fired up one of the strips the effect was actually pretty good!

I applied themultiplexing approach I described before, using a modified version of the Adafruit Neopixel Library running on an Arduino Uno. I had replaced my original Toshiba 4514 multiplexer chip with a higher speed Texas Instruments CD74HC4514EN and it seemed to work fine driving the 3 strips together. I had fun trying some nice particle system sketches before having a go at some graphics for the Hammer Pong game.

I tried animating a “puck” shooting along the strip, which all seemed to work fine.... except I was a little bit disappointed with the maximum speed I was getting. I could not see any problems in the code, so I got out the calculator:

150 pixels per strip
x 24 bits per pixel
x 3 strips
x ~1.25us per bit
= ~13.5ms to refresh all three strips
= ~74 frames per second


OK, for video, 74fps would be pretty good! However moving the puck one pixel at a time means the fastest it can tun the length of the 150 pixel strip is about 2 seconds. It gets even worse if we add in the other strip the maximum frame update rate would be halved, and the distance doubled.. That would mean 8 seconds for the puck to reach the opposing player if it moved 1 pixel distance per frame. A bit slow. Hmmmmmm...

Yeah of course this is easily solved by making the puck image move more than one pixel between frames, which would be the usual way of doing things. The problem is that the LEDs are very bright - just like I want them to be - and persistence of vision effects make position jumps between the frames really obvious - you see the image frozen in several locations along the strip, spoiling the sense of fluid movement. I really want single pixel per frame motion to make it look smooth, dang!

So what to do about it? Well the WS2812 protocol sets some base restrictions: The data rate is fixed at 800kbps, so we cannot update faster than 1.25us per bit. Also we have to refresh the entire strip at once due to the serial nature of the load operation (we can't just load pixels that have changed and leave the others). So updating a 150 LED strip will always take a minimum of 4.5ms and there is nothing we can do about that (other than cutting the strip into smaller lengths and addressing them separately maybe... but I don't want to go there!).

But, we do have the possibility of loading the data to all the strips in parallel - so there is no specific reason why we can't load all 6 strips in the same 4.5ms cycle. So, what could stop us doing this?

Well firstly we will need to render all the data into a memory buffer before the strip update (at this data rate we will not have the time to render images on the fly) . Yikes.. thats going to be a lot of memory (by microcontroller standards).. 6 strips x 150 pixels x 3 bytes per pixel = 2700bytes... already more than the 2k RAM on the Atmega328 microcontroller (sad face)

We could reduce this using a lookup table (“palette”) of colour values and storing the palette index for each pixel instead of the 24 bit RGB colour. Lets say we have an 8 bit palette index (up to 256 colours) with perhaps 64 colours actually defined in that 8 bit colour-space.

6 strips x 150 pixels x 1 byte per pixel = 900bytes
plus palette; 64 colours x 3 bits per colour = 192bytes
=1092 bytes total

This is much more doable - and we can save more memory by avoiding storing the palette in RAM.. e.g. by using PROGMEM data stored in the much more spacious 32k FLASH. However the next problem is processing speed...

To be honest I have never had to be so concerned about performance at this level before, ever. But when we are talking about bit-banging at 800kHz every CPU cycle counts. For an ATMEGA328 running at 16Mhz each clock cycle is 62.5ns. Now that *is* pretty fast, but we have to bang these bits pretty fast too. Reading the assembly language code for the Neopixel library really shows how careful the timing of this stuff needs to be.

However, if we can update a single strip by writing LOW and HIGH byte values to an 8 bit port register at this data rate, there is really no reason we cannot update 6 strips (or even 8 - one for each port bit) at the same time ithout breaking a sweat.. same number of bits to load, right? The extra overhead will be preparing the next port byte value, where we'll need to load data from 6 different memory addresses (one per strip) instead of just one - and might need an palette lookup for each one too.

Reading from this really useful blog post ( we do have up to 9us of idle time to play with between bits. This might make it all possible on an ATMEGA328 with some tight assembly language code, but you know what, maybe its time to look at something with a bit more grunt. Like an ARM board....

I've ordered an Arduino Due as a start. I may yet try to get it working on the Uno, but the comparatively huge amount of memory and much faster CPU speed of the Due does cure a few headaches. Just need to wait for it to arrive now - watch this space.....


Saturday, 10 May 2014

HammerPong #3: 7-Segment Display Made Out Of Fairground Lights

This is the third post in my diary of building my "Hammer Pong" game. 

After a visit with the kids to a local fun fair a couple of weeks ago, I thought some fairground-style lights would look good to jazz up the fascia of my game! I started looking on eBay for used ones, but eventually
decided to buy some new ones.

Loads of LED stuff :o)
At first I was thinking of using a row of individual lights to mark the score, but then I got this crazy idea of making a giant 2 digit, seven segment display!

First of all I needed some kind of board to attach the display to for a proof of concept. My neighbour was throwing out a big sheet of cardboard from a packing case, so I was happy to take if off his hands.

These lights use LED modules in place of filament bulbs, which give a nice clean white light behind the coloured plastic lenses. The LED modules run on 24V and are rated for 1.2W which means they only need 50mA current, which isn't too challenging to switch. 
Bits of a light
I decided to use 3 light units for each segment of my display, so for each segment I'd be switching 150mA at 24V. For this I went for TIP120 Darlington power transistors as I had a few of them lying about and I know them pretty well. 

I wanted to keep my options open for PWM fading and thought that if I used FETs I might need additional FET driver ICs to PWM switch the FETs. Anyway, a bit of experimenting on breadboard shows that a TIP120 could switch and PWM fade a set of 3 lights, wired in parallel, without breaking a sweat. For that test I connected the base of the TIP120 to a PWM pin of an Arduino Uno, via a 1k Ohm resistor. The TIP120 switches on the low side, so my lights were wired to the +24V line and their GND line was connected to the TIP120 collector, with the emitter connected to the GND of the 24V supply. Applying a voltage to the base makes the lights come on.

Now, I don't want to have to use an Arduino pin for every one of my display segments, so I decided to use a 74HC595 shift register to control the lights for the seven segment display. One nice feature of the 595 is the Output Enable pin. Usually I hard wire this to ground to keep the outputs enabled, but here I have it connected to a PWM pin on the Arduino. I thought this would let me fade the brightness of the entire 7 segment display and it seems to work superbly - just need to remember it is an active low signal, so analogWrite(0) is full on and analogWrite(255) is full off.

Each output of the 74HC595 is connected via a 1K resistor to a TIP120. Add a bit of code to load the shift register, define the numeric digits are we're ready to roll with a 7 segment display test!
Shift register/TIP120 driver board

The lights use a screw-on base which forces some sharp terminals through the insulation of the cabling. This makes it nice and quick to wire up without soldering. I used a common 24V supply rail and wired together the ground connections of the three lights on each segment, then connected to the appropriate TIP120 collector terminal. A quick Arduino sketch and I have digits counting, with a bit of a fade in and out around a change of digit.
Quick'n'dirty build

I think I made my digit a bit tall for it's width, but the visual effect seems to work. Now I just need to make sure I have enough space on the fascia of my game for 2 of these - they are quite big! I hope they aren't too big to read properly from a playing distance... hmmmm.... only one way to find out.
In action