Tonalign

Problem

I am not a great pianist. My left hand is a liability, and I don't have the fluent muscle memory with chords and scales that comes from years of practice. But I know how to noodle: I know how to mash on the keyboard and hear what I meant to play, even when what came out was a half step off.

The half-step line is an old jazz saying; Tonalign turns it into a plugin. Play a note outside the current harmony and what comes out is its nearest available neighbor, corrected in real time inside the DAW. The incoming note is kept and shown, so you can always see what you played against what the plugin let through.

Insight

The design problem: showing the correction

A pitch-correction layer is invisible by definition. If it works, the wrong note simply becomes a right note and nobody sees anything happen. That's fine for the listener and a real problem for the player: you send a C, you hear a D♭, and the plugin has given you no way to understand why. A correction you can't see feels like a bug. And if the promise is that players who never got the scales under their hands can play without fear of wrong notes, the plugin has to show its work.

Snapping the note is arithmetic. The design problem was drawing the difference between what the player sent and what the plugin let through, on a surface small enough to live in a plugin window, without turning it into a readout the player has to study mid-performance.

Prototype

Getting it under people's hands

Within a month I had a working plugin correcting notes in real time and was already handing builds to friends. The project would eventually wear three names (Scale Navigator MIDI VST, PitchSnap, and finally Tonalign), but the central idea never changed: take incoming MIDI, constrain it to the current harmonic context, and let players hear what they meant rather than what their fingers landed on.

Failure

The correction was inaudible and invisible

The first failure surfaced in week four, in a message to Brady: "when correcting notes, if 2 notes are corrected to the same midi note, how to handle that case." Two different wrong notes collapse onto the same right note: a collision the player never asked for and can't see. That exact edge case, overlapping corrections in fast passages, is still one I'm tuning today.

The second came back in writing. In week eight, Tristan Whitehill (Euglossine) sent the first external QA report on the plugin:

• "the initial setup inside the users DAW was not exactly clear when approaching blind"
• a chord-button bug
• previous-chord tones bleeding through
• "I couldn't remember the buttons I had pressed in succession"

The correction was working and the player still couldn't hold onto what had happened.

Iteration

The same delta, drawn four ways

The design question stayed the same the whole way: draw the in/out delta. The drawing kept changing.

Final solution

The held note

What happens to a note that's already sounding when the harmony changes underneath it? That's answered by the INTERRUPT toggle. With it on, held notes are re-pitched at the exact instant the scale or chord changes, so the modulation stops being a silent background shift and becomes an audible event in every sustained voice.

Correction style: the feature that came last

The Correction dropdown is the newest idea in the plugin. Correction had always folded neighbors together: in C diatonic, the C and C♯ keys both come out as C. But what if C♯ came out as D? Brady argued there should be other modes for how corrected notes land, and the dropdown now holds four answers to what a correction layer should do with a note that doesn't fit:

• Corrective: notes already in the harmony pass through untouched; a note outside it is nudged to its nearest in-harmony neighbor, so C and C♯ both come out as C
• Filter: notes outside the current harmony are silenced instead of corrected
• Stack (Chrom): the whole keyboard restacks in order onto the current harmony, so C♯ comes out as D, and the stacking rule can move even notes that were already right
• Stack (White): the same stack on the white keys alone, sparing the fingering shifts of mixing black keys into white

Outcome

Tonalign shipped publicly in 2022 and again, rebuilt, in 2026. Since then it has been the MIDI-correction layer in every live session I run, including every Ensemble Jammer deployment. It's the "silent" plugin the rest of the ecosystem leans on: it subscribes to Dashboard's shared harmonic state and corrects against whatever chord or scale the room is currently in, no configuration.

It also turned into a compositional instrument I didn't plan for. I run recorded MIDI (Chopin, Liszt, Paganini, competition-grade performances) through it, stealing Chopin's texture and forcing it into whatever harmonic box I choose: "A whole new level of plunderphonics."

What's still unfinished

The collision problem from week four of 2021 is still one I tune by hand, and mid-sustain harmony changes still have edge cases. And there's an absurdity I've made peace with: because Steinberg makes real MIDI-effect plugins nearly impossible in VST3, Tonalign is technically a synthesizer, with a silent, no-noise synth always running inside it just so a pure MIDI tool is allowed to exist.

Credits

Brady Boettcher, C++/JUCE engineering, from a pandemic JUCE-forum post to the present; the early pair-programming sessions survive in the repo as branch names (bboettcher3/session_1 and up), and the plugin announces itself as "by Scale Navigator and Strange Loops." Tristan Whitehill, the first external QA report.

Related work

Scale Navigator Dashboard — the harmonic state that Tonalign subscribes to
Ensemble Jammer — the same harmonic state, followed by networked instruments instead of MIDI
NotesChordScales — the inverse direction: play notes, and the system infers the harmony
SNaPS — a sampler with the same harmony-aware pitch handling, applied to samples