Some evenings the desk turns into a workbench without you ever deciding it should. I get home after a day at the office spent wrestling with a badge reader that had stopped responding. I have dinner, decompress, sit down at the desk. Ten minutes later, almost without noticing, I'm back in the exact same situation as a few hours earlier. A synth, turned on its side for the one reason you ever turn a synth on its side: is the cable actually plugged in right, or do I need a new one?

I stopped, connector in hand, halfway through putting it back together. It was the second time in twelve hours I'd asked myself exactly that question. The first time in an office, in front of a system installed by someone else years earlier, with someone next to me waiting for a serious answer. The second time at my own desk at home, in front of a machine whose only job is to make people dance.

Same doubt. Same gesture with my hands. And -- I only understood this later -- almost the same cable.

It wasn't a coincidence, and it took some digging to understand why.

Two jobs, the exact same question

Early 1980s. Two industries with nothing in common run into the exact same problem -- and it isn't a technical problem, it's a market problem.

On one side, musical instrument manufacturers: companies at each other's throats commercially, each with its own proprietary format, and musicians who just want a Japanese synth to talk to an American one without rebuilding their whole studio from scratch. On the other, access control: dozens of reader manufacturers, just as many control-panel manufacturers, and installers who'd like to hook up one company's reader to another company's panel without losing a whole day praying over it.

Stripped down to the essentials, the question is always the same: how does one manufacturer's box talk to another manufacturer's box, if neither one wants to give up its own format?

And the answer, in both cases, is identical: you build the simplest possible thing. Simple enough to cost almost nothing to implement, and open enough that nobody has an incentive to stay out.

That choice has a date. Actually, three.

1983

On August 5, 1983, the MIDI 1.0 specification comes out -- the document the International MIDI Association files with the US Copyright Office as the official version. Seven months earlier, at the Winter NAMM show (the January trade fair for musical instruments), Dave Smith had connected a Prophet-600 to a Roland Jupiter-6. Two synths from two rival companies, in front of people convinced it wouldn't work.

It worked.

MIDI 1.0 is a bare-bones protocol, and it's bare-bones by deliberate choice: a five-pin connector, a serial line running at 31,250 baud -- roughly the speed of an intercom, by today's standards -- and a single direction. The sender talks, the receiver listens, and neither one ever knows if the message got through. Zero acknowledgment, zero error checking, zero possibility of a reply.

That exact same year, RS-485 is born. It isn't a protocol, it's an electrical standard -- the distinction matters, keep it in mind. RS-485 only specifies how two wires carry a signal reliably over long distances, with multiple devices hanging off the same line instead of a separate cable pair for each one. It says nothing about what you write on those wires. Which is exactly why, thirty-seven years later, it'll end up wired into your office door too.

Around the same time, access control adopts the Wiegand interface. Three wires -- ground, DATA0, DATA1 -- the reader scans the badge, spits out a string of bits, and goes silent.

One clarification here, because this is the one place in the piece where someone in the industry could catch me out: Wiegand and RS-485 aren't related. They spread in parallel, but they weren't born together, and under the hood they share nothing. Wiegand starts from a physical phenomenon discovered in the 1970s by John R. Wiegand -- a special alloy wire that produces a sharp pulse when it passes through a magnetic field -- and becomes a de facto standard, meaning a standard that exists because everyone uses it, not because someone wrote it down. It only gets put down on paper in 1996, thirteen years after MIDI.

None of the three was elegant. All three were good enough that nobody ever had to redo them.

Why fossils don't die

That MIDI spec from August 1983 was fourteen pages long. And it was incomplete too -- the MIDI Association itself admits as much in its own historical account: an entire block of controllers was dismissed with a generic "on/off."

Fourteen incomplete pages held up for thirty-seven years.

To make a fair comparison: the standard that governs communication between a badge reader and its control panel today is a ninety-two page document. Better, by every measurable standard. But that isn't why MIDI won -- and it's also why, to be honest, the new one hasn't fully won yet either.

Complete protocols don't win. The ones that win are the ones you can implement in an afternoon.

And once a protocol has won, it never budges again, for a reason you learn on day one of shadowing in my line of work: the cost of switching protocols is never the device, it's the cable inside the wall. You can swap out a reader in twenty minutes. Redoing the backbone of a six-storey building that's still in operation, with offices that need to stay open, is a different project, a different budget, and almost always a different signature to chase down.

We pay the bill for that survival every single day. Wiegand travels in the clear, and -- more importantly -- the control panel has no way of knowing whether the reader is even still on the wall. In that protocol, silence and "everything's fine" are the exact same thing. If someone rips the reader off the wall, the system doesn't even notice.

MIDI 1.0 pays its bill in a different currency: a hundred and twenty-eight velocity values to describe everything between a caress and a hammer blow on a key, and no way for the instrument to tell the computer who it is, or what it can do.

You notice it if, like me, you have to deal with a client who wants more security on a system installed twenty years ago, or when you can't quite find the dynamics of the synth you actually played, and you're trying to reproduce them faithfully in Ableton.

The same cable

The protocol that replaces Wiegand today is called OSDP -- Open Supervised Device Protocol -- and it runs on RS-485, with multiple readers hanging off the same pair of wires.

The lights at the club where you go dancing run on DMX512. The name is already the explanation: Digital Multiplex, 512 channels on a single cable. One channel for every parameter of every fixture, with the lighting desk firing all of them out together dozens of times a second, while each fixture only picks out the numbers meant for it.

And for the data signal, DMX512 uses exactly the same electrical layer as OSDP: same twisted pair, same 120-ohm impedance, same termination resistor at the end of the line, same limit of thirty-two devices per bus.

This isn't a resemblance, and it isn't a metaphor I made up to sound clever: the pair that carries the data is, electrically, the exact same pair. There's a real difference too, though, and it's only fair to say it: the OSDP cable that ends up inside the wall almost always also carries power for the reader -- two extra conductors, on top of the two for data. The DMX cable doesn't: a fixture gets its power from the mains, not from the signal. Four conductors on one side, two on the other. But on the pair where the data actually travels, bit for bit, it's the same story.

Then everyone fixed the exact same thing, the exact same way

And here it is, the part everything above was written to get to.

Three industries that never once talked to each other each took their own one-way fossil and fixed it. Same method, same order. Just not at the same time.

World The fossil The fix Year
Stage lighting DMX512 RDM (Remote Device Management) 2006
Musical instruments MIDI 1.0 MIDI 2.0 January 2020
Access control Wiegand OSDP becomes an IEC standard May 2020

Fourteen years pass between the first one and the last two. And that's exactly what makes it interesting -- not despite it.

If they'd all shown up together, I'd have a boring explanation ready-made: a fad, or some enabling technology maturing and unlocking three industries in the same quarter. A fourteen-year gap rules out both the fad and the technological coincidence. What's left is three industries that, each on its own schedule, run into the same wall at different times -- and find the exact same door.

Because all three fixes do the same three things, in the same order.

First: the device can talk back. RDM adds two-way communication over the same DMX pair, no rewiring needed. MIDI 2.0 makes the conversation bidirectional. OSDP polls the readers, and the readers finally reply.

Second: the system discovers and negotiates on its own. RDM goes and finds the fixtures hanging on the line, one by one. MIDI 2.0 introduces MIDI-CI -- Capability Inquiry -- which lets one instrument ask the other what it can do before they've even played a note together. OSDP keeps its readers under constant polling.

Third: the controller always knows how things stand. Whether the device is alive, whether it's faulty, whether someone has tampered with it. In access control this is the part that's a genuine game-changer for whoever designs a system: OSDP monitors the wiring continuously, and its secure channel encrypts everything that travels over it. It's literally in the protocol's name -- supervised.

Three different working groups. Three industries without a single point of contact, commercial or personal. Nobody copied anybody, and I'd bet most of them didn't even know the other two existed.

It isn't a coincidence. It's what happens when a protocol built to talk to mute devices ends up having to govern intelligent ones, over a network that has since turned hostile. The solution wasn't chosen at a drawing board. It was found three times, fourteen years apart, because it was the only one that existed.

Latency is the first thing you feel

There's one last thing these two jobs have taught me, in completely different words.

In the studio, ten milliseconds between the key you press and the sound you hear are the difference between playing and fighting your own instrument. You don't count those ten milliseconds: you feel them in your hands, you start playing ahead to compensate, and from that point on the groove is already gone. Nobody listening will ever be able to tell you exactly what was wrong -- they'll just feel that something was off.

At a company's entrance, three hundred milliseconds between the badge tap and the turnstile release are imperceptible on their own. But at eight-thirty in the morning, with two thousand people coming in over the same half hour, those three hundred milliseconds turn into a queue. And the queue is the only thing a client will ever notice about your system -- not the architecture underneath, not the redundancy, not the encryption on the wire.

Same physics, completely opposite tolerances, the exact same lesson: latency is the first thing whoever uses the system perceives, and it's the last thing anyone talks about while designing it.

The desk

Let's go back to my evening at the desk.

For years I thought my two halves only had the method in common -- the same fussy attention to detail applied to two subjects that have absolutely nothing to do with each other. That evening I understood they also have the material in common, and that the material carries the exact same constraint with it.

In the studio that constraint is called an old instrument: a machine that does exactly what it knew how to do forty years ago, and so you either compose inside those limits, or you don't compose at all. At work it's called an existing system: kilometers of cable inside walls I've never seen, laid by someone I'll never meet, that decide upfront most of what I can actually propose to a client.

For years I treated the constraint as the enemy of the project. In neither job is that true. The constraint is the first useful piece of information you get -- often the only reliable one -- and it's the reason a solution has the shape it has, and not a different one.

Whoever shows up with the perfect solution and the wrong cable hasn't understood the job. In either one.