Maru Sampler

Two samplers existed in this repository: a Web Audio prototype that could read a sample library's map, and a compiled reader that could ship as a plug-in. The repository's invariant settles which one is the product — Web Audio DSP is reference-only and never a production fallback — so the reader is the sampler, and the prototype's selection semantics were ported into it rather than the other way round.

What a sampler mostly does is choose. Which recording answers this key, which layer answers this strike, which take comes up next so a repeated note does not sound mechanical, what happens when the key is released. Those choices are the engine. Putting them in a compiled kernel means the choice a plug-in makes and the choice the browser makes are the same choice, provably, rather than two implementations that agree until they do not.

That proof is the point of the gate: twelve scenarios, five lanes — the Node oracle, the ScriptC LLVM archive, the ScriptC C-emission archive, a repeat run, and the wasm32-wasi reactor — compared byte for byte, with behavioural assertions alongside, because byte parity alone would also be satisfied by a kernel that ignored every feature it claims.

Round robin is deterministic here, which is a deliberate departure from the sampler engines it takes after. A clock- or Math.random-seeded selector cannot pass a byte-parity gate at all, so takes advance from a pure integer generator seeded per group. The randomness is real to a player and reproducible to a test.

Some things are refused rather than approximated. Legato is rejected when a bank declares it, with its own return code, because there is no legato axis in the program model; an out-of-range round-robin take is refused rather than wrapped, because a bank whose 33rd take quietly became take 1 would be a plug-in playing the wrong sample. A missing algorithm keeps its content unsupported; it never authorizes a different implementation.