Firmware development

I’m thrilled to announce that a couple of us from the Novation engineering team are coming to Music Hackday Barcelona at Sónar+D!  We’re bringing along some Launchpad S hardware to hack, and we’ll be on hand to help get the most out of the hardware and software, as well as participating in the event ourselves.

This post will serve as a place for us to share some of the content that we’ll bring on the day, but of course it’s not just for Music Hackday participants.

Two Ways to Play

The Launchpad Programmers Reference documents the MIDI messages you can send to the Launchpad to set the LEDs, and the messages that Launchpad will send you.  This allows you to do almost anything with a Launchpad, given source-level access to the software you want to control (or if you’re willing to write an intermediate translation service app).  But sometimes, you might want something a little more immediate!

To do that, what you really need to to is get inside the Launchpad…

Open(ish) Firmware

Yes, that’s right – you can now modify the firmware of your Launchpad S!  To do so, you will need several things:

  • Raisonance Ride7 development environment and RKit-ARM (Windows only)
  • The source code (we’ve exposed the fun parts so you can get straight to the action)
  • The libraries (some bits of Launchpad S are not that interesting, so we’ve packaged them up)
  • A MIDI sysex uploader (try MIDI-OX on Windows or Sysex Librarian on OS X)
  • Some guts!  The bootloader is protected so you’d have to try really really hard to brick one, but I’m sure it’s possible.
  • Optional – an RLink hardware debugger.  We’ll have a couple on hand at Music Hackday Barcelona, they can be really helpful if you’ve got nothing else to help you debug!

We’ve put the firmware on GitHub so you can make use of it.  We decided to release it under the 3-clause BSD license, which is very permissive – mainly because the code is not useful for anything other than a Launchpad S!

Those of you around on the day will be able to ask us questions, but until then we’ll try to document at least partly – we expect the documentation to improve based on your feedback.  It can’t get any worse, as at the moment, this is it:


Ummmm…. this page.  Yup, that’s it.  We’ll be adding documentation to the source code as it matures, so expect to find some useful comments and example code, particularly in sonar.c where we’ll include commented code for some of the key features.

Building the Firmware

Double clicking on build.bat in the root of the project should spit out a .syx file that you can upload to your Launchpad S.  The process is as follows:

  1. Disconnect the Launchpad S
  2. Hold down the “session”, “user 1”, “user 2” and “mixer” buttons
  3. Connect the hardware while holding them down – the device should enter the bootloader screen
  4. Send your .syx file to the device using a MIDI sysex utlilty (the device will scroll “Updating …” across the LEDs)
  5. When the pads return to the bootloader screen, press the bottom right green pad to exit to the main firmware

Note that if you modify the .rprj file, you must ensure you leave the “Standard Configuration” selected, as otherwise your build won’t work without the RLink debugger connected.


Four years ago, I was involved with the design of the original Launchpad. Conceived as a clip launcher for Ableton, we quickly realised that it had many other uses, so we prepared a MIDI reference manual so that programmers and hackers could control it easily.

It was abundantly clear from the start that people would like Launchpad. Its success as a product came from two sources: the power that it imparted to Ableton, and the community of programmers who, eager for an affordable tool like this, quickly put together a plethora of third-party products: sequencers, music warpers, and even emulators for other controllers.

More than three years have passed since we sold our first Launchpad, and it feels good to revisit it. It’s not very often an engineer gets the chance to reappraise an old project. Even less often does one get the chance to do so with an excellent assistant, Ross. He’s done most of the hardware design and implementation work this time around.

A short while ago we manufactured our last Launchpad. From now on, we are making Launchpad S. Compared with the other controllers that have emerged in the meantime, it is fundamentally a straightforward device, but this simplicity is part of its strength.

We set out to maintain 100% compatibility with the original Launchpad, so that Launchpad S would continue to work seamlessly with existing programs. We’ve actually added very few new features, for reasons that will become clear. But from an engineering perspective, it is a substantial redesign, and the briefing was better in every way. There’s much more to S than a superficial makeover.


If I have one regret about Launchpad, it’s our choice of microcontroller – the part that interfaces with the computer and provides all of the device’s functionality. We used exactly the same chip that we employed in Nocturn: a ST7 microcontroller. This enabled us to work very quickly, and to improve our buying power to make the device more economical.

One of the biggest frustrations with this microcontroller is its communication speed. Because the processor is based around a fairly old eight-bit core, we were confined to a low-speed variant of USB 1.1 that limited us to 400 MIDI messages per second. Even when we are clever about it (Ed – kernel mode MIDI drivers are a scary place to be “clever” – getting maximum throughput in the WIndows driver was extremely difficult – davehodder), it takes at least 100ms to update the status of all 80 LEDs on Launchpad. This complicated the effective control of Launchpad beyond the Ableton environment, and stopped us from using class-compliant MIDI, but these were seen as acceptable compromises.

Our sleight of hand was to employ double-buffering – a trick borrowed from certain home computers of the 1980s. This enables a programmer to set up every LED in advance and to switch them all instantly with a single command. Our compromise makes life more complicated for the software designer, but it permits flicker-free fast updating. We put in a mode so that this feature could be used to flash LEDs too. A lot of programmers ended up making very creative use of double buffering, and started to do other things that we didn’t anticipate.

Faster communication.  Given the opportunity for a rethink, the first thing we changed was the microcontroller. Times have moved on since 2009, and it’s possible to upgrade from the old 8-bit device to a shiny 32-bit ARM core. Thanks to a price war between semiconductor manufacturers, this costs only a few cents more than the old solution. Extra speed carries many advantages. The new Launchpad’s USB can handle MIDI at around forty times the speed of the old one, rendering double buffering unnecessary, but we’ve left it in for backwards compatibility.

Class-compliant MIDI.  Faster USB not only allows Launchpad S to be updated directly at a civilised speed; it also allows us to make it class compliant. So the new Launchpad doesn’t require a third-party driver (except for multi-client operation under Windows, but that’s a Microsoft thing). As well as being great news for Linux and iOS developers, class compliance also allows us to improve our MIDI parsing. So Launchpad S deals gracefully with badly-formatted MIDI, and will respond to System Exclusive device inquiry messages that the old Launchpad didn’t have the capacity to support.

Upgrades.  The firmware in the original Launchpad was not upgradeable, but we actually turned this to our advantage. It was a great motivator for keeping the product simple and spurning featuritis, as well as being a spur to get it right first time. Launchpad S is based on technology that we’ve deployed in many other products, and it allows us to respond to demand for product enhancements without stranding our existing users.

A great advantage of being able to change the program space is that we can now add a configuration page. This allows a number of new features. One of the most important is that a user with more than one Launchpad S can now label them to give them different IDs, so that they can enumerate differently and software can determine which is which.


Moore’s Law has a counterpart, Haitz’s Law, in the LED world. The LEDs we put into the original Launchpad, that led the industry in 2008, look rather dim in 2013. One of our goals was to obtain visibility in full sunlight using bus power, and now it’s just about possible to see what the Launchpad is doing when it’s operating in full sunlight. We have achieved this in two ways: by sourcing LEDs that are the brightest available, and by finding smarter ways to squeeze as much light from them as we can.

One thing we didn’t do is add a blue LED element. We ran experiments using them, but there are still a couple of problems. The first is that we can’t quite get the device bright enough for our satisfaction using bus power alone. The annals of engineering are littered with the corpses of products released before their core technology was ready. The time is not yet right for a bus-powered device with eighty LEDs, but give it a year or so and Haitz’s Law will help us out.

The second problem is that we’d need to update the MIDI protocol that Launchpad uses to talk to the outside world. That would turn it into a different product, and would break backwards compatibility with certain software that remaps MIDI traffic to deal with Launchpad.

Colour separation.  Brightness was not our only priority. We’ve been listening to our customers, and one of the more interesting feature requests we have received is to improve the device for colour-blind users. Certain people find it particularly difficult to distinguish between the amber and green states of Launchpad. In Launchpad S, we deliberately selected LEDs with a colour spectrum that spaces the red and the green wavelengths much further apart. The green element is an emerald green, closer to the colour of a traffic light, and the wavelength of the new red element is just a few nanometres higher. Amber is balanced so it looks about the same as it does on the existing Launchpad.

If you do confuse reds and greens, Launchpad S will be a substantial improvement. And if you’re not colour blind, there are now more distinct colours within the colour space that Launchpad offers, whereas before you would have had to be content with three.

Launchpad S vs Launchpad, Full-power mode

Photographs cannot do adequate justice to light emitting devices, but this will give an idea. A Launchpad S battling against a Launchpad under office lighting, both showing the 16 available colours.

Welcoming careful drivers.  It wasn’t sufficient just to find brighter LEDs: we decided to find a more responsible way of putting current through them. The original Launchpad drove its LEDs directly from the 5V USB supply, and LED current was obtained by tempering this voltage with resistors. As we have only 500mA to use, this meant that about 40% of the power we had at our disposal was converted to heat without ever encountering the LEDs. The new scheme uses a switch-mode regulator to divide the input voltage down to 3.6V. Some of our LEDs are driven directly from this, which saves fitting a few resistors, and makes the system about as efficient as it can be: more like 80%. Although the extra regulator costs a little more, we can use fewer components so the cost implications are not severe. The extra efficiency also gives us more current to push through our new LEDs.

Faster multiplexing.  Launchpad multiplexes LEDs. This is a technique that makes more efficient use of our circuitry by turning different LEDs on at different times. No more than a quarter of the original Launchpad is illuminated at any instant and, because it takes time to set up the next set of columns, no LED is on for more than about 18% of the time. The use of a switching regulator gives us more of a power budget to spend on driving LEDs, so Launchpad S is multiplexed one third at a time via a faster processor. Now each LED is on for about 29% of the time (the faster processor helping to reduce the overhead), allowing them to be quite a lot brighter.

Banishing flicker.  We can configure certain LEDs to be lit dimly. When an LED is set to ‘dim’ on Launchpad, it lights for only one multiplexing pass in every five. This was about as small a duty cycle as we could achieve before we could see the device flickering. Unfortunately, video cameras work faster than the human eye. This accounts for the flickering you can see when the LEDs are set to their ‘dim’ mode while the Launchpad is being filmed. One of my pet annoyances with the original device is that it seldom accounts well for itself in Youtube videos.

Launchpad S is so much faster, we changed the way that we do multiplexing completely. We also changed the way that LEDs are dimmed so that we have 64 steps of dimming rather than Launchpad’s five, giving us improved control over contrast and colour balance. The round-trip frequency, at which the dimmest LEDs flicker, has also been increased from 56Hz to 400Hz. This is somewhat faster than a video camera, so dim LEDs no longer flicker when they’re filmed.

To show you this, we used a bit of magic firmware to slow the old and new Launchpads down to 0.25% of their proper speed (so half a minute of the video corresponds to about 1/14 of a second at full speed). The video below shows both Launchpads displaying the same LED pattern as the still photographs on this page. It shows quite clearly that two very different techniques are used, at very different speeds. This is why the dim settings on Launchpad flickered on some video cameras, while the ones on Launchpad S just won’t. Apologies for the video quality, but it proves the point!

More productive!

iPad compatibility.  The LEDs are sufficiently bright to enable us to provide a special low-power mode for Launchpad S. This uses a maximum of 80mA instead of 450mA, which allows the device to be powered from an iPad. Surprisingly, it’s actually a little brighter than the original Launchpad, while using less than 20% of its power.

Launchpad S vs Launchpad, Low-power mode

Launchpad S in low-power mode. The one on the left consumes less than 20% of the power of its older brother on the right.

Reapportioning cost.  We have been able to reclaim quite a lot of the expense of using a newer processor and higher-spec LEDs by thinking harder about the way that the printed circuit board is laid out. Launchpad’s circuit board has four layers in total: two layers of printed circuitry are buried internally. The new one uses a few tricks that we’ve devised in the meantime, and we’ve safely reduced it to two layers. This simplifies the manufacturing process and saves quite a lot of cost, so that we now provide a much-improved Launchpad for the same retail price as the original one. We have even rethought the packaging, slimming down the gift box considerably, so the units are smaller, lighter, and easier and cheaper to transport.

You’ll also notice that we’ve removed the silk screen legends from the buttons: they’re all blank now. This reflects the fact that Launchpad’s uses became far more expansive than we had anticipated, and transcended both Ableton and Automap.

For the same cost as Launchpad, you can now get hold of Launchpad S: a better-engineered product that takes advantage of four years of hard thinking and technological advancement. We hope you like what we’ve done.

Focusrite are hiring!

in case you didn’t know, Focusrite are hiring.  In fact, we’re almost always hiring, and even if we’re not hiring, we’re probably still open to hiring.  I’ve seen a lot of CVs in the past few years, so I thought I’d offer some tips to help you present yourself in the best light.

That might seem a little odd, but I remember what it was like writing my CV (actually, only dimly as it was about ten years ago!), and having spent some time at the other end of the wire I thought it might help to improve the quality of applications we receive.  The last thing I’d want is for us to miss a great candidate.

Before I get started, please excuse me if the tone is patronising – the best applicants teach us things we don’t know, and the interview process is very much two way – but having seen too many terrible CVs, I can’t help but sound off once in a while.

CVs and covering letters

I do not care about your “Career Purpose” – you really shouldn’t have to state that you aim to be the best at what you do, or to make a difference, or that you’re a great communicator – that should shine through!

I really need to see your other jobs, particularly your achievements there.  I’m much less concerned with keywords (languages, technologies and so on) except where specifically required for the role.  I am also interested in some of the non-technical work you’ve done, so leave some of it in unless it’s ancient history.

I do care about your degree or further education, but probably not as much as you think.  In particular, I don’t necessarily mind if you didn’t go to university, or if you did a non technical subject.  I’m interested in your thesis, final project etc. but not as much as…

…your hobby projects.  We love these!  Above all else, this is the single most important thing you can do to get our interest.  I came back from holiday to find an odd looking box of electronics on my desk, and I was thrilled – I thought I had been sent an electronic CV – but it was just some junk from our WEEE waste that someone thought we could make use of on one of our company hackdays.  Please, please send us your electronic / software / mechanical hobby projects, however crazy or half baked.  If you’ve got the passion to create things in your spare time, we’d love to see what you can do in a full time job!

I also care about your early education (GCSE, A-Level results, subject choices etc.).  I will not reject a CV based on bad early grades, but seeing a dramatic change of tack / results / subjects is interesting background information that offers insight into who you are.

I do not care about your bronze swimming badge from 1984 (from a genuine CV, really)!

Good spelling and grammar are absolutely vital – if English isn’t your first language, or if you’re dyslexic, ask a friend to review your work.  We’re not grammar freaks, but attention to detail is an essential skill, as is clear writing.

I like covering letters that show you know who we are and are interested in what we do.

I dislike templates, especially if you leave “please insert content here” in the body (again, from a real CV!)

The phone screen

So, you’ve sent us a well written, spam free CV, a coupon for your iOS app and a covering letter describing your home studio, the gear you use, what you love and what you’d improve.  At this point I will be really excited, so I’ll remind myself to calm down and give you a call to check three basic things:

  1. You want the job we’re actually offering.
  2. You are available for work, now or soon.
  3. You have realistic pay expectations.

You’d be amazed at how many people fail at one or all of these three steps – it’s very depressing when an interesting candidate says “well, I’m going to finish my studies next year and then take a year out travelling… is there a part time position in Marketing available for £50k?” – ummm… no, there isn’t.

The technical interview

Assuming that goes well, we have a shared understanding of the role, so it’s time to start the fun part – the technical interviews.  This is where we get to talk about (and actually do) all the interesting stuff we work on all day long.  You also get to interview us, to make sure you like the way we work, that we’re competent, that we can give you the support and freedom you need to deliver your best work.

We like to start this process over Skype, as it’s so much quicker and easier for both parties.  We’ll do some simple starter questions, some code / design review, some more general discussion about products and processes, and we’ll hopefully go off on some interesting tangents about the innermost details of something you’ve been working on.  If we get on, we’ll ask you to visit us at Focusrite HQ for the final stage, where you’ll do some more detailed interviewing, have lunch in our canteen and meet the rest of the team.

I look forward to seeing you soon!

To develop the Impulse firmware, we first wrote a software simulation of the hardware in Cocoa.  Using this, we could rapidly redesign the UI and test out the button layout, and we could also write almost all of the device’s application level firmware before the hardware was even built.

Simluating hardware has a number of advantages

We could turn around design changes very rapidly and distribute the simulator to the team, long before there was a firmware update process for the hardware.

On top of this, we had the full benefit of the Xcode tool chain (static analyser, unit test harness, debugger etc.) applied to the embedded firmware, which helped enormously to improve the quality and stability of the device.

Once the hardware arrived, we would regression test any bugs found against the simulator – this helped to pin down hardware / low level firmware issues quickly, for example if the bug did not appear in the simulator.

This was all very useful, and we are already using this technique for new products – this time on iPads and iPhones for a more accurate user experience  (one problem with the Impulse simulator was button combinations – we had to make the “shift” button sticky, which made it confusing to operate).

What should we do with the simulators once the hardware has been released?  We still use them for debugging and testing, and I put a simple synth into the Impulse simulator one hackday… but could they become products in their own right?

What else could we do to make simulators more powerful?