For years, in music technology and computing, we’ve relied on an idea so ubiquitous, we take it for granted. That notion is that you can use things together, and they work. At its soul, MIDI gives us the power to assemble different sounds, to record ideas. It means the investment you make in one device, whether a soundmaker or computer, can be expanded. Just brought a new gadget home? Plug it into the old gadget, and use them together.

There’s another notion, even more fundamental, underneath that idea: if you save up your pennies and buy gear, you get to choose what to do with it. This is neither a desire of “advanced” users – on the contrary, casual users of technology are often the first to assume that things will work the way they want.

What if that weren’t true?

I was intrigued, as were many on this site, by the announcement of a MIDI adapter for the iPhone. It’s something I expected from the moment Apple announced support for third-party hardware. It’s a little thing, and definitely a niche product, but that means the ability to turn your shiny, little mobile device into a portable recorder for musical ideas – even with, unmodified, a mid-80s keyboard. Score one for standards.

Line 6 MIDI Mobilizer (hardware) + MIDI Memo Recorder app (software)

But with countless apps for music making on the iPhone already – and many more coming to the iPad – you probably would want to use this MIDI support with more than one app. You might take for granted (there’s that phrase again) the power of connectivity. That’s how computing platforms work.

Not so with the iPhone, and by extension, the iPad.

Hardware must support Apple’s proprietary protocols and APIs, and it requires signing legal documents which, among other things, prevent developers from talking about the contents of the legal agreements and disclosing certain developer features. Partly because of the restrictiveness of these terms, there’s even a murky issue that raises questions about whether more than one application publisher can support a given accessory.

The result is anything but “friendly to beginners,” unless the iPad and iPhone are catering to lawyers.

MIDI, Minus the Compatibility

Line6 have built a really cool little gadget. It plugs into an iPhone, iPod, or soon an iPad, and via their software provides quick recording and playback of MIDI files. And to Line6’s credit, they’ve extended an open invitation to developers to support it. The problem is, supporting any accessory iPhone/iPad hardware is restricted by Apple not technically, but legally.

From Line6’s FAQ:

Can I use MIDI Mobilizer to control synthesizer applications or play other music apps on my iPhone?

This is technically possible, but would require software updates to each application in order to communicate with MIDI Mobilizer. Additionally, the developer of the application would need to become a Line 6 MIDI Mobilizer developer in order to be given the development tools, and allow Line 6 to publish their MIDI Mobilizer-enabled version (currently, all applications for a hardware accessory must come from the same publisher). If there’s an application you’d like to see work with MIDI Mobilizer, please have the developer contact MMdeveloper [at] line6.com for more information.

Line6 can’t talk to me about Apple developer agreements, because they are contractually bound to keep those details to themselves – details below. However, I was able to ask whether the restriction on publishing was one they had imposed.

Their answer: no, they didn’t come up with this restriction. Their understanding of the Apple accessory program is that only one publisher for an app that works with a specific accessory can provide compatibility for the accessory.

While the EFF has released the main developer agreement, I have not seen a public copy of the separate accessory program agreement. But I can confirm at least part of Apple’s requirements for proprietary accessory development below.

Because the accessory document is not available, I’m happy to be corrected. Please, if we’re wrong about this, if there’s a counter-example of an app, let us know, and I’ll investigate. I’d actually like to be wrong, as then we could open the floodgates on more compatible apps.

Assuming this is correct, however, we can assume that multiple applications from multiple developers can’t support a non-Apple accessory, unless they come from the same publisher. And that’s a pretty big issue, if the iPad is – as people claim – the future of computing.

Sure, this is just for hard-line gear you plug in via the connector. And yes, wireless communication still uses open standards for Bluetooth, Wi-Fi (TCP/IP and UDP), and zero-configuration networking or Zeroconf (what Apple calls Bonjour). But those are the exceptions that prove the rule: standards are good. Standards make things work.

And that’s what Apple has done: they haven’t simply simplified a design to make it friendlier to non-techies, or to make the iPad extra slim. You can make non-standard connectors that still work with USB, or use standard, slim-line USB connectors. The Apple Dock Connector is just the physical connection: inside are the actual signals that replace the video, device, and audio connections. What Apple has done is not simply change the technical and industrial design: they’ve added legal restrictions around that design.

No, You Can’t

Whatever the specific restriction around accessories, in general, the terms of the Apple developer agreements can be chilling.

Apple’s iPhone Developer Program License Agreement is a non-public document. The moment a developers signs it, they are contractually obligated not to speak “publicly” about the document. (Some iPad apologists might say, ah, but this is true of many game console developer programs, to which I ask, when did I say that was a good idea? And did that really help make Dragon Age more reliable?)

Thanks to the Electronic Frontier Foundation and the Freedom of Information Act, however, the non-Apple lawyers found a loophole: force NASA, a government agency, to release its document. You can read the results (including, in detail, section 10.4 which bans developers from discussion):

UPDATED: All Your Apps Are Belong to Apple: The iPhone Developer Program License Agreement

I can at least refer to this section:

3.3.20 Your Application may interface, communicate, or otherwise interoperate with or
control an iPhone Accessory (as defined above) through Bluetooth or Apple’s 30-pin dock connector only if You have obtained a license for such iPhone Accessory under Apple’s MFi Program.

The MFi Program refers to “Made for iPod.” There is at least one case of Apple suing a vendor who tried to make hardware without that license, so it’s clear Apple is serious about their intellectual property there.

I can’t refer to the specifics of that license, because they’re not published. In fact, you have to apply for the program before you know the details of the program, and once you do know those details and sign the agreement, you’re obligated not to share them.

But Line6, the self-described only MIDI adapter vendor, has interpreted those rules as meaning multiple application publishers can’t support hardware. And because you need an application to support any hardware, and Apple has complete control over what applications are available through the store, and because jailbreaking iPhones violates US law according to established legal precedent, and because you violate Apple’s developer agreement just by making your app available through jailbreak software sources, Apple is the true, final arbiter on the matter, as they are all matters of developing for their device.

Here’s Apple, again in the developer agreement, on the matter of hardware support:

You agree to inform Apple in writing through iTunes Connect if Your Application connects to a physical device, including an iPhone Accessory, and, if so, to disclose the means of such connection (whether iAP, the headphone jack, or any other communication protocol or standard) and identify at least one physical device with which Your Application is designed to communicate. If requested by Apple, You agree to provide access to or samples of any such devices at your expense (samples will not be returned).

That may be defensible when it comes to verifying quality or providing an official Apple certification. But it shuts down the possibility of DIY hardware, or, as in this scenario, even cases that would provide greater compatibility, interoperability, and usability.

Why this isn’t just for “techies”

A common characterization of iPad criticism is that it’s technological “elites” who care more about features than design.

David Pogue writes in The New York Times (a newspaper heavily invested in the success of the iPad, though that is not disclosed):

In any case, there’s a pattern to these assessments. The haters tend to be techies; the fans tend to be regular people.

Pogue provides no evidence for this description, which is odd, as my experience has been that non-techies generally don’t really understand why techies are so excitable either way. (As for whether “they” want an iPad, they seem as polarized as everyone else. Plenty of non-techies love their QWERTY and have other places to spend $500.)

But it’s a brilliant argument. The only people who would likely debate you – technical experts – are magically excluded from the discussion. “Ah,” says the technical expert. “But you’re a technical expert. It’s not for you. So you’ll have to accept my argument about what non-technical experts want at face value.”

Apple promotes this distortion of the reality of their device. When Stephen Fry asked Apple representatives about missing functionality on the iPad, Jonathan Ive responded with this quizzical answer:

I put to designer Ive the matter of all the features that are missing from the iPad. “In many ways, it’s the things that are not there that we are most proud of,” he tells me. “For us, it is all about refining and refining until it seems like there’s nothing between the user and the content they are interacting with.”

The thing is, those things are there – with an addition: restrictions, encoded in legal documents and developer agreements, about how what is there can be used. Apple’s intention may well be “quality.” But that’s the very essence of control: whatever the reason, one party has control, and the other doesn’t. Get it?

The assumption is that these kind of restrictions make devices more usable and more stable to end users. But how does gagging developers from talking about their legal agreement accomplish that goal? How does blocking application and hardware interoperability – the first thing those “casual” end users would take for granted – make the iPad easier to use?

Not Just an Apple Problem: Reinventing and Uninventing the Wheel

Apple I think deserves the brunt of this criticism at the moment, partly because they’ve made their restrictions legally explicit. But don’t think I’m about to let anyone else get off as easily – not with the entire Internet abuzz about how the “future of computing” is coming and it’ll transform everything we know about the universe.

Google’s Android and Chrome operating systems have none of these legal restrictions. (Android’s Market does require that, if you’re sold through the Market, you can’t be sold through another market, but that’s about it – and even that doesn’t stop you from posting an installer file on your site.)

Unfortunately, Android and Chrome also are lacking in actual hardware support. In reinventing the wheel of what operating systems done, Google hasn’t quite gotten to adding all the functionality we expect in operating systems. Sure, an OS built on the browser sounds fantastic – but what if you have a Chrome-based netbook and decide you want to connect a camera with your vacation photos? There’s tremendous confusion in the developer and device vendor communities about what Android and Chrome are for. Is Android a netbook OS, too? Will Google add hardware support? How? It’s even easier to be critical of Google, too: because their operating systems are based on the Linux kernel, support for a vast array of currently-shipping hardware is essentially ready to go, once they can make up their minds to support it. So, bonus points to Google on not being, to use a technical term, “legal bastards,” minus quite a few points for not shipping hardware support.

That also means a missed opportunity for Google, since restrictions like those above could easily drive vendors and developers into their arms. I’m hopeful that their rapidly-evolving platforms will resolve these issues, but I will hold them to the same standard. Ironically, Apple solved some of the technical problems, but imposed new, arbitrary legal obstacles that cripple their own solution.

There’s also the danger that other vendors will copy Apple’s legal restrictions, thinking that these are part of the appeal of the platform – when, for many of us, they’re quite the opposite. That happened most recently when Microsoft announced it was controlling app distribution and disallowing native development on the upcoming Windows Phone platform. Details of that platform are too early to judge, but it’s a discouraging sign.

If I had more time, this would have been shorter

I bring this up for a reason:

The future isn’t inevitable. This is a fixable problem. Apple could – as they did by loosening the NDA on developers – make this better, and they’d deserve credit if they did.

But we have a special obligation as musicians to cry foul. Musicians have taken a leadership role in defining what computing can be, in stretching the boundaries of digital interaction and expression, and in standardizing means of exchanging ideas, connecting equipment, and collaborating. Music was at the center of the creation of copyright law, musical notation was one of the early international standards, and music itself is one of the earliest forms of communication.

The ability to plug things in and connect them is apparently no longer something we can take for granted. But it is something we can protect and improve.

See original here:
Of MIDI, iPhones and iPads, and a Restrictive Future for Hardware?