Modular Synthesis and UNIX

I’ve always loved strange and interesting music and sounds. For the last few months, I’ve been assembling a collection of patch cables and circuit boards on my desk which, when connected just right, can create anything from melodic sequences to fast, driving beats to wacky electronic soundscapes.

This is a modular synthesizer in the Eurorack format. Eurorack is a de-facto standard created by German synthesizer manufacturer Doepfer designed around the concept of voltage control. Levels of voltage between 10 and -10 volts, or changes in voltage, represent and control everything: audio, pitch, speed, slope, and even color.

As I learn more about Eurorack and the modular ecosystem, it reminds me more and more of the magical feeling of working with UNIX tools: it is a world that exchanges programs for filters, oscillators, and VCAs, text for voltage, and pipes for patch cables.

Text, Audio, and Control Voltage

We’re all used to voltage representing audio. An “AUX cord”, correctly called a 3.5mm TRS (tip, ring, and sleeve) stereo cable¹, carries two channels of voltage and a common ground between audio devices through a nearly universal² standard. For audio signals, this voltage jumps between a maximum and minimum voltage. Its value over time is eventually turned into the movement of a speaker or headphone diaphragm, which in turn moves the air and can be heard.

In modular synthesis, though, these analog signals don’t just represent the movements of air that our ears hear as audio. We also use them to control other parameters: pitch, for example. Like the text streams that UNIX tools use to move around data and text, or the JSON payloads that power a huge portion of the modern web, voltage-based communication is simple and versatile.

These voltages are, by their nature, analog - there are infinitely many values between C4 and D4, or even between C4 and C#4. Among other things, this means that complex microtonal music is not just possible, but just as easy for the hardware to produce as music in any Western scale.

Text, of course, isn’t analog, but it does have similar characteristics. It’s not always easy to parse or generate exactly the right text, but with enough information, it’s always possible to interoperate with something that uses a text interface, or even JSON structured data.

Oscillators, Filters, grep, and awk

The traditional synthesizer, as invented by Bob Moog and co., produces sound through a so-called subtractive process. Sound, some kind of complex wave-form, is produced by an oscillator, according to control voltage representing pitch. That waveform, which has lots of harmonics, is put through an amplifier which turns the sound on when a note is being played, and off when it is not, and through a filter, which removes some harmonics and emphasizes others.

Of course, this is not so different from a standard UNIX log mangling pipeline, where cat grabs some output from a file, awk formats it in some easy-to-work-with way, grep cuts out irrelevant information, and head, tail, or a second awk invocation formats the output. This is the versatility of universal, standard interfaces like text, JSON, or voltage; each tool does what it does, and interoperates cleanly with all the others.

Envelopes, Signal Flow, and mkfifo

In my rack, I have a simple signal flow mapped out by the sequence of modules. My Winterbloom Sol turns digital signals into control voltage. The Kinks, Pique and Ornament and Crime modules shape that CV. Then come two oscillators, a filter, a set of amplifiers, and some effects.

But that’s not necessarily the order I actually patch the signal chain.

Most synths have an “envelope” control, sometimes controlling the level of a signal, and sometimes controlling a filter. The magic of modular is that each of those components is discrete. One module generates control voltage every time a note is played. Another module (a voltage controlled amplifier or VCA) uses that control voltage to change the volume of the note, turning a rising voltage into attack and falling voltage into decay. A third module (a voltage controlled filter) uses that control voltage to change the harmonic content of the sound. Just by moving a cable from the “FM” input to the “Q” input, that filter can go from subtracting harmonics to emphasizing them, or maybe both!

This is the flexibility of modular synthesis. Every signal exists within a constrained realm, and every module manufacturer knows what their interface should expect. Each module does some transformation - in a sense, every module represents a mathematical funtion, transforming voltage-over-time and knob positions into voltage-over-time, which can itself be transformed by further modules.

This is not something we see often in UNIX programming - but it is possible! With mkfifo, we can create more complex data flows and unique ways of moving information around, using multiple FIFOs as input and output files. In web systems, this kind of many-way connection is very common; even relatively simple systems like If This Then That allow users to create long, wide, branching data flows, and even flows that contain cycles. Ideally, each program or API does work like a mathematical function, taking command line arguments and input and transforming them into output and perhaps some side effects, like making a Mastodon post or writing to disk or a database.

Modularity, Open Source, and Market Forces

In the forward to The UNIX Time-Sharing System³, the seminal 1978 paper on UNIX, Doug McIlroy articulates the philosophy of modularity thus:

1. Make each program do one thing well. To do a new job, build afresh.
2. Expect the output of every program to become the input of another, unknown, program.
3. Design and build software […] to be tried early, ideally within weeks. ⁴

These are the same values that motivate the design of the best Eurorack modules. Each module is easy to experiment with, designed to accomplish one or a few tasks, explicitly built to integrate with other modules, and well-documented.

Eurorack’s modularity works well because there is no incentive to lock in users - indeed, there is a significant disincentive, since no one small company could ever hope to produce a universal product line. Building modules that work well in as many systems as possible is the best way to maximize sales.

Indeed, even in the cases where larger companies (like Intellijel) have tried to invent their own standards to get at least some degree of lock-in revenue, the size of the market limits the effectiveness of that strategy. Their smaller, 1U form factor has been widely adopted, and there are now nearly a dozen small manufacturers making compatible modules.

We, as software engineers, should strive to build software that is amenable to interoperability, because that is the most effective way to support creativity. Documented, open, and capable APIs are good, if your software must be centralized; federation through open protocols is even better.

Critically, your interface does not need to be optimal. Control voltage in 1v/Oct certainly isn’t; it requires difficult and imprecise exponential conversion circuits, or slow and expensive floating point computations. Consider, for instance, ActivityPub and the Mastodon ecosystem. Eugen Rochko could have easily stuck with OStatus, which does have some advantages, but the Mastodon project’s move to ActivityPub catalzyed an entire ecosystem, with dozens of other microblogging products, as well as blogs, video sharing, music sharing, and photo sharing software springing up, all able to interoperate at least somewhat.

Modularity also promotes longevity. The predecessor to ls was written in 1961⁵; the GNU find command has history as far back as 1987⁶. These programs are so deeply embedded in the brain stem of computing that building a modern server operating system without something compatible is nearly unthinkable.

I should also point out that, while free and open source software is, in my opinion, a moral good, software freedom and open protocols/interfaces are tangential concerns. While many Eurorack modules are open source, some of the most popular are not; for example, Make Noise’s analog computer Maths is not an open source design, but it is the heart of many modular systems because it integrates well into the ecosystem and has a clearly documented and well-specified interface.

Amazon’s Simple Storage Service, for instance, is a proprietary service with an open protocol, and it is hugely successful - so much so that many projects have sprung up to implement its interface, and a huge volume of cloud software is designed to work with “S3 - and other stuff that works the same.”

Modularity is the most direct path to innovation. As software engineers, we should do our absolute best, both technically and politically, to build programs that do one thing well, programs that can be tried early, and programs that work well together. Anything else guarantees stagnation, lock-in, frustration, and eventual obscurity.