Putting together a new standard

The topic I jettisoned from my talk about MPE at last week’s conference was my thoughts about what makes a good Working Group, as I didn’t want to imply any criticism of the MIDI Manufacturers Association or its members.

As Chair of the MPE Working Group, I neither presume that I can pilot harder projects through technical and diplomatic adversity, nor will I tempt fate by attributing much talent to what might just be beginner’s luck. All I know is that, over the years, I have seen a couple of things.

Some time in the past, I sounded off about what is wrong with MIDI, and every now and then I still do, but always with a veneration for a standard that has managed to age so gracefully while seeing off so many rivals.

The HD Working Group has been meeting at least weekly for more than a decade now to define a successor to MIDI, and we’ve all been waiting, reading, and preparing. It’s not been an easy journey, and HD has recently stumbled at one of the last hurdles. The MIDI Manufacturers Association functions as a democracy of individual companies, and getting a new idea ratified means convincing important stakeholders that they will benefit from your changes and not be threatened by them.

This has always worked for small changes. But a wholesale replacement for MIDI must be non-disruptive, and a non-disruptive replacement is a paradox. After ten years of development, the HD spec is more complex and intimidating than MIDI, there’s no straightforward compatibility between the two, and it’s too new even to be clear how it’ll be used. MIDI has survived nearly 35 years being meddled with and patched up — MPE is just the latest way of doing this.

The HD spec would fix a lot of our problems automatically and for good, but it’s in a tricky place. Every passing year, the tweaks to the old spec gain some ground on the new, and the case for the new diminishes.

Either in its current or a modified form, I want HD to thrive. It seems that there are a few options open to the Working Group to keep it alive, all of which might work, in varying shades of palatability. Some of these are happening, and some aren’t:

  • Keep working on the market model, convincing the company representatives who intend to vote ‘no’ that it’s in their interests to vote ‘yes’.
  • Allow companies to start commercialising the draft specification without permission, on the basis that the first few compatible products will create a small ecosystem, prove a market for HD devices, and establish a commercial case without frightening incumbents.
  • Encourage software framework developers to add implementations of HD to make it easier for third parties to assimilate.
  • Approach a different standards body, such as the USB Implementers Forum or the ISO, to ratify the specification as a standard that is independent of MIDI, and bring it back to the MMA as a fait accompli. This might be less hard, but risks destroying the MMA by driving it into irrelevance (or making it look like this is the intention). Doing so could alienate much of the industry.
  • Go back to the drawing board, and work out a roadmap where MIDI 1.0 can be turned into MIDI 2.0 by backwards-compatible steps, each of which will require a little work in exchange for some exploitable advantages. For example, MIDI 1.1 could mandate full-speed USB, assume bidirectionality by default, revise its note model to support MPE, respond to the System Exclusive Device Inquiry message, and abandon Polyphonic Aftertouch (the messages for which might then be reappropriated at some point in the future). All of these have clear commercial value, ease communication with computers, and pave the way for a ten-year plan of improvement. The new spec gets chucked away, but not the underlying vision, which is actually the important part. Who, after all, knows what the market will need by the time MIDI 2.0 sees the light of day?

The last one would, of course, be terrible. HD isn’t at this stage and I hope it doesn’t reach it. For what it’s worth, though, here is my conclusion from what little I’ve seen of Working Groups.

Creating a new specification is just like software design …

  1. Have a short attention span, because you never know which way the industry will turn tomorrow.
  2. Surgically fulfil specific, identifiable needs.
  3. Always have an up-to-date implementation so that the spec makes sense.
  4. Engineers have enough to learn. Resist the temptation to change established practices. Even if it hurts a bit, make the old spec fit new requirements.
  5. Put something out within a year, or two things will happen: the world will forget you, and the sunk cost fallacy will sink its teeth in. In other words, hardly anyone will volunteer to junk more than a year’s work even when it’s the right thing to do.
  6. Capture neat ideas in a roadmap, and leave space to put them in, but promise as little as possible. Non-essential features should be marshalled into a to-do list for a future spec. They may never be needed in practice, so don’t burden early adopters with them.

… Except for the bits that aren’t.

  1. Keep the door open. Never work in secret or limit discussion. These days, being courteous and responsive to keyboard warriors is part of your marketing campaign. However —
  2. Don’t let your guests take over. Good specifications need clear ownership, so limit scope and limit control.
  3. In this industry, don’t sell your spec for money, as it will need all the help it can get. People have grown very accustomed to getting stuff for free.
  4. Make it really easy. Great documentation isn’t enough these days: people expect TED talks, code libraries, unit tests, and preferably source code for a working demo.
  5. Persistent and contrary people will drive you crazy along the way. It may not look like it, but many of the people that work you the hardest will turn out to be your greatest friends and advocates. Like you, they want this specification to meet their needs and succeed in the wider world, which is why they push back so hard. Do all you can to understand them, be unfailingly polite and positive, and go out of your way to accommodate them if that’s what it takes to keep them on-side.

Academic stuff

I realised I didn’t have my academic papers up on the web site anymore. Here are the more significant ones.

Supper, B, 2010. Processing and improving a head-related impulse response database for auralization. Paper 8267. AES 129th Convention.

Supper, B, 2009. Characterising studio monitor loudspeakers for auralization. Paper 7994. AES 128th Convention.

Supper, B, 2005. An onset-guided spatial analyser for binaural audio. PhD thesis, University of Surrey.

Supper, B, 2000. Virtual reality presentation of loudspeaker stereo recordings. Undergraduate technical project, University of Surrey.

VR audio engine running on RISC OS in 2000
VR audio engine running on RISC OS in 2000