Thinking in Diagrams

Music software is good at getting you to a finished-sounding result quickly. Load a project, drag in a synth, add a compressor and a reverb, move a few parameters. A preset hides a lot of complexity and can still be expressive.

Then try to describe the path from source to output. I often can't, not precisely. I added a synth, then an effect, then another, and turned knobs until it felt right. Ask me what makes the sound pulse, or why it opens up in the second bar, and I am guessing at my own patch.

That is fine while I'm exploring. It stops being fine when I want to adjust one movement without disturbing another, replace part of a sound without losing its character, or show someone else how the patch works. The question changes from "does this sound good?" to "can I see why it sounds this way?"

Where this comes from

My inspiration came from two seemingly disparate sources: UNIX and old synthesisers.

The UNIX philosophy, as Doug McIlroy summarised it, has a couple of rules for writing good software:

1. Make each program do one thing well
2. Design programs to connect smoothly with other programs

Neither rule is worth much on its own. Together they give you the pipe. Here is a chain that counts how often each error repeats in a log:

grep error server.log | sort | uniq -c

Three programs, none of which knows the others exist:

• grep error keeps only the lines containing the word.
• sort puts identical lines next to each other.
• uniq -c collapses each run of identical lines into one, prefixed with how many there were.

The result matters less than the shape. Each stage does one job and hands a stream to the next, so the connection is the interface. You can cut the chain anywhere to see what is flowing through it, swap one stage without touching the others, or splice a new one into the middle. Nothing a later stage needs is hidden inside an earlier one.

Early synthesisers printed their schematics on the front panels. The block diagram wasn't tucked away in the manual, it was the face of the instrument, so learning your way around the controls and learning the signal path were the same act.

The MS-20 panel is the same idea in hardware. Across the top, two oscillators run into a mixer, then a high-pass filter, then a low-pass filter, then an amplifier, then the output. Under each stage sits a socket, so you can interrupt the flow: take the filter's output before the amplifier hears it, drive the cutoff from the sample-and-hold instead of the envelope, feed the external signal processor from the noise generator. The panel is a diagram you can plug into.

What I miss isn't the sound or the limitations. It's that you could follow a line from input to output, so when something went wrong there was somewhere to look.

The analogy has limits. A pipe carries one stream in one direction and stops when the data runs out, while an instrument branches, feeds back, and has to keep running in real time. But both put their structure on the surface, and both let you get at any point in it.

Throughline is an attempt to walk back in that direction without giving up what modern tools can do.

The diagram is the instrument

In Throughline the graph is not a picture of the instrument. It is the instrument.

Nodes alone don't get you there. My first sketches used big familiar blocks: a synth node, an effect node. They recreated the original problem one level down: the diagram represented the signal path, but the interesting behaviour stayed inside the boxes.

So the rule I keep tightening is that the musically important behaviour lives in the graph. If a parameter moves, something visible is driving it.

Not every detail, though. A filter doesn't have to expose its coefficients, and a delay doesn't have to draw its buffer. The line I'm drawing is whether a musician can reason about the sound: the modulation source, the feedback path, the clock, the envelope, the point where voices are summed.

A small patch

Take a simple subtractive patch:

graph LR
  midi[MIDI In] --> osc[Oscillator]
  osc --> filter[Filter]
  filter --> vca[VCA]
  vca --> delay[Delay]
  delay --> out[Output]
  midi --> env[Envelope]
  env -->|level| vca
  lfo[LFO] -->|cutoff| filter

In a conventional plugin most of this folds into one synth panel, with the routing spread across tabs and hidden assignments. Drawn out, it becomes a set of relationships you can point at. The envelope opens the VCA. The LFO moves the cutoff. If the delay starts blurring the rhythm, you can follow the feedback path and decide where to filter it.

What the diagram adds isn't control — you had control before — it's orientation. Where the sound starts, where it changes, where it could branch.

What it costs

A wobbling filter is three things on the canvas: an LFO, a range mapping, and a cable into cutoff. Elsewhere it is one knob.

I think that trade is worth making, but only if the editor takes the cost seriously. Common gestures have to stay quick without their mechanism disappearing, and grouping has to reduce noise without turning subgraphs back into black boxes. The approach so far is to let convenience grow out of composition: a useful pattern becomes a group, a common group becomes a reusable node, and a reusable node can always be opened again. The shortcut shouldn't erase the path.

The bet

None of this is an argument against instruments that hide their machinery. On stage I want one knob too. Throughline is aimed at the times when hiding gets in the way: learning a sound, debugging it, extending it, explaining it to someone. In those moments a patch should read closer to a patch bay than a preset browser.

The bet is that visible structure is not only a teaching aid or a debugging tool, and can be part of the musical practice itself.

There is a hole in the argument. A diagram is a still picture, and sound isn't still: an envelope decays, a delay remembers what you played a bar ago. That's the next piece: making state visible.