Some find it strange that I transitioned from audio engineering to software development. In fact, I've heard the phrase "odd jump" more than a few times personally. But here's what they don't know: my audio background gave me some neat tricks that have made me a better developer. Allow me to tell you about one of these tricks today.
The Patchbay
The patchbay? You mean that thing in the wall with all the cables hanging out of it? Yeah that. For those who don't know, a patchbay is actually a very simple device. Essentially, it tracks a logical flow of a signal through the steps it needs to take to reach its endpoint, while allowing an operator to interrupt that flow if needed. Now with that very high-level description out of the way, let's talk about signal flow. If I want to record an audio signal, a microphone needs to capture that signal and output it to the input of a mic preamp for amplification. Then that mic preamp, after amplifying the signal, needs to output it to the input of the recording console or interface, which then outputs audio to the input of a recorder, which then outputs to the input of a fader, which then outputs to the input of the speakers, which then ultimately outputs to the input of our ears (that last part isn't on the patchbay). There can be more or different steps depending on the hardware being used, but what I hope to make clear is the relationship between outputs and inputs here.
The patchbay, if configured properly, makes these default connections for us without any intervention, but let's say we want to process our microphone signal through a compressor and record that. Well, the patchbay makes it trivially easy to take the output that's coming out of the mic preamp and reroute it to the input of a compressor. We can then take the output of that compressor and reroute it to the input of our recorder. By taking a problem (sound needs to be recorded and played back) and breaking it down into its component steps, we're able to much more effectively plan out solutions, and implement much more creativity in the execution of those solutions. The patchbay is a brilliant way to visualize this type of problem solving, and it's one of the most valuable skills I learned during my degree.
The World Through The Lens of the Patchbay
Beyond just sound recording, I've found the patchbay can be used to visualize pretty much any problem. Take the problem of making dinner, for example. I have a steak in a package, and I need to turn it into dinner that I can eat. Well first, the package needs to output the raw steak to the input of the hot frying pan. Once the pan is finished processing the steak, it outputs to the input of a board where the steak can rest. Once that's finished, the output ends up at the input of the plate, and then we're done.
Now that's all well and good as a sane default flow, but this isn't just any steak, this is a nice ribeye steak that deserves a proper reverse sear. Well, we can take the output of the package and patch it into the input of a warm oven, the output of which will then be patched to the input of the pan, and the process continues. Nice summer day? The output of the oven can be patched to the input of the grill outside, which can then output directly to the board for resting, skipping the default step of the pan entirely. The possibilities are endless (within reason, don't patch the raw steak directly to the plate unless you really trust your butcher).
Software as a Patchable Problem (or My Confession to Berklee Studio Ops)
This paradigm can easily (and should) be applied to software development. When dealing with something as rigid and literal as a computer, everything can be broken down into pairs of outputs over inputs. It's actually this idea exactly that makes the Unix command line so brilliant; the idea of piping the output of one command to the input of another in a long chain is exactly what a patchbay is doing.
This paradigm allowed me to write software before I even knew how to write software. But before we continue with this story, I owe a quick confession to my old student employment boss, the head of Berklee Studio Operations. I know you were hunting for students using bots. It was me. Please accept my (mostly sincere) apology.
So ok, story time. In school, we had a ridiculous system for booking time in the recording studios. Open time slots for the next day would open for booking at 6:30pm the evening prior, and at that point it was first-come-first-served. Everyone in the department would log in at exactly 6:30, the booking site would take forever to load in, and whoever's request happened to get served first would get the time (and everyone else would get stuck with a 4-6am timeslot and a bad time).
One fateful day, I had the bright idea to do a view source on the booking form page, and I quickly realized that I could apply the patchbay principle (I had no idea what I was looking at). I noticed that when you would click on a timeslot on the calendar, it would take the data associated with that timeslot (output) and use them to fill in a hidden form on the page (input, see what I'm getting at here?). The submit button would then take the data from the form (output), and send them to the booking office (input).
If I could patch into the process somewhere, I could set myself up at quite an advantage, but where would I patch in? Well, the longest part of the process was waiting for the calendar to load in. The hidden form would load nearly immediately, but the calendar was in an iframe with a bunch of Javascript running, so that could take seconds to load if the server was being worked hard (always), so if I could patch into the input of the form, I'd be able to skip over the entire calendar loading process.
I got right to work writing a (questionable) Perl script (why Perl?) that would ask the user's desired timeslot and then output the Javascript one-liner to paste into the browser's address bar (remember when you could do that?) at exactly 6:30:03 (wouldn't want to look like a bot), which would in one step fill in the hidden form and submit, thus allowing me a nearly 100% success-rate booking any studio time I wanted.
(Ethically) Patching Our Way Forward
The mental model of the patchbay is something I've carried with me ever since my time at Berklee, as it's a very intuitive way to reason about the flow of data through multiple discrete processes. Moving beyond small scripts of a questionable ethical nature, I've used this exact mental model when building much more complex software systems, such as game engines and memory allocators. Being able to draw out the control flow with pencil and paper as a series of outputs over inputs can be an absolute lifeline when debugging complex systems.
(And as a quick aside: The Patchbay Principle also got me through Calculus. Each derivative rule takes inputs and produces outputs, draw it like a signal chain and you’re done!)
More than anything though, the Patchbay Principle stands as a reminder to me that we all bring unique experiences to the table that inform the way we think about things. I mean, who would've thought I'd be writing about that humble little jumble of cables hanging out of the wall so many years later. So now I put it to you, the reader: have you ever taken what felt like an unrelated concept and applied it successfully in your own software journey? If so, I'd love to hear about it in the comments!
Top comments (0)