snails.fm/ docs voice tuner

Under the hood

None of what follows changes how the tuner sounds. It changes whether you can trust it. It's documented because trust is a feature you should be able to inspect. This is engineering hygiene made visible, not sonic innovation.

Deterministic, to the bit

Same input, same settings, same output: bit-identical, every render. There is no random number generator anywhere in the plugin and no clock-dependent behaviour; the Ensemble scatter that makes the crowd sound human is fixed difference tables, not dice. If a mix recalls a project next year, the tuner prints the same samples it printed today.

Nothing is allocated on the audio thread

The audio thread performs zero heap allocation, takes zero locks, and makes zero system calls: the three classic ways a plugin causes a dropout. Every buffer is sized at construction for the worst case; switching Range selects an effective size within pre-allocated maxima rather than reallocating. This isn't a policy statement: it's enforced by automated tests that make debug builds abort on any allocation from the audio thread.

Fixed internal chunking

The host's buffer size is irrelevant to behaviour. Internally everything runs in fixed 64-sample chunks (~1.3 ms at 48 kHz), whatever the host delivers, so the sound does not depend on your buffer setting, and neither do the control decisions. All internals are 32-bit float, derived from the host sample rate at construction; nothing is hard-coded to 48 kHz.

Classical DSP, in-house, in Rust

Every algorithm in the plugin is published, classical DSP: YIN and pYIN for detection, zero-frequency filtering for epoch detection, TD-PSOLA for shifting (period-adaptive grains, after Praat), an STFT phase vocoder with cepstral-envelope formant preservation as the second engine. No neural networks, no models, no training data. The whole core is implemented from the papers, in-house, in Rust. The lineage is credited by name across these pages because standing on published work, and saying so, is the same transparency the rest of the tool practises.

One house rule worth stating: no tone processing. There is no saturation, EQ, compression, or "enhancement" anywhere in the signal path. The tuner moves pitch. Your tone is your business.

Measured, not asserted

The claim "it doesn't click" is cheap; the tuner ships with the measurement instead. An offline seam scanner synthesises forty consonant-to-vowel transitions and scans the output for isolated single-sample discontinuities (the signature of a bad splice) across a matrix of configurations. Current steady state: processed output adds zero step-class seams over the dry baseline in every shipped configuration.

The rest of the test surface, counted at the current alpha: 39 plugin tests and 284 DSP-library tests, including dedicated regression tests for the audible defects named in these docs (the onset scoop, harmony-entrance clicks); offline diagnostics for seams, cold starts, and onset preservation; pluginval at its strictest level and Apple's auval, both clean.

You can identify the build

The plugin's display name embeds the short git hash of the build. The title in your DAW identifies the exact code you're running: useful in a bug report, and honest the rest of the time.

last updated · Charlie