SNaPS

Problem

Every sampler I knew treated a sample as if it had a single pitch. Assign a recording to the keyboard and the sampler re-pitches it chromatically across the keys, a digital Mellotron. That works for a piano note or a kick drum. But the sounds I wanted to play weren't like that: they were little recordings of harmony, a cello double stop, a choir chord, several bells ringing together, fragments of counterpoint. The sampler knew where the sample began and how fast to play it. It had no idea what notes were inside it.

SNaPS starts by giving it that knowledge. Every sample is born knowing its pitch classes, and once it knows them, following the harmony becomes simple arithmetic: how far does this recording have to move so that the notes inside it fit the current scale?

Insight

A sample that knows its notes

Instead of asking what MIDI note triggered the sample, the engine checks the pitches inside the recording against the Current Scale. If they're a subset of the scale, the sample plays untransposed; if they'd be a subset after transposition, it plays at that transposition; if no transposition fits, it doesn't play.

The same check runs again at every scale change, and that's where the instrument lives. A sample that's already sounding re-checks itself and bends to fit in real time, because harmony doesn't respect the boundary of a note: if the chord changes while a violin sustains, the violin doesn't restart, she keeps singing through the change. A conventional sampler either lets the sustaining sample clash or cuts and retriggers it, and you can hear the retrigger.

Prototype

2021: the SuperCollider engine

SNaPS started as a SuperCollider instrument that Nathan Ho and I built together, and the idea itself descends from Ho's conception of sound dumplings: hand-assembled collages of samples repitched into a common key and arranged into a single gesture. A finished dumpling is a static object, like hardened lava. The question behind SNaPS was what happens if you keep it molten: live, mobile blobs that collage themselves automatically and re-pitch as the harmony moves.

I wrote the whole system out first as a design document, the "Sample Particle System"; Ho built the engine, and Scale Navigator integration was there in week one. I owned the sample corpus, the metadata standard, and my own performance file, and contributed engine code back through reviewed PRs.

Iteration

The tagging bottleneck

Every sample the engine plays has to be born knowing its own pitch content, so it can be born into the current scale. For years that meant tagging thousands of samples by hand with their pitch classes. I had the corpus and no way to listen to each one.

The unblock came from Ho, in early 2026, when he pointed me at Basic Pitch, Spotify's open-source ML transcription model. I built the Librarian around it: a headless tool (MVP January 31, 2026) that auto-transcribes a sample library into sample→pitch-class-set records. The interface couldn't scale until metadata became automatic.

Final solution

Voice leading as arithmetic

When the harmony changes, every sounding sample evaluates every legal transposition. Small movements cost less than large ones, downward movement is slightly preferred, and ties resolve downward. Those simple constraints produce motion that resembles ensemble voice leading rather than arbitrary pitch shifting.

The glide's shape comes from Ho's oddvoices research, measured from a real singer: ascending glides dip below the starting pitch before they rise, descending glides overshoot the target and settle up into it. SNaPS samples glide along that measured shape, like a voice, not a machine.

Design decision

Seeing the particles

Every playing sample becomes a moving particle, making the texture visible instead of hiding it in a list. I drew it as a swarm because a swarm behaves like an ensemble in a way a sample list never could.

Design decision

Three modes, one engine

The plugin plays the same particle engine three ways:

• Emitter: streams samples continuously at a chosen rate
• Looper: holds chosen samples as sustaining loops on pads
• Sequencer: lays samples out on a timeline

Whatever is sounding when the scale changes obeys the same rule in every mode: bend to fit, or make an exit. The window itself is scale-aware too: the whole interface takes on the root color of the current scale, so the three screenshots on this page are red, orange, and gold because they were taken in C, F, and A♯.

Design decision

The failure is the instrument

Sometimes a sample's pitch content no longer fits the new harmonic state. The obvious solution is to fade it out or mute it, but that throws away an opportunity: those moments can become transitions. A sample can narrow to the notes that still fit through a band-pass filter and open back up when the harmony allows it, or leave on purpose with a stackable exit: a stutter, a filter sweep, a Doppler-style pitch drop. In SNaPS the modulation is the event: the moment the harmony changes is the thing you hear, a texture of dozens of voices leaning into the new chord and a few of them making a scene on the way out.

Outcome

In the studio I routed SNaPS multitrack through Loopback into separate Ableton channels, so it worked as a source, not just a live rig. In 2025 the engine was ported into Ensemble Jammer as browser instruments, and in 2026 it became a plugin, so the workflow I'd performed with for five years finally packages for any DAW (Logic Pro, Ableton Live, anything that hosts VST3 or AU) and subscribes to Dashboard's shared harmonic state like the rest of the ecosystem. Samplerate Counterpoint, an album made entirely with SNaPS, is the sound of the whole system at work.

Related work

Scale Navigator Dashboard — the harmonic state that SNaPS subscribes to
Tonalign — MIDI pitch correction with the same harmony-aware logic
Ensemble Jammer — networked instruments that follow the shared harmonic state
NotesChordScales — the inverse direction: play notes, and the system infers the harmony