Cross-platform development is a notoriously difficult task that can be tackled from a number of different directions. There’s a plethora of cross-platform frameworks available, but most tend to be bulky and difficult to use. Websites, on the other hand, are inherently cross-platform; web developers are more concerned with cross-browser support than cross-platform support.

What if we could avoid the cross-platform issue altogether by developing our applications on the web? Although this is a great idea in principle, it’s thwarted by the lack of MIDI support in most of today’s web browsers. MIDI is an old and established technical standard that allows electronic music devices, computers and related devices to communicate; without it, a website has very little hope of talking to any such musical devices.

The arrival of Web MIDI (sort of)

In early 2013, W3C, the main international standards organization for the internet, introduced the Web MIDI API ( However, this in itself is not enough: the API must be implemented in at least one browser before it can be used at all, and must be fully supported in most browsers before it can be deemed acceptable for public use. This is clearly a problem; to date, Chrome Canary, the bleeding-edge verion of Chrome, is the only browser that supports the Web MIDI API.

Soon after the arrival of the Web MIDI API, the folks over at Jazz Soft ( developed Jazz-plugin to provide Web MIDI support in most browsers. Jazz-plugin works extremely well and can be used to communicate reliably with MIDI devices. Our work wouldn’t have been possible without Jazz-plugin, so we’re very grateful for their efforts! However, asking a user to install a plugin before they visit your website is not a particularly attractive prospect. At this point, the future of our cross-platform, MIDI-enabled web application looked bleak.

Enter Chromium Embedded Framework

What if we could bundle our web application with Jazz-plugin, then distribute it to users as a download? The folks at Jazz Soft graciously provided Jazz-plugin under an open licence, so we knew that bundling the plugin would not pose any legal problems. After a little research, we came across Chromium Embedded Framework (CEF), an open-source, cross-platform project that provides web browser support across a range of languages. If CEF could be packaged with Jazz-plugin, then it might satisfy our requirements for a cross-platform, web-based, MIDI-enabled solution. Of course, the user would still be downloading a file, but it would be the entire bundled application rather than a 3rd party plugin.

CEF, although bulky and largely undocumented, proved to be exactly what we needed. However, we were still faced with a lot of unanswered questions. Might there be problems integrating Jazz-plugin with CEF? Would users expect functionality typical of a compiled application that is simply not available in a web browser? Are there security considerations? Will the web source files be exposed? Would CEF and Jazz-plugin work well on all operating systems?

Example application: Launch Control Editor

When designing the Launch Control (, we decided that users should be able to customize templates on their hardware. This needed an editor: something lightweight, simple, cross-platform and easy to use — an excellent candidate for CEF + Jazz-plugin! The application itself is relatively straightforward: the user can choose various properties for each of the hardware controls, and can also save/load templates. All communication between the device and the application is via SysEx messages.

Over the next few weeks we began to design and implement this functionality using CEF and Jazz-plugin. We used Eli Grey’s FileSaver.js ( to simplify the saving of templates to the file system, and abudaan’s JazzMIDIBridge ( to simplify MIDI device connections. Most of the functionality was developed and tested in a browser (Chrome), rather than through the CEF wrapper. Although this sped up the development cycle considerably, it did lead to one or two unexpected surprises.

Issues and pitfalls

The in-browser development cycle highlighted one major issue: that the behaviour of a web page depends on its environment (web developers are of course acutely aware of this fact!). On several occasions we developed and tested a feature in the browser, only to discover that the it behaved differently — or didn’t work at all — when wrapped in the CEF framework.

Under the Web MIDI API, connecting/disconnecting a MIDI device to the host computer does not trigger a connection/disconnection callback; instead, the system must be polled regularly to see if the number of connected MIDI devices has changed. Although this isn’t a show-stopper, it’s an annoyance that could present problems when connecting/disconnecting multiple devices quickly.

Another issue is security: the web files wrapped by CEF aren’t compiled into the application, which means the user can potential discover (and modify!) the files. The folks at Spotify were probably faced with the same problem as they use CEF, so I presume it’s fixable somehow. This also means the files have to be stored somewhere; this isn’t a problem on Mac OS X, but on Windows an installer is needed to place the files in a particular location. Again, this isn’t a show-stopper, but it’s at odds with the ‘easy to use’ design goal.

One of the most important issues we encountered was with Windows 8: Jazz-plugin was not being made aware when devices had been connected or disconnected, so the user must restart the application when a device is added/removed. Whether this is a problem with CEF, Jazz-plugin or the Web MIDI API, we’re not sure. Unfortunately we didn’t have the time to look into the issue further, but one day we may get back to it!

What’s next?

Combining CEF with Jazz-plugin provided a short-term solution to the longer-term problem of support for Web MIDI API in web browsers. When (if!) all browsers support the Web MIDI API, we’ll be able to migrate the Launch Control Editor (and any future similar products) to a purely web interface. If, on the other hand, the Web MIDI API is never supported in most browsers, this CEF + Jazz-plugin alternative provides a largely acceptable cross-platform approach for small-to-medium-sized applications.

The potential for Web MIDI is massive, and there are already a number of innovative applications available. Imagine web-based piano tutors, music games, synthesizers with built-in mappings for different MIDI devices, and firmware updaters. The last of these is particularly appealing; imagine a section of the Novation website that would detect what MIDI devices are connected, and then update the firmware on each device automagically!

MIDI is an established protocol that’s not going to disappear anytime soon. Support for MIDI in web browsers is sure to bring an exciting new wave of music apps on the web — something everyone can look forward to!


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.


Having recently tweeted my concerns about FogBugz in the face of Trello’s (very interesting) new Business Class feature, I was very pleasantly surprised to get a response from Michael Pryor pointing out that Fog Creek are hiring a FogBugz developer, and that the future was not “bleak” as I’d feared.

Happy Kiwi

This is great news – we love FogBugz at Focusrite and use it for everything from issue tracking to customer support via project management and documentation (not to mention Kiln) – but sometimes we find we need to do things that it just can’t help us with.  While I am now much more optimistic about the future of FogBugz, I wanted to make sure we could make use of the system in ways the core app does not support.

Ways in

There are several options which Fog Creek have helpfully provided – BugMonkey, Plugins, API and even source hacking! Much as I’d love to spend a few days making a plugin, I thought I’d see what could be achieved with the API and Google Docs in couple of hours, and I was pleasantly surprised.  With a very simple call to Google Spreadsheet’s importXML function, I could easily slurp in pretty much anything I wanted from our FogBugz install.  The key to this is:

=ImportXML(CONCATENATE("",B1,"&password=",B2); "/*")

This gives you a login token (given that cell B1 has your email address and B2 your password.  If this formula is in cell B3, you can then use this in an XML query, for example:


Given that cell A1 contains the name of a milestone field you’re interested in, for example sFixFor for the milestone name or sProject for the project name, this will give you a list of milestone names or projects.  Note that the XPath query used here is a problem – because it returns unstructured data where the milestone output contains dependency information – I need to modify it to return only “top level” milestones.

What now?

My next plan is to build a visual representation of milestones, and ultimately to add case/estimate breakdowns so I can see where we’re under-planned or over committed easily (though the EBS Schedules feature is interesting, reading the graphs is a fine art!).

The power of this solution is that I can easily share this information with my less technical colleagues who know Excel better than I do, and help them to integrate fine-grained information from FogBugz in their planning processes.  I hope they’ll like it!

The one thing that’s badly missing from the API is access to the holiday log – this prevents us from hooking our holiday booking system in, and means we have to maintain two calendars by hand.

Anyway, thanks Fog Creek, please keep making FogBugz better, we love it!

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.

Last year, as this blog testifies, we bought and assembled a 3D printer from a kit. In doing so, we unwittingly joined a revolution.

3D Printer

Affordable 3D printing is fairly new, and the possibilities are only just beginning to be explored. This makes it the darling of lifestyle magazines, chic periodicals, Kickstarter companies, and any journalist who is desperately looking for an emerging technology that can be described in short sentences, and which might just revolutionise the world. So much has already been said by others that there’s a risk of my vanishing into the background of noisy commentary, but for three reasons:

  • I lead part of a design department, populated by engineers. We understand technology, and the logistics and requirements of manufacturing, and we know how to communicate it.
  • We actually own a 3D printer, with the intention of using it seriously.
  • The printer was bought and constructed on the understanding that it would pay for itself.

Our printer complements more established methods of rapid prototyping. We sometimes hire external companies to build rapid prototypes for us in foam, plastic or metal using a number of more mature techniques: SLA, SLS, or CNC, as cost, size, and material considerations dictate.

How to print

Our printer builds up a physical object, one layer at a time, by extruding a filament through a heated tube. Each printed layer is a quarter of a millimetre thick, and cools and solidifies in time for the next layer to be added on top. This method is favoured because it is very inexpensive and requires no specialist chemicals or high-powered lasers. Prusa, the Makerbot Replicator, and the Bits from Bytes Rapman are all based on filament extrusion. The world is beginning to see its potential and its problems.

Spool holder

One of the printer’s first jobs was to service itself. It still has a sideline in printing its own spare parts. This detail is from a spool holder I designed, which helps to feed filament reliably into the machine. The two printed parts are white.

Filament extrusion seems straightforward, but is deceptively subtle, beset by the problems of a technology in its infancy. There is a choice of at least four pieces of software that can be used to convert a three-dimensional CAD model into a stack of two-dimensional lamina, and then to a set of instructions to control the printer. I know of Skeinforge, Slic3r, KISSlicer, and Axon. All have different strengths and weaknesses, can be hard to configure, and are inaccurate, unreliable and cumbersome in different ways. One has to master the peculiarities of the software, and it’s quite a skilled job. To coax the slicer into working well is a craft in itself.

None of the software will work satisfactorily without a substantial amount of human intervention. The work must be oriented appropriately so that it is maximally easy to print. A material must be chosen. The correct head speed, extrusion rate, temperature, and fill density must be arrived at by a mixture of prior knowledge, intuition, and trial and error. If necessary, the CAD model must be adjusted to make it easier to print.

When the work is running, we must know when the printer is about to jam and what to do when it does. We must develop a sense of the correct starting height of the print bed, and adjust it manually when it is crooked, too high, or too low. We must fine-tune the print head temperature for particular layers, and turn the cooling fan on or off as the room’s ambient temperature changes to allow layers to adhere without warping. Between prints, we must keep the printer in calibration and perform running repairs every few hours, and be constantly vigilant to the vagaries of the software, the material, and the printer.

Not only is the printing process challenging; it places restrictions on the object itself. One of the major drawbacks of filament extrusion is that the work is not self-supporting. In SLA and SLS prototyping, the top layer of material either floats in a bath of uncured resin or rests on a pillow of plastic dust. In filament extrusion, the head prints on top of the previous layer, or else on thin air. Holes or overhangs end up very messy unless the angle of slope is carefully designed. An unsupported hole of 15mm or less can be achieved without warping; a hole of about 30mm can be achieved with considerable mess on the upper face; any more than this and the piece becomes distorted and unusable. Our slicing software can automatically insert support material. Any excrescence can then be mounted atop its own little plastic pedestal, which is cut away manually at the end of the print. Currently, no software does this job very well: we add supporting posts to the design ourselves. Like the printing stage, it benefits from human intuition.

Red 1 RackTwo details from a Focusrite Red 1 500 prototype. The red panel is a SLA rapid prototype for which we paid good money; the clear white one is a PLA printout that we made ourselves. (The production material will, of course, be anodised aluminium.)

These are all things that will improve as the technology matures, and as domestic 3D printing turns into a proper industry. The push-button panacea is perhaps five years from our grasp. Until then, printing remains an art, and early adopters like us must live with its frustrations, find our own workarounds for them, and support the development of tomorrow’s technology.

What we have learned about material properties is difficult to impart engagingly, but was quite fun to glean from about sixty hours of printing. If you are about to embark on this journey yourself and are looking for hints on this site, there is not much we can offer you. There are so many user-, printer-, and material-dependent variables that proceeding by intuition is more likely to succeed than applying orthodox rules.

However, some hard-and-fast rules very quickly manifest themselves: particularly regarding the strengths and weaknesses of the two plastics. PLA is strong but brittle. It can blunt glasspaper. Its low temperature means that good-looking results are easy, but it starts to deform in response to fairly gentle warming. ABS is very strong, slightly flexible, and hence preferable for parts that undergo mechanical strain. It is easier than PLA to work with glasspaper or a scalpel, but far less easy to control during printing owing to its higher glass transition temperature. It also has a tendency to shrink slightly and warp during cooling. This is not a craft for people who expect results hurriedly, or at the first attempt.

In search of an application

There is something delightful and compelling about this kind of additive 3D printing, and there is a very strong temptation to print objects just for the sake of it. This is a very young technology, promising a future of low-cost object printing, and it is attempting to supplant established methods of rapid prototyping. However, it is still uncertain what the domestic applications might be. This is exactly where the home computer industry was in the early 1980s, before anybody had even coined the term killer app, let alone sought one.

In industrial use, we are beginning see the benefit of having our own rapid prototyping machine. Once the software becomes more mature, it will be reliable and controllable enough to usurp some traditional prototyping methods in certain applications. It is already very good at allowing us to experiment with control surface layouts, to test the mechanical fit of assemblies, to catch silly mistakes, and to do everything we’d expect from an Issue 1 prototype. It even has its uses enhancing our office furniture with custom-made fittings. However, it isn’t versatile or precise enough for more advanced use.

What’s the killer app for domestic printing? If the pages of Thingiverse provide any clues, 3D printing will start by putting Games Workshop out of business, and will then breed a generation of mechanical engineers who have taught themselves by designing, printing and assembling linkages and gears. That would be great: if somebody writes a program that enables us to start printing open-source Meccano, you won’t see me for months.

There are a few special cases where this technology fits perfectly: items that are very hard to manufacture in any other way; low-batch manufacturing; local factories offering highly-customised variants of standard designs; medical and dental prosthetics, where every part must be custom-made. Outside such niches, though, the argument for 3D printing as a manufacturing process is less compelling. It uses more energy and more material than injection moulding, and cannot approach more established methods for precision, economy, and repeatability. The other problem is even more obvious. Say I’ve downloaded and built an enclosure; it’s probably taken me eight hours to get a good printout of this specialised container. Now, what am I going to put inside it? For example, one cannot print circuit boards on a domestic printer, or white goods, or furniture, or cooking vessels. The material possibilities are, and will remain, very limited.

It is not my intention to finish this article by rubbishing this technology, but the hype that surrounds it is currently greater than it deserves, and this is worthy of recognition. I’d like to conclude with an idea that I’ve ventured in private, and would like to test here. The ‘making revolution’ has garnered so much attention because it is just one small part of a wider revolution. We human beings have an atavistic yearning to sculpt and control our environment. Our survival once depended upon our individual ability to grow food, to build shelter, and to construct and use tools. When these needs are met by mass-produced commodities, the link between us and the people that conceive and build our things cannot stretch across the geographies that divide us. It is not a connection that we can comfortably maintain, but it is not one we can bear to lose either.

We are not automata and, although business is global, we are not global individuals. We still live and die much as we did a million years ago: in little social groups, with our own interests, beliefs, and desires. The response to divesting control, and losing our parochial craft and culture (of which design is just one facet) to greater economies of scale, is to make anew. The objects that we make must suit our requirements; they must reflect our passions and prejudices; they must be just right for us. A 3D printer, or a soldering iron, allows us to be expressive in a manner that is more familiar to many of us than brick, paint or clay. The maker and hacker movements are exemplified just as clearly by stencil graffiti and urban allotments as they are by our RepRap printer. So, perhaps the more faceless and undistinguishble our environment becomes from all the others, the deeper our need to imprint it with something of our own. Something that is uniquely inspired, uniquely enriching, and uniquely ours.

Many thanks to everybody who read and commented on last week’s article. Our posting was picked up by The Register and then by Slashdot. In two days, we hosted more than five thousand readers: more footfall than we usually experience in a year.

In the article, I set out to look at what we have learned about radio interference problems and best practice as a result of legislation. Engineers find this an engaging subject, because it has transformed the way that we see the world and how we approach our work. EN55022, on which I focused, is just one of many new regulations that are increasingly affecting our trade. The ZX Spectrum neatly illustrates that we have made genuine progress, and it does so in a refreshing way.

Those who enjoy modifying and continuing the legacy of the computer (and there are many such people) may be a little let down that I didn’t do more. However, I couldn’t please everybody in the space of a blog posting, and I didn’t attempt to. What follows is a consolidation of much of the feedback we received.

EMC isn’t important

It is clear that there are two, and perhaps three, camps in the general argument about electromagnetic compatibility [EMC]. A few correspondents sincerely believe that none of it matters and, in a limited context, they’re right. In the domestic situation, you’re unlikely to encounter a compatibility problem that endangers your life or livelihood. For a lot of people, the fact that home computers would knock out radios, televisions, or toys in the vicinity just blends into part of the nostalgia.


Collision course: the Tandy TRS-80 and MB Games Bigtrak wouldn’t share a room together (thanks to Animats on the Slashdot board for the example)

The other camp, in which I include myself, will contend that good EMC practice is of prime importance. Although I concede that the test limits are arbitrary, we have a duty to invest serious effort in designing equipment that people can use in any way they like, without it disrupting their work or leisure.

That same argument can be extended to rules like RoHS, however clumsily it was introduced, and further into educating engineers about conflict minerals, and particularly tantalum. These things force us to confront the fact that we all shape the world, and the products we design have consequences beyond our influence.

It’s not just about our consciences; it’s good business. What might have been novel and forgivable in the 1980s, when all electronic equipment tended to be a little shambolic and every user was a pioneer, is not so endearing in younger products. Customers today are more sophisticated and less forgiving about environmental and ethical issues, factory conditions, technical problems, even delays in shipping, and we have to be at least as sophisticated as they are.

There is a third camp, whose argument, succinctly, is that a few cowboys spoil everbody else’s fun. Telecommunications products, for example, still run roughshod over EMC regulations because certain products, that transmit radio as an essential part of their function, are exempt from large parts of EN55022. Today, when I plug my cordless phone into the wall, it knocks out the radio on the other side of the room. It’s the switch mode power supply that does this, because the system is exempt and it costs a few cents to buy components that quell the energy it’s emitting.

These issues remind us of the bad old days, but we should set our own sights higher. Let us imagine if every competitive advantage was justified, irrespective of the means, just because nobody had legislated otherwise. We would all be designing dreadful equipment, avoiding our taxes, destroying the world around us, and cynically manipulating and reinterpreting the rules to suit ourselves. Some people do this, but most people don’t, which is why we have lasted this long as a species.

It’s a moot point these days, though: if we don’t meet EMC requirements, we don’t have a product we can sell.

The Metal Box Scenario

screeningScreening: a large example of a screening can; a heat sink on the Issue 6a Spectrum that might have been a shield but wasn’t; a sprayed can in a spray can.

Many correspondents pointed to the Faraday Cage. Simply make the case out of cast metal, or coat the inside with a special paint, contrive a method whereby this can be earthed, and radio signals can no longer enter or leave. You suddenly have a compliant product. Simple, right?

It depends. If you’re retrofitting one computer, or you’re making a few dozen of a new product, it is indeed simple: you control the process, you dictate the quality of the result, and you are selling your products or services at enough of a profit that the cost of a can or two of conductive spray paint presents no difficulty. You may still have problems with your cables radiating, though.

If you’re contracting your manufacturing and knocking out tens of thousands of products, though, there are big problems with this kind of technique. Use conductive plastics or cast metal and you change the finish of your product, you accelerate the wear on your tools, and you raise material costs. Use a spray coating, and you must accept that a good proportion of your plastics will be rejected because the paint finish is unacceptable in one way or another. You create a new quality control step, and a new manufacturing process where your equipment must be coated and dried, which impacts on the production line. Aside from having to pay for the extra labour, suddenly you have to store case materials very carefully on massive racks of shelving for several hours while they dry. You’re paying for this time, this floor space, and this temporary storage.

That’s why we accept plastic cases in mass production, and design our products so that the enclosure doesn’t matter. Faraday cages still have their place in modern electronics: if you look inside a mobile phone, you’ll see them soldered to the printed circuit board to protect or defend against selected devices. We can’t enclose everything we make in metal cases, or it would price us out of certain markets entirely, so we find other ways to make our products comply.

Plus ça change

When is a Spectrum not a Spectrum? My attention has been directed towards a number of novel retrofits and research products. Some of these are worth a look:

As many correspondents point out, we can make an impact on radiated emissions if we tinker around the edges. The failure I described as ‘abject’ may be ameliorated with a few simple modifications. Perhaps it would then pass; perhaps it wouldn’t. I would have liked to try these, but unfortunately didn’t have the time.

If we allowed ourselves a more drastic redesign, we’d have a device that behaves like a Spectrum, but when would it cease to be one? If we change the RAM, so it no longer requires those extra power supplies, and then we disable them, is it still a Spectrum? If we change the 7805 regulator for something that doesn’t throw away about 60% of the input power, then remove the heat sink, is it still a Spectrum? Do these conservation projects really preserve the Sinclair legacy?

An old computer is what it is: a product of the market, engineers, and achievements that produced it. These days, a good engineer could create a passable version of this computer using off-the-shelf components and software in a couple of weeks. It’s easy to redesign in hindsight, when technology has moved on and improvements are cheap and even obvious — that’s another article. But in 1982, making a Spectrum was a different order of challenge.

There were five major modifications of the ZX Spectrum’s electronics during its production for reasons of cost, yield, and quality, and by the end they had a much better product. Most of the area on a ZX Spectrum motherboard was taken up by RAM and the electronics required to access it: something you could now do in two or three square centimetres of board space. In 1982, you couldn’t make a computer with a four-layer board economically. Today it is a trivially simple process.


The abysmal video output and the lack of memory of my current Spectrum drives me a little crazy. I’ve also forgotten how slow the BASIC is, which must be why I decided, at the age of ten, to teach myself assembly language.

While it’s tempting to take this and all my correspondence on board, be influenced by latter-day add-ons such as divIDE, and produce another almost-Spectrum in the manner intimated by my previous post and the links above, that would involve an awful lot of time that I don’t currently have. It’s expensive to make the first one properly, and I’m not certain there’ll be a market for others.

So, what am I going to do with my Issue 2 Spectrum? The next thing I intend to do is to take another look in the EMC chamber to see if the simple modifications I suggested in the last article will make it pass, as there’s a relatively low risk of messing up my computer if I stick to some fairly basic changes. I’ll get back to you in March, when the snow has melted and we’ve booked a little more time in the chamber.

For the next few postings, though, forgive me if I steer the subject back to Focusrite.

Photo credits:TRS-80 / Bigtrak / P&O container (the article is great) / Issue 6a Spectrum / Nickel spray.