As I mentioned last time, three of us from the Focusrite/Novation engineering team attended the Music Hackday event alongside the amazing Sonar festival in Barcelona.  We learned lots, slept very little, and had a great time – here’s a quick summary!

2013-06-14 16.33.16

Web APIs > everything else

It seems most of the hackday crowd are very web oriented, and we’d failed to make it easy for them to see how to use a MIDI controller (MIDI? What’s that?  Is there a Node.js wrapper for it?  …well, actually, yes, in fact there are two!) in their projects.  Nonetheless, several of them did a great job.

We did point people towards the Web MIDI API and the essential Jazz Plugin, which was included in a particularly interesting hack – we’ll be exploring this further in the coming months.

Going mental

For our own hack, we decided to aim high and use the incredible Enobio EEG sensor from Starlabs.  The team were very helpful getting us up and running with their OS X SDK, despite having so much else to do and having presented the Windows version!

We wanted to exploit the phenomenon known as Steady State Visually Evoked Potentials, or SSVEP.  Broadly this means that if someone looks at a visual stimulus flashing at a rate between 3.5Hz and 75Hz, you can observe EEG activity at that frequency, with harmonics.  We instantly thought of synthesizers and decided we’d build something that could sonify the EEG trace to play musical notes – effectively using Ross’s brain as an oscillator clocked by a flashing Launchpad.

Science is hard

After an hour or so with the sensor and some hacked Launchpad firmware generating outrageously nauseating flash patterns, we’d captured a number of test traces from Ross’s brain, but had seen little in the way of harmonic content in the spectrum analyser.  I blame Ross’s brain.

2013-06-13 14.41.48

At this point, we should probably have given up and decided to make something different, but instead we thought we’d give the EEG trace a helping hand and filter for the frequencies we were expecting.  Combining this with a heart rate sensor to modulate the level, and pitch-shifting the output by an octave or two, we thought we’d be able to get something that was, while not truly “mind music”, at least in some way meaningfully related to brain activity.

DSP is hard

Ben set up an Audio Unit plugin and started integrating the Enobio SDK, discovering just how much fun* it is to add a dylib with dependencies to a component in a way that won’t bomb out at runtime.

Ross was having much more success modifying the Launchpad to do variable rate flashing, PWM for intensity and colour patterns.  He spent time helping out some of the other hackers and got some great results (see later on).

At this point I lost the plot and charged off into DSP territory.  Unfortunately I’d forgotten just how bad I am at DSP, and spent a long time troubleshooting the various buzzing, popping and aliasing introduced by my code.  By 2am, we had something that made a noise in response to the heart-rate sample data, and decided to call it a day.

*really not much fun at all.

This brain has left the station

The next morning we felt like a result was just within reach – we’d use the heart rate sensor to modulate the processed (but horribly aliased) output from the EEG, in response to visual stimulus triggered from the Launchpad buttons.  It might just work…

…but it didn’t.  With an hour to go, we had nothing that made anything approaching a useful sound, we were struggling to normalise or beat-detect from the heart rate sensor, and had only one usable development machine after the ongoing runtime dependency nightmares had wasted hours.

We decided not to demo our hack (especially as it would mean monopolising one of the precious few Enobio sensors), and spent the remaining time helping our fellow hackers include Launchpads in their work, which was a lot of fun.

2013-06-16 01.47.19

In hindsight, we’d have been much better off attacking the problem using something like Pure Data to get going quickly, wasting less time on dependencies, sample rate conversion and C++.  I sincerely doubt I’ll be writing any DSP code in the near future either.

Hacks and demos

The hacks from the event are published here on Hacker League.  Our favourite Launchpad hacks were:

…and some others that really made us smile:

We really enjoyed the event, meeting lots of inspiring people and learning about cutting-edge technologies.  We’ll be back, and next time we’ll demo!


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.


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!

This is the first year for ages that I’ve not been to Musikmesse.  I thought about it long and hard – I enjoy the show, and it’s always fun to see what everyone is excited about, to meet people at the booth, and of course to indulge in beer and sausages in the Frankfurt sunshine while seventeen different guitarists and DJs try to outdo each other!

However, try as I might I just couldn’t justify the expense – the odd, unexpected meetings with engineers from interesting companies have always been good, but this seems to be less and less of a feature of the show (I guess they thought the same as me).  I can check out all the products and announcements in pretty much real time anyway, and all the real collaboration gets done remotely.

I tried to see if there could be any useful recruitment opportunities, but again there’s virtually nothing except a small jobs board in German.

I can’t help feeling like we’ve missed out.  I’d love to go to a proper engineering conference, rather than a trade show, with more to offer (technical seminars, workshops etc.).  Something like the Game Developers Conference, which I loved attending in a past life, where us geeks can get together and do our thing without embarrassing semi-naked women trying to sell us DJ bags!
Does anything like this exist, even on a small scale, or is our industry just too small and cagey to support such a thing?