Why your browser and your DAW hear the same thing here

Web audio plugins have historically meant two implementations that sound close. One in JavaScript for the demo on the marketing page, one in C++ for the thing you actually buy, and a slow argument in the support forum about why the browser version sounds thinner. Everyone loses that argument. The person playing loses because the demo was a lie. The person maintaining loses because they now own two DSP codebases that drift apart every release.

We started from the assumption that this was avoidable, and the rest of the site is downstream of finding out that it was.

One kernel, two compile targets

A Codex Music tool has exactly one DSP source file. It is written in restricted TypeScript — no allocation on the audio thread, no closures, no exceptions, a subset narrow enough that a compiler can reason about it completely. That file goes through ScriptC twice: once to native code that gets linked into the VST3 shell, once to WASM that gets loaded into an AudioWorklet.

There is no second implementation. There is no "web version" of the filter. When the tone stack changes, it changes in one place and both targets pick it up on the next build, because there is nothing else for them to pick up.

What "identical" means, precisely

The claim we make is stronger than "sounds the same", and we picked the strong version on purpose because the weak version is unfalsifiable. The claim is: given the same input PCM, the same sample rate, the same block size, and the same parameter values, the two builds emit byte-identical output buffers.

That is verified in apps/vertical-slice. The harness renders a fixture through the native build, renders the same fixture through a real Chromium AudioWorklet driving the WASM build, and compares. Not statistically — it takes an FNV-1a hash of each float32 buffer and asserts the hashes match. Any single bit that differs anywhere in the render fails the check.

Getting there was less glamorous than it sounds. Most of the work was removing sources of nondeterminism that nobody notices until they are the difference between two hashes: denormal handling that differed between targets, a fast-math flag reordering a multiply-add, and libm functions whose last bit disagreed across platforms. The fix in each case was to stop trusting the platform and pin the behavior in the kernel.

Why this is worth the trouble

Because it makes the free browser version honest. If the browser build is the same compiled DSP as the plugin, then offering it free at full quality costs a creator nothing they were otherwise selling. There is no feature gate to design, no "demo mode" resampling, no silence injected every thirty seconds. You get the whole tool, in a tab, and what you decide about it there is a real decision.

It also makes the download boring in the best way. When you buy the plugin, you are not buying a better-sounding version. You are buying portability into your DAW, and offline rendering, and your presets on another machine. The sound was already yours.

Go check

The Listening Lab is on this site precisely so you do not have to trust the paragraph above. It runs the same input through both engines in front of you, shows the per-buffer hashes, and reports divergence metrics when they differ. It is free forever, with no account, because charging for the tool that lets you audit our central claim would be a strange way to earn trust.

If you find a case where they diverge, that is a bug and we want the fixture. Open an issue with the input, the sample rate, and the parameter state, and it becomes a regression test.