How to read this

What Auracle computes, in enough detail to disagree with.

This book is the technical companion to the guide. The guide says what the instrument does; this book says how, with the math written out and pointers into the code that implements it.

It is organized as a pipeline, because that is what Auracle is. A term (the genome) compiles to a patch, the patch renders audio, the vetting gate passes or quarantines it, $\varphi$ measures it as 44 numbers, and the utility $u_\theta$ scores it:

$$\text{term} ;\xrightarrow{\text{compile}}; \text{patch} ;\xrightarrow{\text{render}}; \text{audio} ;\xrightarrow{\text{vet}}; \text{audio} ;\xrightarrow{\varphi}; \R^{44} ;\xrightarrow{;u_\theta;}; \R$$

A loop closes over it: the player’s picks condition the taste parameters $\theta$, and $\theta$ reshapes how the next term is proposed.

Three commitments

Every number is sourced. Thresholds, dimensions, defaults, and step counts are quoted from the code, with the constant named so a reader can check. Where a figure came out of a measurement, the measurement is named too.

Design and implementation are distinguished. Several things in Auracle are intended as one algorithm and currently implemented as a simpler one. The clearest case is refinement: the design is tempered sequential Monte Carlo, and what ships is a short local Metropolis–Hastings walk. Those pages say so in their first paragraph. See Refinement.

Known weaknesses are stated. Where a coefficient is unidentified, a variance inflation factor is uncomfortably high, or a memory spike is unfixable without forking a dependency, it is written down.

Four pages to start with

1. A typed PCFG over patch terms is the representation decision everything else follows from. Because the genome is a typed term rather than a parameter vector or a raw graph, all three levels of evolution (settings, connectivity, module set) live in one object, and every sample is valid by construction.
2. Trace addresses are the naming scheme shared by panel knobs, hand edits, locks, live parameter handles, and search proposals. Nothing else stays coherent without it.
3. Utility as a max of experts explains why taste is a maximum over styles rather than a mixture, and what that buys.
4. The vetting gate explains why randomly composed DSP graphs are safe to put in front of a person.

Conventions

• Code references name the crate and the item: auracle_features::vet::VetConfig. The API documentation has the generated rustdoc for all of them.
• Math follows Notation. $x$ is a patch term, $\varphi(x)$ its feature vector, $\theta$ the taste parameters, $u$ the latent utility.
• Measured claims cite the harness that produced them, usually an example binary such as auracle-session/examples/search_health.rs, runnable from a checkout.

What lives elsewhere

• The generated API documentation is the rustdoc.
• Playing the instrument is the guide.
• Working on Auracle (layout, the quality bar, the sharp edges, cutting a release) is CONTRIBUTING.md.
• What changed when is CHANGELOG.md.

Design decisions, rejected alternatives, the milestones, the open questions, and the directions nobody has raised yet are in this book, under Design. They used to be a DESIGN.md at the repo root, which made the reasoning and the math it justifies two documents that could disagree.

The two libraries underneath

Auracle is thin on top of two in-house libraries:

• fugue-evo does evolution as Bayesian inference. Priors as probabilistic programs, typed Metropolis–Hastings with automatic reversible jump, grammar-based genetic programming, tempered SMC in trace space. Auracle’s grammar is a GenomePrior, and its search is fugue-evo’s typed MH with a learned fitness plugged in. Auracle uses neither the tempered SMC nor any crossover.
• quiver does modular synthesis. Arrow-style combinators, typed ports (Audio / V-Oct / Gate / CV), patch graphs, headless rendering, first-class WebAssembly. Auracle’s genome is a term in quiver’s combinator algebra; its “compiler” targets a quiver patch graph.

Where a guarantee comes from one of them, this book says so.

Notation

Fixed throughout. Where a symbol appears in the code under a different name, the code’s name is given.

Objects

$\varphi$ is always the concatenation $[\varphi_{\text{audio}} ; \varphi_{\text{struct}}]$, in that order. It is written $\varphi$ rather than $\phi$ throughout; the code’s phi is this vector.

The taste model

Search

Conventions

• $\sigma(\cdot)$ is the logistic function $\sigma(v) = 1/(1+e^{-v})$, never a standard deviation. Standard deviations are always subscripted ($\sigma_\theta$) or written as $s$.
• $\log$ is natural. Log-losses are in nats.
• Indices are 0-based, matching the code, including cutpoint indices, which matters for reading the ordinal likelihood.
• Weights $w$ are always normalized unless stated: importance weights sum to one, recency weights are relative to the newest observation being $1$.
• “Standardized” always means after the affine transform in Standardization. The taste model never sees raw $\varphi$; the observation log never stores anything else.

KaTeX macros

Defined in www/reference/katex-macros.txt, which book.toml points to, so a symbol cannot mean two things on two pages:

The crates

Core-library-first. Every frontend is a thin shell over the same engine.

crates/
  auracle-grammar    the genome: typed PCFG over quiver combinator terms,
                      trace codec, term → Patch compiler, structural edit ops,
                      rack description, presets
  auracle-features   phrase render → vet → LUFS-normalize → φ extraction
  auracle-taste      max-of-experts utility, three likelihoods, MCMC posterior,
                      standardization, portable profiles
  auracle-session    the two-loop engine: pool, acquisition, refinement,
                      lineage, calibration, persistence, migration
  auracle-wasm       WasmEngine (worker-side brain) + LivePoly (worklet-side
                      instrument)
apps/web             the instrument: vanilla JS, no build step

Dependencies run strictly downward: grammar knows nothing of features, features nothing of taste, taste nothing of the engine. session is the only crate that sees all of them, and wasm is a binding surface with no logic of its own.

auracle-grammar

The representation, and the crate everything else is built on.

genome’s codec is the grammar’s addressing. It is one scheme rather than two kept in sync, which is what makes a knob turn, a lock, and an MH proposal refer to the same thing.

auracle-features

The measurement crate. One render serves three purposes: the vet report, the feature vector, and the audition buffer the player hears.

pipeline::featurize is the whole crate in forty lines, and the order it composes them in matters; see The vetting gate.

auracle-taste

The model. No knowledge of patches at all: it consumes standardized feature vectors and feedback events.

synthetic is not a test helper that happens to live in src/. It validates the taste model against a simulated user with known ground truth: assert the posterior concentrates on $\theta^*$, and that acquisition regret shrinks. That makes the core falsifiable headlessly.

auracle-session

The engine every frontend drives.

auracle-wasm

Two objects, on two threads, and the split matters:

• WasmEngine is the whole auracle-session engine, in a Web Worker. Pool filling, posterior fits, refinement, workbench edits. Nothing real-time.
• LivePoly is the instrument, in an AudioWorklet. It holds $N$ compiled copies of the current patch, via the same compile() path evolution uses, limiter included.

So what the instrument plays is not a re-implementation of what was evolved; it is the same compiled artifact. See The web runtime.

apps/web

Vanilla JavaScript, no build step, no framework, no dependencies. Among its scripts: main.js (UI and Web Audio), worker.js (the engine), farm.js (a stateless render and walk worker), live-audio.js (worklet assembly), perform.js (PERFORM), taste.js (TASTE and LEARNING), midi.js (MIDI controllers) and booth.js (booth mode). Beside them are smaller modules, most of them pure rules with unit tests of their own, such as words.js (sentences built from engine facts), taste-geom.js (TASTE’s and LEARNING’s geometry), deal.js (EVOLVE’s dealing) and toasts.js (the toast lane). apps/web/AGENTS.md lists every one and what it holds.

Its own architecture notes are in apps/web/README.md; the parts that constrain the engine are in The web runtime.

Foundations, from crates.io

All three come from the registry. To hack on them alongside Auracle, add a [patch.crates-io] block at the bottom of the workspace manifest.

Two build settings worth knowing, both in Cargo.toml:

• Release builds use lto = "fat", codegen-units = 1, panic = "abort". Everything the player waits on is render-bound. panic = "abort" also drops unwinding tables from the wasm bundle. None of these can change float results; only --fast-math-style options could, and none is enabled.
• serde_json with float_roundtrip. The observation log is the profile’s source of truth and must reload bit-identically; serde_json’s fast float parse can be off by one ULP.

The two loops

A machine-paced loop and a human-paced loop, sharing one observation stream.

┌─ patch loop (fast, silent, machine-paced) ─────────────────┐
│  grammar prior → vet → pool                                │
│  local MH toward π_β: subtree moves → struct-screen →       │
│  render survivors → feature-score                          │
└──────────────┬─────────────────────────────────────────────┘
               │ candidate pool (`pool_size`: 48 by default, 40 in the app)
               ▼
   acquisition: choose what to play
   (uniform by default; BALD selectable)
               │ audition + feedback events
               ▼
┌─ taste loop (slow, human-paced, persistent) ───────────────┐
│  observe events → posterior over (θ, τ, cutpoints)         │
│  persisted across sessions = the user model                │
└──────────────┬─────────────────────────────────────────────┘
               │ θ reshapes the prior's proposal weights
               └──────────────► back into the patch loop

The two loops run at different speeds on purpose. The machine can evaluate thousands of candidates against a learned surrogate silently, and surface only a curated few. That addresses interactive evolution’s classic failure mode: the human bottleneck, where a user is asked to rate a whole population per generation and quits from fatigue.

The patch loop

Machine-paced. No human in it.

1. Fill. Sample terms from the grammar prior, compile, render, vet, featurize. The pool target is SessionConfig::pool_size vetted candidates (48 by default in engine.rs; the web app passes 40 in apps/web/main.js), with at most max_draws (400) draws attempted per fill, since vet failures burn attempts.
2. Refine. Once a posterior exists, take the top refine_seeds candidates and run refine_steps Metropolis–Hastings steps from each. The defaults in engine.rs are 10 seeds × 40 steps, both scaled from the grammar’s processor count (N_OPS, 20, in prior.rs), so a change to the processor set does not silently change the search’s character.
3. Inject. Each child is admitted only if it beats the member it would displace. When the generation ends, the lowest-utility members are replaced to bring the pool back to size. Pinned (saved) candidates are exempt, including ones pinned while the generation runs, and so is a sound kept as new until its first pick (at most pool_size / 4 of them, persistence).

The 10 × 40 split is measured; moving in either direction is worse.

The taste loop

Human-paced, and persistent across sessions.

1. Observe. Every duel (an EVOLVE pair, a heard PERFORM offer, or an edit claim), star, and cut appends to the observation log, as raw $\varphi$, never standardized. That is what lets the standardizer be re-fit later without invalidating history.
2. Reweight, immediately. Each new observation folds into the existing posterior by importance sampling. It is exact, costs time linear in the number of posterior draws, and is what makes the next pair respond to the last pick.
3. Refit, every sixth pick. Full MCMC over the log: 10,000 post-warmup steps (mcmc_samples) after 3,000 warmup steps (mcmc_warmup), thinned to at most 500 retained draws (KEEP, in auracle-taste’s model.rs).

The app paces refits by count: every sixth pick refits (FIT_EVERY, 6, in apps/web/main.js), and so do the end of the warm start and opening a taste profile that holds picks. The engine also reports when the cheap path has run out of road, that is, when the reweighted posterior’s effective sample size has collapsed far enough to need resampling since the last fit (Engine::needs_refit). The app does not wait for that signal. See The posterior.

Where they meet

Acquisition picks the pair the player hears next. The taste tilt carries $\theta$ back into the grammar.

The tilt is the part that makes this more than a scored search. The fitted structural coefficients reshape the categorical weights of the grammar the search draws new modules from. Because the tilted grammar is installed as the prior, they also reshape the target the search climbs (see Proposals). Kind $i$’s weight $w_i$ is multiplied by $e^{\eta t_i}$, where $t_i$ is the fitted coefficient for that kind and $\eta$ is the tilt strength (proposal_tilt, 0.6, in engine.rs):

$$w'_i ;\propto; w_i \exp(\eta, t_i)$$

with each multiplier clamped to $[\tfrac14, 4]$ so no module kind is ever starved or monopolized. Details and the shrinkage applied to $t_i$ are in Proposals.

So the loop is closed: the player’s picks change what gets proposed and what the search counts as parsimonious, not only what scores well once proposed.

Why this is preferential Bayesian optimization

There is a latent objective (the player’s utility), an expensive oracle (the player), a cheap surrogate (the posterior), and a generator of candidates (the grammar prior plus MH). The acquisition step is where $\theta$’s posterior uncertainty would earn its keep: early sessions could ask informative questions (duels the model cannot rank), and a confident model could mostly serve sounds it predicts the player will pick.

Whether it is worth asking informative questions rather than random ones is an empirical question. See Acquisition.

The gate on all of it

auracle-session’s closed-loop test runs the engine against a SyntheticUser with known ground-truth $\theta^*$, end to end through the real grammar → render → vet → feature pipeline, and asserts that the learned taste ranks genuinely preferred patches on top.

It is slow, and it is the only test that can fail when the loop is broken while every component is individually correct.

Trace addresses

The spine. Six subsystems refer to the genome, and they all use this one naming scheme.

A trace address names one probabilistic choice site in the grammar program. Every site in a term has one, and it is derived from the site’s position in the tree rather than assigned:

The pattern is <path>#<param> for parameters and <path> for structure. Paths are /-separated child indices from the root; a /m segment enters a modulation slot, and because every modulation key sits below a /m, the child convention is reused there without ambiguity.

What shares it

Six subsystems, one vocabulary. The alternative is three schemes that drift: a UI parameter id, a genome index, and a DSP handle, mapped to each other. The drift surfaces as a knob that edits the wrong thing after a structural change.

Why it cannot drift

Because the canonical trace codec is the addressing scheme, not a translation of it. auracle_grammar::genome encodes a PatchTree to a fugue::Trace by walking the tree and emitting exactly the addresses the grammar program samples at. The same walk decodes.

A round-trip property test pins it: encode a random term, decode it, and require the result be identical. If the codec and the grammar ever disagreed about what a site is called, that test fails.

Structure is encoded in its own choices

The reason a tree can live in a flat trace at all: the structure of an execution is determined by the choices the execution makes. The value at node#leaf decides whether node is a source or a processor, which decides whether node/0 exists at all.

That is what lets fugue’s generic trace machinery work unchanged: subtree regeneration and reversible-jump Metropolis–Hastings operate on traces without knowing anything about synthesizers. Auracle contributes a grammar, not an inference algorithm. It uses no crossover: every child grows from one seed (walk.rs).

Live parameter handles

When a term is compiled, each continuous parameter site yields a ParamHandle, an atomic the audio thread reads. Turning a knob does two things:

1. Writes the atomic, so the running voices change without a recompile.
2. Writes the genome at the same address, so the edit is real rather than cosmetic.

Both, always. Writing only the atomic gives a knob whose change disappears on the next patch swap; writing only the genome gives a knob that must be recompiled to be heard.

Not every address has a live handle. Structural sites do not, and a few parameters feed compile-time decisions. window.__aur.nonLiveAddrs in the web app is the set that requires a recompile.

Locks, precisely

$\mathcal{L}$ is a set of exact address strings, typically snapshotted from the UI. A proposal $x \to x'$ is rejected if it changes, deletes or creates any address in $\mathcal{L}$.

All three, and the third is the one that is easy to omit. Scanning only the current trace lets a birth at a locked address through while rejecting the death that would undo it. That is an asymmetric constraint region: it breaks detailed balance, makes the exactness argument false, and lets the chain drift into locked structure it can never leave.

One limit: a structural move can grow a brand-new address inside a locked module, present in neither trace, so it cannot be in $\mathcal{L}$. That case is symmetric (unmatched in both directions), so it costs nothing in detailed balance. A lock is a guarantee about addresses, not about subtrees.

Persisted UI state must be JS-owned

A rule from the web app, and it belongs here because it is about this scheme. UI state that persists must be held in JavaScript and never scraped from the DOM at save time. A phantom DOM slider (present but not the live control) once reset a value and poisoned an autosave with it.

The address scheme makes the genome authoritative; the rule keeps the interface from quietly disagreeing with it.

A typed PCFG over patch terms

The genome is a term in quiver’s combinator algebra, generated by a probabilistic context-free grammar whose non-terminals are signal kinds.

The representation decision

The genome is a tree: a term in quiver’s Layer-1 combinator algebra. It is not a raw patch graph and not a parameter vector, and the patch graph is the compilation target.

Everything follows from this. One representation covers what usually needs three:

A parameter-vector genome cannot change topology. A raw-graph genome can, but most of its mutations produce invalid graphs, so it needs a repair step, which is a second, undocumented grammar. A typed term needs neither: every sampled term compiles to a valid, sound-making patch, because the type system constrains which productions can fire where.

The sorts are quiver’s signal kinds: Audio, V/Oct, Gate, CV. Auracle’s PatchTree splits into AudioNode and ModNode, and the split is enforced by Rust’s own type system: an ill-sorted term is not rejected at runtime; it cannot be constructed.

The grammar as a probabilistic program

PatchGrammarPrior is a fugue program. Every node at tree path $p$ emits real probabilistic choices at path-keyed addresses:

The amplitude envelope is fixed at amp#attack … amp#release.

The three categorical orders (8 sources, 20 processors, 9 modulation kinds) are the persisted wire format, because the codec writes the chosen index into the trace. They are append-only.

Parsimony is the prior, not a penalty

Deeper terms pay more prior mass by construction: each additional level of recursion multiplies in another #leaf Bernoulli that came out “processor”, and each processor node draws its own parameters. There is no size penalty term anywhere.

Ad-hoc parsimony penalties are the norm in genetic programming and a persistent source of trouble: they need tuning, they interact badly with fitness scaling, and they leave the target distribution unwritten. Here the target is written down: $\pi_\beta \propto p_{\text{grammar}} \cdot e^{\beta u}$, and $p_{\text{grammar}}$ is exactly the parsimony pressure.

Modulation is a recursive sort

A modulation input does not take “an LFO”. It takes a modulation term, which can itself be built from modulation terms:

• Six leaves: LFO, envelope, random (sample-and-hold), envelope follower, Euclidean, step sequencer.
• Op wraps one modulation term: quantize, slew, rectify, hold.
• Pair combines two.

The #mod order is None, Lfo, Env, Rand, Follow, Euclid, Op, Pair, Steps. The step sequencer is a leaf that sits after the two branches, because the order is append-only wire format and it arrived last. So “is this kind a leaf” is a predicate (mod_kind_is_leaf), not an index range: the range it replaced (kind < 6) would have switched the new leaf off at the depth bound along with the branches, and a term forced to bottom out could never have drawn it.

The step sequencer’s values are latent

Steps carries eleven continuous sites: #srate, #slen, #sslew, and one per step, #s0 … #s7. Each step value $u_i$ is its own $\mathrm{Uniform}(0,1)$ draw and plays as $(2u_i - 1)\cdot 5\text{ V}$; #slen decides how many of the eight play (2 to 8, seven equal bins of the knob). This is the Mutable Instruments Marbles design, turned into a genome:

• One site, one step. An MH proposal that moves #s3 re-voices step four and nothing else, so evolution edits a pattern the way a hand does.
• Hidden, not deleted. The steps past #slen stay in the trace. A proposal that shortens the pattern and a later one that lengthens it give back the steps that were hidden instead of inventing new ones.

The module behind it is Auracle’s own (auracle_grammar::steps::StepsCv) rather than quiver’s StepSequencer, whose values are internal state with no ports: every one of the eleven sites is a port driven by a live knob, so a bar drag in the rack is an atomic write, not a recompile. Its clock is free-running (#srate is $0.5\cdot 2^{5x}$ steps per second), and every audition hears it that way; tempo sync is a live-instrument concern and is not in the genome. With the dock’s sync on, the live engine snaps each sequencer’s rate to the nearest division of the tempo in octaves (straight, triplet, or dotted; a quarter-step per beat up to eight) and drives every voice’s clock from one transport through a sync port the term never sees (<key>#~sync). The transport restarts on the first key down or on MIDI start, and it counts steps, not bars, so a five-step pattern keeps its polymeter against a four-beat arp.

So s&h rand → quantize → slew is a legal modulation term, and the rack draws the whole chain. Subterms live at <p>/m/0 and <p>/m/1, the same child convention the audio tree uses; it is unambiguous because every modulation key sits below a /m.

Its parsimony pressure is max_mod_depth, and the renormalizations that enforce it live in mod_weights_at: at maximum depth only leaves remain available, and below a processor the “no modulation” option is removed so a slot that must be filled is filled.

A modulation slot hangs off every module with somewhere to send it. The exceptions are the ones without: Noise, whose only site is a color switch, AudioIn, whose only continuous knob is a level, Mix / RingMod, whose two inputs are both audio and whose single knob is the blend, and the two player kinds, Track and Capture, whose knobs are how they listen and play. Having two audio children is not itself an exception: the four sidechained productions (comp, duck, gate, and vocoder) take two subterms and carry a slot as well.

The modules

Forty-six modules: 8 sources, 22 processors (20 the prior draws and 2 player kinds), 16 modulators.

sources     Vco  Supersaw  NoiseGenerator  Wavetable  KarplusStrong  FormantOsc
            Silence  AudioInput
processors  Mix  Filter  Fold  Delay  Chorus  Reverb  Distortion  Bitcrush
            Phaser  RingMod  Flanger  Tremolo  Vibrato  Eq  Granular  Shift
            Comp  Duck  Gate  Vocoder
            PitchTracker (Track)  Capture        (player kinds)
modulators  Lfo  Adsr  SampleAndHold  SlewLimiter  EnvelopeFollower  …
            StepsCv (Auracle's own: a step sequencer whose values are ports)

Seven processors are binary:

A compressor’s sidechain is not an audio input, and the type system makes wiring it as one impossible.

AUDIO IN: the player’s input

AudioIn is a source whose signal comes from outside the patch: one of the host’s inputs, read through quiver’s AudioInput (ADR-015). It is source index 7, with three knobs:

What it is for comes from where it is patched: into a filter or a delay it is processed, into a ducker’s key or a vocoder’s modulator it shapes another sound. It is measured with the session’s audition clip, never with the live input.

The input belongs to the player. #input is a real trace site, so the rack, a knob edit, a lock and the lineage diff all address it, but the grammar never chooses it. Its distribution, PlayerInput, samples slot 0 and gives every slot the same (unnormalized) mass, so a node the prior draws reads the first input, and a player’s choice of slot 3 is exactly as probable, and as evolvable, as slot 0. A refinement walk locks every #input its seed holds (locks): it may change the gain, the channel and everything the signal goes through, and never the input or the node itself.

AUDIO IN is a player kind, like TRACK and CAPTURE below: the prior never draws one, and scores a player’s. Its source weight is 0 (AUDIO_IN_WEIGHT), with no taste tilt, so no fill, walk or offer deals an input and the source table draws exactly what it drew before the term: whether a patch listens is a choice a player makes by patching one in. The #src site’s distribution, SourceKind, samples that table unchanged and scores AUDIO IN at PLAYER_SOURCE_MASS (0.005) where the table gives it none, so a listening patch is inside the support and ⚡ and generations walk it, holding the node by its #input.

TRACK: an input plays the patch

Track lets a voice or an instrument play the patch the way the keys do (RFC-008’s play the patch). It compiles to quiver’s PitchTracker, which reads pitch by YIN, a gate and a level from its /1 branch (usually an AUDIO IN), and it is #op 20.

The input is the keyboard for /0. While the compiler builds the played branch, the tracker’s pitch and gate stand where the keys’ stand everywhere else: a VCO there sings the tracked note (its octave knob still transposes it), a pluck is plucked and a mod envelope fires on every tracked onset. The tracker’s gate is also summed into the voice’s amp envelope with the keys’ (either opens it), so a note sung into an AUDIO IN sounds the way a key does, and a key let go while the input still sounds holds the voice open until the input stops. Outside /0 the keys play the patch as before, so a mix can hold a tracked side and a keyed side.

Three consequences worth knowing:

• A chord collapses. Every voice of a chord plays the one tracked note inside /0: there is one input, and one pitch in it. In the audition phrase the dyad’s second voice is a follower: it plays the note the main voice’s tracker hears from its first frame, and its amp keeps its own key’s gate, so it stops with the dyad.
• Live, one voice tracks. The instrument (LivePoly) builds a patch with a TRACK with one tracked voice, its open voice, and every key’s voice is a follower of it, as the phrase’s chord voices are: so a key let go stops with its key instead of staying open while the input sounds. The tracked voice is not held like a key; its tracker’s gate opens it, so while the input is monitored it sounds when the input does. It renders its quantum first and copies its tracked signals frame by frame (CompiledVoice::read_tracks) for the followers to read before each of their frames.
• Before the first tracked note, /0 plays C4 (the tracker’s 0 V), and between notes it holds the last note it tracked.
• The tracker hears what is there. Where one note still rings under the next, YIN can read the pair (see below).

Rendered on the audition clip, a TRACK plays the reference figure’s notes: thirteen of its fourteen within 1.4 cents, and the D4 that sounds over a still-ringing E4 17 cents sharp, because YIN hears the pair.

CAPTURE: a recorded take as a source

Capture records what is patched into it and plays the take back (RFC-008’s resample). It compiles to quiver’s Capture and is #op 21.

Its output is its take, not its input. /0 is what it records; it is built and running, and never heard. So inserting a CAPTURE turns the chain below it into what is recorded, and the patch plays the take instead. Each note plays the take at the keys’ pitch, C4 at the speed it was recorded; an empty take plays silence, as an unplugged socket does.

The take is the sound’s content, saved in the term:

"take": {"format": "f32le-base64", "sample_rate": 48000.0, "length": 96000, "data": "…"}

It is quiver’s own Capture state, lossless, so a reloaded take plays back bit for bit. A take is bounded the way an audition clip is: the format tag, a rate no higher than MAX_TAKE_RATE (192 kHz), a length no longer than TAKE_SECONDS (4 s, quiver’s default Capture buffer) at that rate, and the data’s length checked before it is decoded. A take that breaks a rule never costs the sound: the term loads with the take empty, and a restore counts the sound as repaired, so the app says so. When that take was the sound’s only source it no longer renders, and the restore keeps it aside (the engine’s held list) instead of dropping it: out of the pool, so nothing deals, fits or breeds it, reported apart from the repairs (“One sound’s take couldn’t be read. It’s kept safe until you record it again.”, once for each set of such sounds), and written back by every save with its take JSON-equal to what was loaded, until a readable take brings it back (readmit_held), measured as a new sound. A fragment sent with a take that couldn’t be read (SetTake, ReplaceTree, InsertTree) is refused. A take is not a trace site, so no walk can propose a new one, and an edit that changes only a take logs a lineage event whose diff is empty.

A recording stops at TAKE_SECONDS at the voice’s rate (the record gate goes through a window that closes then), even into a buffer a longer, higher-rate take has enlarged, so what a capture records always reads back as a take.

Recording is the host’s. A compiled voice has a record gate per capture and reads the take back from quiver’s state, and StructOp::SetTake puts it in the term. Nothing in the engine raises the gate, so a measurement render never records and a capture measures the same every time. In the app, RECORD on the CAPTURE’s plate has the worklet copy the input the CAPTURE listens to while it is lit, and on STOP (or at TAKE_SECONDS) the engine worker plays that copy through one voice of the patch, its key held at C4 and the gate raised (render_take, with LivePoly::set_record and LivePoly::take_json): the take a voice recording live would have made, without compiling, rendering or encoding on the audio thread. The take goes out as set_take, an edit like any other. A sound kept safe is recorded the same way from its saved term, and the take goes to readmit_held.

Player kinds: scored and never drawn

Track and Capture are player kinds: a sound has one because a player put it there. The prior must never draw them (a drawn tree that tracks or captures would move every random-tree statistic, and a capture with nothing recorded is silence), but it must not score them at zero either: a tree the prior gives $\log p = -\infty$ cannot start a walk, so a player’s tracked sound could never be evolved.

The #op site’s distribution, OpKind, does both, as PlayerInput does for #input. Its sample is the categorical over the twenty drawn kinds, exactly as before, so it returns the same index from the same stream and every draw is unchanged. Its log_prob scores a drawn kind as before and a player kind at PLAYER_OP_MASS (0.005, the weight of the grammar’s other two kinds a player puts in place). The extra mass leaves the scorer unnormalized, which is harmless: a walk holds every player kind’s #op, so the term is the same constant in every ratio it takes. N_OPS, which the refinement budget scales with, still counts the twenty drawn kinds.

A TRACK or CAPTURE whose input chain holds an AUDIO IN scores finite too: SourceKind does for that AUDIO IN what OpKind does for the TRACK.

What is not in the grammar

Feedback. Terms are acyclic: there are no feedback combinator productions. Modules with internal feedback (delay, chorus, reverb) are fine, and there are plenty of them.

This is a v1 constraint rather than a principle. A tamed feedback production, with a mandatory attenuator and limiter in the loop path, is the intended v2 grammar extension. Until then cycles are unrepresentable, which is why cable dragging in the UI does not offer them.

Strict validation as an oracle

Grammar output is compiled with quiver’s ValidationMode::Strict in the test suite. Because the grammar is typed, a SignalMismatch is by construction a bug in the grammar, so Strict doubles as a property-test oracle: sample $N$ terms, compile all of them, and any error fails the test with quiver’s actionable message.

Patches are wired in Warn mode, though, with an allowlist test pinning the warning classes. Strict rejects warning-class pairings the compiler uses on purpose, the clearest being a constant bipolar Offset feeding a unipolar knob. The allowlist test (every_prior_sample_compiles) names each class with its reason, which keeps a known exception from quietly becoming a habit of ignoring warnings.

Where this comes from

The design mirrors fugue-evo’s ArithmeticGrammarPrior, with quiver signal sorts in place of arithmetic types. That is deliberate: fugue-evo’s subtree mutation and reversible-jump MH apply to this genome unchanged, because they operate on traces and this genome’s trace encoding is faithful. Auracle uses that MH. It does not use crossover, since every child grows from one seed (walk.rs), and it does not use fugue-evo’s tempered SMC.

Parameter sites and their domains

Every continuous knob in the genome is a draw from $\mathrm{Uniform}(0,1)$. The musical meaning is the compiler’s job.

One domain, everywhere

pub const PARAM_DOMAIN: std::ops::Range<f64> = 0.0..1.0;
pub const PARAM_MAX: f64 = 1.0 - f64::EPSILON;

pub fn in_domain(v: f64) -> bool {
    v.is_finite() && PARAM_DOMAIN.contains(&v)
}

Every continuous site is normalized to $[0,1)$ and the mapping to Hz, seconds, dB, or cents happens in the compiler. Half-open, because that is what $\mathrm{Uniform}(0,1)$ is: fugue’s log_prob is $-\infty$ at $x \ge 1$. The domain used to be 0.0..=1.0, which made exactly 1.0 legal here and impossible under the prior: a knob dragged to its stop, two shipped presets, and the default vibrato insert all had $\log p = -\infty$, so init_from refused them and ⚡ evolve silently did nothing. Every clamp in the crate now lands on PARAM_MAX, never on 1.0, and it is one f64::EPSILON below rather than the next float down so that a JSON round trip cannot put it back on the boundary. No mapping in the compiler can hear the difference. Three things fall out of the shared domain:

• The prior is trivially correct. $\mathrm{Uniform}(0,1)$ at every site, with no per-parameter range table to get wrong.
• A proposal cannot leave the domain. MH moves are in normalized space.
• The panel can read in musical units (840 Hz, 24 ms, −6.0 dB, +12 ¢) while the genome stays uniform. The knob and the number under it are two representations of the same site.

Note that in_domain requires finite: NaN compares false against every bound, and an infinity is exactly the runaway the gate exists to stop.

Bounded by the mapping

Because the mapping is the compiler’s, the musically dangerous regions are excluded by how $[0,1]$ is spent rather than by a downstream guard. Filter resonance maps to a range that stops short of self-oscillation; delay feedback stops short of 1; V/Oct maps into an audible band.

So the grammar cannot express the most degenerate settings at all, which leaves no pathological region for the search to keep sampling and be penalized for.

It is not a substitute for vetting, which catches pathology that arises from composition: a bounded resonant filter fed by a bounded distortion fed by a bounded fold can still scream.

Latent sites

Not every continuous site is heard. A step sequencer (ModNode::Steps, see the grammar) always carries eight step values #s0 … #s7, and #slen decides how many of them play. The rest are latent: in the trace, in the domain, drawn from the prior, and moved by MH like any other site, but inert until a longer #slen reveals them.

That is deliberate, and it costs nothing the search has to pay for. A proposal on a latent step changes neither the sound nor $\varphi$, so the tempered target accepts it as a neutral move (drift, not selection: nothing about taste has acted on it yet), and the value it leaves behind is what a later #slen proposal reveals. Shrinking a pattern never throws a step away, and growing it again brings back the step that was there.

Discrete sites

Categoricals, each with a named domain, and all uniform but the octave:

The octave is weighted for the speakers a patch is heard on. A patch’s register comes almost entirely from its lowest oscillator. Drawn uniformly, 30.5% of a fresh bank put most of its energy at C4 below 200 Hz, and 17.5% put under a fifth of it in 200 Hz–5 kHz, the band a laptop’s speakers reproduce: sounds a laptop barely plays. With the weights, the same five fresh loads of the app’s pool (200 patches, measured by auracle-wasm’s pool_loudness example) hold 21.5% and 8.5%. Most of what is still below 200 Hz has its lowest oscillator at −1: a patch with two oscillators has one at −1 or lower more than a third of the time.

Octave 0 is the common draw and the lowest the rarest. The edges keep a weight above zero: at zero, a preset or a saved patch with an oscillator at −2 or +2 would score $\log p = -\infty$, and refinement would refuse to start from it.

Plus the structural categoricals (#src, #op, #mod, #modop, #pairop), whose orders are the persisted wire format and therefore append-only.

Enumerating the sites

domain_violations() returns every out-of-domain continuous site as (address, value), in address order. It reads the trace, not the term:

self.to_trace().choices.iter().filter_map(|(a, c)| match c.value {
    ChoiceValue::F64(v) if !in_domain(v) => Some((a.to_string(), v)),
    _ => None,
})

The trace enumerates exactly the continuous sites, by construction, from the same walk the prior samples. A hand-written match over the productions would be a second table of “which fields are knobs”, and the first module somebody forgot to add to it would be the one the next bad value escaped through.

This is the address scheme paying for itself: there is one enumeration of the genome’s sites, and it is the one inference uses.

Repair, not refusal

clamp_domains() pulls every out-of-domain site back in and returns how many it fixed. NaN goes to the domain’s midpoint; anything else is clamped, with 1.0 and above landing on PARAM_MAX. It runs on every session load, which is what mends a save written by a build that still let a knob rest on the stop.

It is half of normalize_tree(), the normal form every tree is put in once, on its way in: a session's bank on load, a held sound brought back, an opened patch file, and a whole tree the panel posts. The other half folds a modulation term the grammar would fold (ModNode::normalized): a shaper over nothing is nothing, a pair with an empty side is its other side, and a one-parameter shaper's unused second parameter is 0. Every structural edit ends in both, though an edit that grafted a subtree once brought its modulation in unfolded, which is how a saved session or a patch file came to hold such a term. A term left unfolded was rewritten by the next edit instead, and on such a patch every module the guess could add also took the folded one away, so the guess said the patch was full. The compiler builds each such term as its folded form, so the fold changes no sound: it takes off the rack a module that did nothing. That is why a restore says so when it clamps a knob and not when it folds a term.

The asymmetry with the size ceilings is deliberate:

Repair wins for parameters on product grounds: a saved session that already contains a bad value must not become an app the player cannot edit, load, or evolve their way out of. Corruption must not be load-bearing.

The sentinel incident

The gates above are not hypothetical. A shipped session contained amp.sustain = 1e30, an out-of-domain sentinel that had escaped into the genome and then into the observation log.

What one bad cell did:

1. The value rendered fine. The limiter bounds the output, so the audio was unremarkable and vetting passed it. The vet gate is a gate on the sound, not on the term.
2. Its $\varphi$ entered the observation log, with amp_sustain $= 10^{30}$.
3. The standardizer fit on that column produced a mean of $\approx 1.2 \times 10^{29}$ and an SD of $\approx 5.5 \times 10^{29}$, which standardized every real patch in the pool to $-0.2 \pm 10^{-30}$.
4. The coordinate was dead. The model could never learn from it again, and the belief line still printed a contribution for it.
5. The panel read SUSTAIN 1200.0 dB, and the HELD tray printed 1e+30.

The fixes are at three layers:

• clamp_domains on load, which repairs the corruption that exists.
• FeaturizeError::OutOfDomain, which refuses to measure a term whose φ would be a lie, before spending the render. This is the gate that keeps the log clean; every row in the log came through it.
• Runaway-column detection in the standardizer, so the next escape costs a coordinate’s precision rather than the coordinate.

Layers 1 and 2 should make layer 3 unnecessary. It exists anyway, because the value got through everything that was supposed to stop it.

Budgets

Separately from domains, the search is bounded in size:

The app shows a ceiling once a patch is one step from it, in the form 23/24 modules, and all three (8/24 modules · 4/6 depth · 1/3 mod depth) with Show measurements on. A hand-built patch past a ceiling is refused, and one at a ceiling has no room to grow, which is a common reason a generation reports that every walk came back unchanged. See the validity gate for why the two depth ceilings are derived from the prior rather than set above it.

Structural edits

Hand edits and search proposals walk the same lattice, which is what makes the workbench trustworthy.

The vocabulary

Because the genome is a typed tree, rewiring is a small closed set of operations that are type-safe by construction: an LFO can never end up in an audio slot, and a filter always has exactly one audio input.

Nodes are addressed by trace key: node, node/0, node/0/1, node/0/m.

The *Tree variants exist for the wiring gestures: “plug this staged chain in here”. Callers park the displaced subtree client-side, which is what the SET ASIDE tray is.

What a splice keeps

Insert and a processor Replace place the kind’s default module, and they seat the chain with the same splice InsertTree uses. The chain becomes the new module’s primary input, /0: the old subtree for Insert, the old node’s own primary input for Replace (the old node itself, when it was a source). On the two-input modules that is a mix’s or ring mod’s a, the in of a compressor, ducker or gate, and a vocoder’s carrier, the one branch whose waveform reaches the output. A Replace drops the old node itself and its /1, and nothing else. The default module brings its own second branch:

So a vocoder placed on a chain makes that chain speak. The Vox Machina preset is built the same way: a supersaw stack as the carrier, a formant voice as the modulator. Until October 2026 Insert and Replace built the vocoder with a supersaw carrier of its own and dropped the chain they landed on. The app was never affected: it never sends Insert or Replace. Its structural edits are insert_tree, replace_tree, set_mod_tree, set_mod, swap_mix and delete, and its other wiring gestures post the whole rewired tree.

Wrap versus replace

The distinction shows up twice and is the same idea both times:

• Replace on a source with a processor kind wraps the source rather than deleting it, because a processor needs an input and the obvious one is what was already there.
• SetMod with a shaper kind wraps the existing modulation term rather than evicting it, which is what makes s&h rand → quantize → slew a three-click build.

The socket in the UI says which of fill / replace / wrap it is about to do, so the choice is never implicit.

Hand edits and MH proposals share one lattice

The search does not call these operations. A walk’s structural move is fugue’s single-site MH on the trace: it redraws one structural site (#leaf, #src, #op or #mod) and draws from the prior whatever the new choice needs, keeping every site whose address survives. What hand edits and the search share is the state space and the address scheme: both produce terms of one grammar, under ceilings that end where the prior’s support does.

Consequences:

• Anything a player can build by hand, the search can score and walk from, because it is inside the prior’s support. Anything the search produces, a player can edit.
• A structural edit cannot produce a term the search would consider invalid, because validity is one predicate.
• ⚡ evolve from this on a hand-built patch is not a special case.

Parameter edits

Separately, edit::set_param(tree, addr, value) writes one continuous or discrete site by address. This is what a knob drag is: a one-site write, then a re-render and re-vet before the result can be auditioned.

The validity gate

validate_tree is the predicate every edit result must satisfy, and it is what the structural-edit gate test exercises.

Hard ceilings on hand-built patches:

pub const MAX_SIZE: usize = 24;                            // modules
pub const MAX_DEPTH: usize = PRIOR_MAX_DEPTH + 1;          // audio tree depth: 6
pub const MAX_MOD_DEPTH: usize = PRIOR_MAX_MOD_DEPTH + 1;  // modulation nesting: 3

MAX_SIZE protects the realtime voice and the feature pipeline. The two depth ceilings are derived from the prior’s support, and that is a correction: they used to be 9 and 4 against a prior whose max_depth is 5 and max_mod_depth is 2, on the reasoning that a person stacking modules by hand knows what they are building and the ceiling only protects the voice. What that reasoning missed is that the prior forces #leaf at max_depth and zeroes Op/Pair at max_mod_depth, so the deepest term it can score has depth max_depth + 1. A hand edit past that had $\log p = -\infty$, EvolutionChain::init_from returned None, and ⚡ evolve on the patch did nothing and said nothing: the very failure the grammar gives Silence non-zero weight to prevent. Now the ceiling is the support, stated once in prior.rs and read from there.

A session saved under the old ceilings may hold a deeper tree. It still loads and plays (no load path re-checks the ceilings, because corruption must not be load-bearing), but refinement reports it as outside_support rather than pretending to walk, and a structural edit that leaves it over the ceiling is refused until one brings it under.

MAX_MOD_DEPTH stops well short of the audio ceiling for a concrete reason: a Pair branches, so depth 3 is up to eight leaves on one cable, and each is another level of the compiler’s by-value recursion stacked on top of the audio tree’s. That is a stack-depth argument rather than an aesthetic one; see the wasm stack note.

The gate test

The structural-edit suite is a gate rather than a set of unit assertions:

Apply every operation at every node of randomly generated trees, and require the result to stay compilable.

This catches the class of bug that unit tests miss: an operation that is individually correct but produces an invalid term in combination with a particular tree shape. The codebase leans on gates like this generally; the preference is stated in CONTRIBUTING.md: prefer extending a gate over asserting implementation details.

Naming stability

NodeKind serializes as snake_case, and that string is also what describe::RackModule::kind reports and what the frontend keys its module list off.

RingMod is renamed by hand, because the derived spelling would be ring_mod while the module is ringmod everywhere else, and one module with two spellings is a defect waiting for a caller.

Silence is silence on both sides, and it is the one kind in the vocabulary nobody shops for: Replace { kind: silence } is how an edit unplugs a socket. The app’s unplug, extract, and cable-move gestures leave the same leaf (as {"Silence":{}} in the tree they post), the rack describes it as kind silence titled empty, and it renders nothing. It used to be unreachable by hand, so the app stood a saw VCO in an unplugged socket and drew the EMPTY plate over it; the plate said “nothing here” while the saw played, and φ measured the saw. As a source kind it can be neither inserted into a wire nor wrap anything.

Node identity

Nodes carry a Uid assigned on the way into the pool. This is what makes the rack’s hand positions and locks survive a structural edit. Without them a node is its position, so any structural change wipes the locks and destroys the hand-build → pin → breed loop the editor exists to serve.

A node is a thing with an identity that has a position, not a position that has contents.

Compilation to a patch

Term → quiver `Patch`. One path, used by both the search and the live instrument.

auracle_grammar::compile is the largest single module in the workspace, and its job is narrow: turn a PatchTree into a playable quiver patch graph, with handles for every live parameter.

The mandatory output chain

Every compiled voice ends the same way, and none of it is optional:

$$\langle\text{audio}\rangle \to \text{DC blocker} \to \text{VCA (amp ADSR)} \to \text{Limiter} \to \text{StereoOutput}$$

Plus two external controls (pitch in V/Oct and gate in volts) fanned out to every pitched source and every envelope.

No evolved patch can bypass the limiter or end up unplayable. That is safety layer 3, and it is enforced by the compiler emitting the chain, not by asking the grammar not to.

The tail is built once per channel, so a subtree that produces true stereo (reverb, chorus) keeps both tanks all the way to the output rather than having the right one discarded on the way to a mono sum.

Parameter mapping

The compiler owns the musical meaning of every normalized $[0,1]$ site, and the ranges are deliberately bounded away from pathology:

So the grammar cannot express self-oscillating resonance or a runaway delay. This is the same argument as parameter domains, one layer down: excluding a region is better than generating it and rejecting it.

Two details worth knowing when reading the code:

• Some quiver inputs are gates, not amounts. Adsr.shape, Vca.response, and Limiter.soft are read at a 2.5 V threshold, so 5 V and 10 V do the same thing. The compiler uses named constants GATE_TRUE = 5.0 / GATE_FALSE = 0.0 rather than bare numbers, because “5.0” at one of those ports does not mean what it looks like.
• Filter keytracking is fixed at 0.5. quiver applies $2^{v \cdot a}$, so 0.5 moves the corner half an octave per octave played: enough that a patch still speaks two octaves above where it was dialed in, which is what the audition phrase’s C5 stab measures.

The DC blocker, and makes_dc

The output chain includes a DC blocker, and the compiler decides whether it is needed by walking the term:

fn makes_dc(node: &AudioNode) -> bool {
    match node {
        AudioNode::Filter { kind, input, .. } =>
            matches!(kind, FilterKind::Ladder) || makes_dc(input),
        AudioNode::Distortion { mode, input, .. } =>
            matches!(mode, DriveMode::Tube) || makes_dc(input),
        AudioNode::Mix { a, b, .. } | AudioNode::RingMod { a, b, .. } =>
            makes_dc(a) || makes_dc(b),
        // sources produce none; dynamics inherit from their audio input
        …
    }
}

Two productions generate a DC offset (the ladder filter and tube-mode distortion), and it propagates up through anything downstream of them. An AudioIn always pays for the blocker: a host input can carry an offset of its own, and so does a Capture, whose take was recorded from one. A Track pays for it only if the branch it plays does.

Without the blocker, a tube-drive patch measures 1–8% DC as a fraction of RMS. That is nowhere near the vet gate’s 0.6 limit, which is the point worth recording: the vet gate was never what protected the feature extractor from that offset. The blocker was.

Validation mode

Patches are wired under ValidationMode::Warn, not Strict.

quiver’s Strict rejects warning-class pairings, and this compiler uses several of them on purpose, for example:

• a unipolar modulation envelope driving a bipolar FM input;
• a constant bipolar Offset feeding a unipolar knob.

The type discipline Strict would enforce is already guaranteed by construction: the term’s Audio/Mod sorts are Rust types, and the compiler only emits known-good connection shapes.

Compile errors (invalid ports, cycles) remain hard failures. Accumulated warnings are returned for inspection, and a property test (every_prior_sample_compiles) asserts they stay within an allowlist that names each class with its reason. That test keeps a known exception from drifting into a habit of ignoring warnings.

Separately, the grammar’s output is compiled under Strict in the test suite, where a SignalMismatch is by construction a bug in the grammar and therefore a useful oracle. Two different modes for two different questions.

Live parameter handles

Compilation returns a ParamMap: address → ParamHandle, each wrapping an AtomicF64 the audio thread reads.

This is what makes knob turns free. Turning a knob writes the atomic, so the running voices change on the next block with no recompile, and writes the genome at the same address. Both, always; see Trace addresses.

Structural changes do require a recompile, and so do the handful of parameters that feed compile-time decisions.

Taps, and the level on each cable

Compilation also records each term node's tap: the quiver port its audio leaves by (CompiledVoice::taps, keyed by the node's trace key). A term is a tree, so each module's output feeds exactly one parent, and its tap carries exactly what the cable from that module carries. Two readers use them, and both read in the same scale, dB re 1 V of the raw port value (quiver's calculate_rms_db), so PATCH maps a level to light one way:

• The live meter. While notes sound, LivePoly::set_meter subscribes to every tap, read on one voice, the newest one sounding, and each tap's RMS reaches the page as quiver's level windows fill. It needs no recompile and costs nothing when off.
• The cable probe, for a patch at rest (auracle_features::probe_cables, WasmEngine::edit_cable_levels in wasm, the worker's cable_levels message). It renders the audition phrase once and reads every audio cable after every tick of the main voice, through the routing slot its tap resolves to, keeping each cable's RMS and peak over the whole phrase, gaps included. A cable that carries nothing reads PROBE_FLOOR_DB (−120 dB).

The probe's cables are the rack's: one per audio wire of describe, in its order, with the from and to module keys PATCH draws a cable by and both modules' uids, which PATCH's cable identity is made of. Modulation cables are not measured, because the compiler taps audio nodes only, and PATCH draws a modulation cable by its rate. Chord voices are not measured either: the levels are the voice that plays every note of the phrase, as the live meter's are one voice.

The probe writes nothing: it reads each port's last value and leaves the patch alone, so a render it watches is the plain render, bit for bit. All 62 presets render identically with and without it (crates/auracle-features/examples/cable_probe.rs), and the test suite holds every fourth preset to that. It is not φ, and nothing it reads reaches the featurizer.

Its cost is one render of the phrase. Natively, a probed render took a median 0.99 times a plain one over the 62 presets (162 ms against 165 ms of CPU, on a shared machine, so the reads are lost in the noise); in wasm under node it took a median 160 to 206 ms over two runs, against 183 to 238 ms for a render with φ (crates/auracle-wasm/examples/cable_cost.mjs). That is not a per-block cost, so the probe runs once an edit has settled, in the worker's later lane, and the live meter covers the patch while notes sound.

How PATCH uses it

PATCH (apps/web/patch.js) asks for the probe once the bench has settled after an open or an edit (nothing in the edit lane, nothing opening, no knob held, about half a second after an edit's reply and a little over a second after an open or PATCH coming into view, so the next click is not kept waiting behind a render), and only while PATCH is in sight; a knob turned during a drag asks once, after the drag. A reply measured on a tree the bench has since left is dropped and asked again. With the levels in hand, each audio cable at rest:

• carries light by its level, mapped as the live meter maps one: −54 dB re 1 V and below is unlit, 0 dB full, linear between (paintWireLevel's stroke opacity, eased over --d-state);
• wears a level mark on its middle that lights one bar per third of that range, with the level as its tooltip.

Until a structure has been measured, its cables are unlit and its marks hollow: the rack used to draw an estimate here (each cable's share of the output through the mixers above it, every source at unity), which is not a measurement and is not drawn on the workbench any more. After a knob turn the marks stay hollow until the change has been measured. Modulation cables carry no light and no mark. The pictures of other patches (EVOLVE's pair) still draw the estimate; they have no probe.

One compiler, two callers

• The search compiles a term to render and measure it.
• LivePoly compiles the same term, through the same function, to play it: $N$ copies for $N$ voices, limiter included.

So what the player hears under their fingers is the patch that was evolved, vetted, and featurized. There is no separate “playback engine” that could disagree with the one the model learned from.

Cost

The compiler is recursive and builds by value: every level of Compiler::build constructs quiver modules before moving them into the patch, and some of those carry large inline buffers. A PitchShifter holds [f64; 4800], which is 38 KB, and a Granular holds more.

On a native main thread this is invisible. On wasm32, whose default stack is 1 MB, a dozen-module patch overflows it, and it does so as memory access out of bounds, nowhere near the flag that caused it. See the stack size for the fix and why it lives in the Makefile.

The standard phrase

Audio features are only comparable under an identical stimulus. This module owns that stimulus.

The spec

PhraseSpec::default() is four notes, 5.05 s in all, at 44,100 Hz, with the random seed 0xE05_F00D:

Pitches are V/Oct offsets from C4. The seed is installed into quiver’s thread-local RNG before rendering, so noise and analog drift are bit-reproducible: a patch’s features are the same every time it is measured.

Why each segment

The original phrase was three short notes (0.6 s stab, 0.25 s stab, 0.8 s low note), and it was the loop’s weakest link. It could not discriminate

• slow pads: a 2-second attack was silent for most of the stimulus,
• anything modulated below ~1 Hz: no register-constant segment long enough to hold a modulation cycle,
• anything above Eb4, its highest note,
• how a patch stacks polyphonically: it was strictly monophonic.

So the grammar could express patches the audition could never reveal, and the taste model was being asked to learn preferences over evidence that was not in $\varphi$. No amount of model improvement fixes that; it is a measurement problem.

The v2 default covers each hole with the cheapest segment that reveals it:

1. C4 held 1.8 s. The attack measurement window (onset → next onset) is now 2.0 s rather than 0.75 s, and the sustain is long enough that sub-Hz modulation completes most of a cycle. held_centroid_std is measured here specifically, which is what makes it register-constant by construction.
2. C5 stab. One octave above the old ceiling. With the compiler’s fixed 0.5 keytracking, this is where dark patches reveal whether they speak up high (high_ratio).
3. C4+E4 dyad. A second compiled voice, gate-synced with the main voice, reveals intermodulation (chord_flatness_delta). A dyad rather than a triad because render cost is per voice-second and pairwise intermodulation is the first-order phenomenon.
4. C3 with a 1.1 s release window, kept last. Bass register, and its position matters: the tail measurement is the final 300 ms, so putting this note last is what makes the tail see release length and reverb rather than a truncated chord decay.

Cost: about 2× the v1 render, measured. The dyad’s second voice is the difference between wall seconds and rendered voice-seconds.

Chord voices

Note::chord carries additional simultaneous pitches, each rendered by its own compiled voice, gate-synced with the main note.

Two behaviors worth knowing:

• Chord voices start cold at the note’s onset, exactly how live voice allocation behaves, so the measurement matches what a player would hear.
• After the shared gate closes they keep ticking until their own output parks on silence. A truncated release tail is a broadband click, and a click would poison every spectral feature in the frame it lands in.

max_voices() reports the largest simultaneous count (2 for the default spec), and the vet gate’s peak ceiling scales with it.

The :p2 stimulus tag

Every audio feature name carries a generation tag:

centroid_mean:p2   rms_std:p2   attack_s:p2   …

This is the migration mechanism, not a version comment.

A stimulus change changes what every audio value means, even when the formula is untouched. A slow pad’s rms_mean under a phrase that never lets it open is a different quantity from the same field under one that does. The observation log stores raw $\varphi$ by name, and FitSet::build projects old logs onto the current names on the rule same name ⇒ same coordinate.

So tagging the name with the stimulus generation means votes recorded under the v1 phrase:

• keep their structural coordinates, which are stimulus-independent;
• have their old-stimulus audio coordinates imputed as “no evidence” rather than mixed into a standardizer they were never commensurable with.

Bump the tag whenever PhraseSpec::default() changes audibly. Failing to bump it is worse than a wrong number: it is old evidence presented as current evidence.

What the phrase still does not reveal

Stated because the model cannot learn what the stimulus does not show:

• Velocity response. The phrase plays at one velocity.
• Fast passages. No segment tests how the patch behaves in a run.
• Long-term behavior. Five seconds cannot reveal a 30-second evolving pad.
• Stereo width. The render is summed to mono for feature extraction, and there is no width coordinate in $\varphi$ at all. The chorus module’s spec card says so outright in the app.

The intended direction is per-style audition phrases (a discovered bass style picks a bassline, a pad style picks a chord swell), which would make the stimulus adaptive rather than fixed. That is a design note, not shipped code, and the :p2 tag is the mechanism that would let it happen without invalidating history.

Audition clips

A live input is neither fixed nor repeatable, so it cannot be measured as it is. A patch with an AUDIO IN is measured with an audition clip instead, and the clip is part of the stimulus.

A patch that reads the player’s input (an AudioIn anywhere in its term, PatchTree::listens) would otherwise be rated on whatever the room sounded like when it was rendered. Taste would chase the room. So every AUDIO IN in a measurement render reads an audition clip: its input slot’s own, a capture of what the player plays into that input, if it has one, else the clip every slot hears, which is a built-in reference signal unless a session saved before slots had clips of their own brought back its one capture (RFC-008, part 2). The features, the vet, the walks and the render farm all render with it, so a patch that listens is measured, rated and bred like any other.

What a clip is

AuditionClip (auracle-features, clip.rs):

• one or two channels, at the phrase’s sample rate;
• at most MAX_CLIP_SECONDS (8 s) long;
• quantized to 16 bits when it is made, so the engine measures exactly the samples it saves and a reload measures the same $\varphi$;
• named by a content id: FNV-1a 128 over its rate, channel count and samples.

A capture becomes a clip through AuditionClip::from_interleaved. It is resampled linearly to the phrase’s rate (a browser captures at 48 kHz, the phrase renders at 44.1 kHz) and cut to the phrase’s length, since nothing past the phrase is ever read. Two captures are refused rather than repaired: one holding a sample that is not a number, and one that is silent (below the vet’s silence floor, an RMS of $10^{-4}$), because every patch that listens would fail the vet over it.

The clip rides inside the stimulus, as PhraseSpec::clip. None means the reference. An input slot can have a clip of its own, in PhraseSpec::clips, which an AUDIO IN on that slot reads in its place (PhraseSpec::slot_clip). A spec without a clip serializes exactly as it did before clips existed, which is what keeps every existing cache key and fingerprint where it was.

The reference signal

auracle_features::reference builds it from the phrase’s rate and length. It is a plucked figure: fourteen notes over four and a half seconds, in A minor pentatonic from A2 to E4, then a rest.

It has to exercise what a patch does to an input, and each property is there for a reason:

• Pitched. Every note is a harmonic stack, so a filter, a wavefolder, a pitch shifter or a vocoder has partials to work on.
• Transients. A pluck has fallen at least 27 dB by the next note, and a longer note 19 dB, so every onset is a rise a follower, a compressor, a gate or a ducker can react to, and a delay has onsets to repeat.
• Broadband. The picks are white noise across the whole band and the stacks reach up to 10 kHz, so a lowpass on the input moves the spectral centroid.
• Space around it. Every note has died away before the phrase’s last 300 ms, the window tail_ratio is measured in.

It is deterministic: integer sample indices, libm’s sine and exponential (pure Rust, so the native build and the wasm build compute the same samples), a fixed xorshift for the picks, and the same 16-bit quantization a capture gets. It is built once per rate and length and shared.

Being mono, it makes an AUDIO IN’s channel knob inaudible to the model. A stereo capture is where that knob is heard.

examples/audio_in.rs measures eight patches built around an input through it: a lowpass on the input lowers the centroid (0.63 to 0.38) and a highpass raises it (to 0.74); hard drive lowers the crest factor (2.69 to 1.56); a reverb smears the plucks (crest 2.04, centroid movement halved); the input keying a ducker sets a supersaw pumping (motion_mid −2.54 to −0.90); and the input as a vocoder’s modulator moves the supersaw’s spectrum. A reverb does not lengthen the tail: every effect sits before the voice’s amp envelope, so the tail ends with the amp’s release, for this patch as for any.

Rendering on the host’s clock

render_phrase gives a patch that listens one quiver AudioInputStream for each input slot it reads, for the whole render, built with with_host_clock; slots that hear the same clip share one stream. The whole clip is written once, as one block, and the render calls advance() after each frame’s tick of every voice, never tick_block. That is quiver’s rule for a frame-by-frame host, and it is what keeps the chord voices in step: a chord voice is compiled at its note’s onset, mid-render, and on the host’s clock its AUDIO IN reads the frame every other voice is reading from its first tick. (On a cursor-mode stream a voice built mid-block would be silent until the next block, and a render has only one.) The test renders a dyad over a clip that is silent until the dyad and a tone after it, and the dyad’s render is the mono render doubled, bit for bit.

A patch that does not listen has no stream to keep in step, and its render ticks each voice in blocks of 64 frames (tick_block): the same samples, bit for bit, at about two thirds of the CPU. Its chord voice still ticks frame by frame beside the main voice while it rings if it follows a TRACK, or if its sources draw quiver’s shared random stream (noise, a plucked string), whose draws come in tick order across the voices.

Frame $n$ of the render reads frame $n$ of the clip: a clip shorter than the phrase falls silent at its end.

A patch that does not listen gets no stream at all, so its render, and every row cached from it, is the same whatever clip the session holds.

The compiler binds the streams: compile_with_input (and compile_for_render, the same voice with its knobs folded, which a measurement render uses) builds each AUDIO IN in the patch on the stream it is given for that AUDIO IN’s slot (InputStreams), a slot it is given none for on a stream nothing writes (silent), and compile builds them all so, which is the same voice for any patch that does not listen. The live instrument, LivePoly, binds its own stream to every slot (InputStreams::every): quiver’s cursor mode, built once in LivePoly::new, which the worklet calls in its port handler and never in process(), and which every voice it rebuilds shares. The worklet writes each quantum’s input through input_ptr and write_input, with no allocation, and a quantum with no write is silent. It writes only while the player monitors (MONITOR on the AUDIO IN module); otherwise the live input is silent and only the module’s meter reads it.

Every patch ends in its amp envelope, gated by the keys, so a live patch that listens would be silent with no key down. LivePoly builds such a patch one voice longer (LivePoly::set_open): with monitoring on, that open voice is held at C4 (0 V, OPEN_NOTE) at full velocity, outside the keys’ allocation, so the input sounds through the whole patch, amp envelope included. Every voice reads the one stream, so a key held over the open voice adds a second copy of the input while it sounds, as a chord voice in the phrase does.

Cache keys

Two clips never share a cached row, and a new clip costs no row it does not have to.

• render_key is unchanged for a patch that does not listen. For one that does, when every slot it reads hears one clip, a 0xfe separator and the clip’s content id (the reference’s when the spec has none) follow the spec. When its slots hear different clips, each slot it reads follows instead, in order, as a 0xfd separator, the slot and its clip’s id. A clip on a slot the patch does not read moves nothing. The clip’s samples are never hashed per key: the id already is their hash.
• cache_namespace never sees the clip. The farm’s store is stamped with its namespace and cleared when the stamp changes, so a clip there would throw away every cached render each time a player captured one.
• The farm’s stored key, "<namespace>/<render_key>", therefore carries the clip for exactly the patches that listen.
• PERFORM’s wiring key (wireKey in perform.js) appends the clips to the key of a sound with an AUDIO IN, and to no other, named as render_key names them (clipKey in clips.js): the one clip’s id when every input the sound reads hears it, which is the key such a sound had before an input could have a clip of its own, and otherwise each input it reads with its clip’s id, in order (0:<id>+1:<id>).

Walks and the farm

A walk renders with the clip because WalkContext.phrase carries it, and the context goes with every walk job (farm_walk reuses its parsed copy while the text matches). A farm worker’s fill and restore renders use the clip because the phrase handshake carries it, parsed once per worker rather than once per render: a phrase with a clip is about 600 KB of JSON.

The handshake is sent when the farm starts, which is before a staged restore installs the session’s saved clip. So after a capture, or a restore with a clip, the farm can be a phrase behind, and its render of a patch that listens carries the old clip’s key:

• A fill draw that listens is admitted only on the session’s own key. pre_featurized refuses the stale result, and Engine::absorb_prior measures the draw itself, on the session’s clips, as the serial fill would. It does the same when the farm sent no result for a listener, since the old clip may be why it failed the vet. A draw that does not listen keys no clip and is taken as sent.
• A restore’s entry is refused by bank_absorb, and the worker measures it with bank_render.

The pool is right either way, but each such patch costs a serial render. So the engine worker sends the handshake again (farmResendPhrase in worker.js): to the crew standing whenever a capture is taken, and in a staged restore right after the import installs a captured clip on any input, before the bank’s first render goes out. The phrase carries every input’s clip, so one handshake brings the farm every one of them. A crew raised later is handed the current phrase when it starts.

Capturing a clip

The web app captures a clip of each input the player plays into (audio-in.js), and each becomes that input slot’s own:

• On an input’s first listen. When an input a sound on the bench reads, or one lent to a recording (a CAPTURE’s RECORD, or RECORD AGAIN on a sound kept safe, lend), first carries a signal (over −50 dBFS RMS, CLIP_SIGNAL_DB) while no clip has been captured from that input (the engine hears it through the reference, or through the one clip of a session saved before inputs had their own, below), it records CLIP_SECONDS (6 s) of it, before the patch, at the browser’s rate. Each input waits for its own signal, so a patch reading two inputs has each captured when it is first played. The engine cuts a capture to the phrase (about 5.05 s), so the capture leaves room over it; a mono input is sent as one channel.
• On NEW CLIP, whatever the input holds: a module’s NEW CLIP captures the input that module reads, whether the keys read it or its meter only.
• It is sent to the engine worker as set_input_clip with the input’s slot, which calls WasmEngine::set_input_clip. The reply carries the engine’s sentence, which the app shows, what it measured again (only the pool’s members that read that input), and which clip every input now hears (clips, from input_clip), as the worker’s ready and a restore carry it.

The app never sets the clip every input hears (set_audition_clip): a capture of one input is that input’s own, not another’s. So in a new session an input that has not been listened to is heard through the reference, and the clip every input hears is the reference, unless a session saved before inputs had clips of their own brought its one clip back. Such a session’s inputs all hear that clip until each has its own. Since the app never sets it, a captured clip that every input hears is always such a session’s, and an input heard through it has no clip captured from it: its first listen captures it (clips.js’s firstListen compares the input’s clip with the one every input hears, clip on ready and a restore’s audition_clip). Nothing tells which input the old clip came from, so that input is captured again too, at the cost of one capture and of measuring again the sounds that read it, in the background. An input with a clip of its own, captured in this session or restored as its own, is left alone.

A silent capture is refused (see above) and changes nothing; the app shows the engine’s sentence and does not capture that input again by itself.

Stored with the session

The clip is saved in SessionState.audition_clip, in its saved form:

{"format":"s16le-base64","sample_rate":44100.0,"channels":1,
 "frames":222703,"data":"…","source":"captured"}

Interleaved 16-bit little-endian samples in base64: about 600 KB of text for five seconds of mono. The reference is never saved; no clip means the reference. The slots’ own clips are saved beside it in SessionState.audition_clips, an object from the slot ("0" to "7") to the same form: one per slot at most, and a slot whose clip is the one every slot hears is not written, so the file holds at most nine clips.

A saved clip is untrusted input, and AuditionClip::from_saved holds it to the bound quiver’s Capture uses for its saved take:

• the format tag must be s16le-base64;
• the rate must be finite, positive and at most 192 kHz (MAX_CLIP_RATE);
• one or two channels;
• at most MAX_CLIP_SECONDS at its own rate;
• a frame count that agrees with the data, and the data’s length is checked before it is decoded, so nothing allocates beyond what the file’s own bytes occupy;
• and not silent.

The session holds the clip as raw JSON and checks it on the way in, so a clip that cannot be read costs the session its clip and nothing else. It is restored before the bank is measured. An unreadable one restores as the reference, and the clip’s status (Engine::audition_clip_status, the wasm binding audition_clip) says why, in unreadable. A slot’s own clip that cannot be read costs that slot alone, which hears the one every slot hears, and its status (Engine::slot_clip_status, the binding input_clip) says why. A session saved before slots had clips of their own restores its one clip on every slot.

Setting a clip (Engine::set_audition_clip) measures the pool’s members that listen again, and only them. A member that no longer vets under the new clip keeps the measurement it had and is reported as unmeasured: a clip change never deletes a patch. Observations already in the log keep the $\varphi$ they were logged with. Setting it also takes each slot’s own clip away. Setting one slot’s (Engine::set_slot_clip, the binding set_input_clip) measures again only the members that read that slot.

Breeding a patch that listens

AUDIO IN is a player kind (grammar): the prior never draws one, so no fill or walk deals an input, and it scores a player’s, so a listening patch is walked like any other. A walk renders every proposal with the session’s clips, because WalkContext.phrase carries them, and the farm’s walk (farm_walk) is handed the same context: a ⚡ or a generation from a listening seed lands the same child on the farm as on the engine, with the seed’s inputs held and any CAPTURE’s take carried through (crates/auracle-wasm’s a_listening_seed_evolves_on_the_farm_with_its_clip_and_take).

What is open

• One live input. LivePoly binds one input stream, so in the live voices every AUDIO IN reads the input of the patch’s first one; the app opens each other input for its module’s meter only, and says so. The model measures a patch that reads two inputs through each input’s own clip, so it rates the patch as it sounds with each input playing its own signal, which the live voices do not play yet.

Loudness normalization

Louder reliably wins A/B tests. Without normalization the model would learn a taste for loudness and present it as a preference about timbre.

Every render is normalized to −18 LUFS (TARGET_LUFS, in pipeline.rs) before audition and before feature extraction. Unnormalized loudness would poison $\theta$, and it would do so in a way that looks like a real result.

Why LUFS and not RMS

Because the confound is perceived loudness. K-weighting approximates the ear’s sensitivity (a high-shelf boost above ~1.7 kHz plus a ~38 Hz highpass), and 400 ms gated blocks keep silence and release tails from dragging the measurement down. Plain RMS would under-measure a bright patch and over-measure a bass-heavy one, and then the “loudness” the model learned about would be a spectral preference in disguise.

The implementation follows ITU-R BS.1770 (auracle_features::loudness).

K-weighting

Two biquads in direct form 1, derived parametrically from the BS.1770 analog prototype by the RBJ bilinear transform, the same approach pyloudnorm takes, so any sample rate works and the coefficients match the spec’s published 48 kHz values at 48 kHz.

Stage 1, the high shelf:

$$G = 3.999844\ \text{dB}, \quad Q = 0.707175, \quad f_c = 1681.974\ \text{Hz}$$

Stage 2, the highpass:

$$Q = 0.500327, \quad f_c = 38.1355\ \text{Hz}$$

With $k = \tan(\pi f_c / f_s)$, $V_H = 10^{G/20}$, and $V_B = V_H^{0.499667}$, the shelf’s coefficients are

$$a_0 = 1 + \tfrac{k}{Q} + k^2, \qquad b_0 = \frac{V_H + V_B \tfrac{k}{Q} + k^2}{a_0}, \qquad b_1 = \frac{2(k^2 - V_H)}{a_0}, \qquad b_2 = \frac{V_H - V_B \tfrac{k}{Q} + k^2}{a_0}$$

and the highpass is the standard RBJ form. Deriving rather than tabulating is what makes the measurement correct at 44,100 Hz, which is the rate the phrase renders at.

Block loudness and the two gates

Blocks are 400 ms with 75% overlap. Each block’s loudness is

$$L_j = -0.691 + 10 \log_{10}!\left(\frac{1}{N}\sum_{n} w[n]^2\right)$$

where $w$ is the K-weighted signal. The $-0.691$ dB offset is the spec’s calibration constant.

Then two gates, in order:

1. Absolute gate. Discard blocks with $L_j \le -70$ LUFS. If none survive, the signal is silent and the function returns None.
2. Relative gate. Compute the mean energy of the surviving blocks, and discard blocks more than 10 LU below it: $$\Gamma = -0.691 + 10\log_{10}!\big(\bar{E}_{\text{abs}}\big) - 10$$

The integrated loudness is the same expression over the twice-gated set:

$$L = -0.691 + 10 \log_{10}!\left(\frac{1}{|\mathcal{G}|}\sum_{j \in \mathcal{G}} 10^{(L_j + 0.691)/10}\right)$$

Note that gating averages in the energy domain, not the dB domain, which is why the implementation exponentiates each retained block loudness back before averaging rather than taking a mean of decibels.

The relative gate is what makes this robust for the phrase specifically: the phrase ends with 1.1 seconds of release tail by design, and a plain average would let that tail pull the measurement down and then be compensated for by a boost.

Applying the gain

let wanted_db   = (target_lufs - lufs).min(MAX_GAIN_DB);        // MAX_GAIN_DB = 30.0
let headroom_db = 20.0 * (PEAK_CEILING / peak_before).log10();  // PEAK_CEILING = 1.0
let gain_db     = wanted_db.min(headroom_db);
let gain        = 10f64.powf(gain_db / 20.0);

The boost is capped at +30 dB. A patch needing more than that is a vetting problem, not something to amplify, and vetting runs first, so in practice the cap is a backstop.

Loudness is a target; the peak is a limit

Matching integrated loudness says nothing about the peak, and crest factor spans tens of dB across this grammar: a pad and a pluck at the same LUFS are nowhere near the same peak. A pure loudness match therefore sends percussive patches over full scale, and it did. Measured over 150 vetted prior draws:

The two 22s are the same twenty-two patches, and the unmoved median is the check that this is a fault stop rather than a re-leveling of the pool.

This is not a matter of audio polish. Preference data is elicited on this exact buffer, so a clipped audition collects a pick about clipping rather than about the patch. That is the confound loudness normalization exists to remove, one stage later and silent. The live voice was never exposed to it; its master limiter has always held a 0.98 ceiling. The offline path took the volt divisor and not the limiter.

A smaller gain, not a limiter. A scalar keeps render_playback bit-identical by construction (the property its bit-identity test exists to protect), and cannot change timbre at all. A limiter would reshape the waveform, moving crest, flatness_mean, and flux_mean as well as the RMS pair, and would need a second copy of itself inside the replay path forever.

What it costs is on the record rather than hidden: the ~15% that reach the ceiling audition below target, so loudness matching degrades exactly where crest is highest. Quieter is a smaller bias on a preference judgment than clipped. Features::peak_reduction_db carries the amount, so a surface can say “pulled down 3 dB so it would not clip” instead of presenting a peak-limited patch as merely quiet.

make norm-peak reproduces the table.

The report carries lufs_before, gain_db, and peak_reduction_db, all of which survive into Features. They are diagnostics rather than model inputs: they are not coordinates of $\varphi$, because a sound’s level before normalization is exactly the information normalization exists to discard.

Where it sits in the pipeline

After vetting and before feature extraction:

$$\text{render} \to \text{vet} \to \text{normalize} \to \varphi_{\text{audio}}$$

Vetting inspects the raw render, deliberately: its thresholds are about the patch’s real output level, and measuring them post-normalization would make the peak ceiling meaningless. See the order is the design.

The normalized buffer is also what ▶ plays (raised to the target where a ceiling stopped it short, in auracle-wasm’s level.rs). One buffer serves the health check, the measurement, and the playback, which is what makes “no audition is unvetted” true by construction rather than by discipline. (The live keys play an edit before its check: see Safety.)

Mono

The measurement is mono, and so is the buffer $\varphi_{\text{audio}}$ is computed from. A patch that produces true stereo keeps both channels through to the live output, because the compiler builds the tail per channel, but the measurement path sums.

So stereo width is invisible to the model. There is no width coordinate, so no number of picks can teach a preference for it. The app says so on the chorus module’s spec card, and this is why.

The vetting gate

No candidate is ever auditioned unvetted. This is what makes randomly composed DSP graphs safe to put in front of a person. The live keys play an edit before its check, and a failed check mutes them (Safety).

Evolution will generate pathological patches: screaming resonance, silent duds, NaN-poisoned state, astronomically high pitches. The gate is what makes that acceptable rather than dangerous.

What it measures

vet(samples, cfg) inspects the raw, pre-normalization render and returns either a report or a quarantine reason.

pub struct VetReport {
    pub peak: f64,             // max |sample|
    pub rms: f64,              // whole-phrase RMS
    pub dc_ratio: f64,         // |mean| / rms
    pub pinned_fraction: f64,  // fraction within 2% of peak
}

Failures, checked in this order:

pinned_fraction, the share of samples within 2% of the peak, is informational only. It indicates heavy limiting, which is a character rather than a fault; promoting it to a failure would quarantine an entire timbre.

The thresholds

impl Default for VetConfig {
    fn default() -> Self {
        Self { rms_floor: 1e-4, peak_ceiling: 2.0, max_dc_ratio: 0.6 }
    }
}

Deliberately lenient. The gate exists to catch pathology, not to encode taste; that is the model’s job, and a gate that quietly enforces a preference corrupts the data it protects.

The polyphony-scaled ceiling

VetConfig::for_spec scales the peak ceiling with the phrase’s polyphony:

$$\text{ceiling} = 2.0 + 1.5,(V - 1)$$

where $V$ is max_voices(). The default 2.0 is one limiter-bounded voice (~1.5 peak in the ±1.0 float domain) plus overshoot headroom; $N$ gate-synced voices legitimately sum toward $N$× one voice.

Not scaling it would quarantine honest polyphony as runaway, and specifically the dyad segment, which exists to measure that summing. The measurement and the gate have to agree about what stacking is.

The thresholds were re-checked, and did not move

Worth recording, because a gate tuned before a whole family of modules existed is exactly the kind that starts quarantining a timbre.

When the drive modules arrived, the three thresholds were measured over the full cross of {soft, hard, tube} × drive {0.3, 0.6, 0.85, 1.0} × {saw, square, supersaw}, plus a stacked fold → tube drive → resonant ladder chain:

Peak is bounded by construction: quiver’s shapers all normalize into the ±1 domain and rescale, so a drive module is bounded at ±5 V however hard it is pushed. Drive buys harmonics, not level.

The DC result is 0.0016 only because compile::makes_dc puts a blocker in front of every tube-mode patch. Without it the same renders measure 1–8%, still nowhere near 0.6. So this gate was never what protected the feature extractor from that offset. A threshold a defect passes comfortably is not a defense against it.

The one threshold that would have had to move, had the shaper not been bounded, is peak_ceiling.

The order is the design

pipeline::featurize composes the stages, and the order matters:

// 1. Domain check, BEFORE the render
if let Some((site, value)) = tree.domain_violations().into_iter().next() {
    return Err(FeaturizeError::OutOfDomain { site, value });
}
// 2. Render
let mut render = render_phrase(tree, spec)?;
// 3. Vet the RAW render
let report = vet(&render.samples, &VetConfig::for_spec(spec))?;
// 4. Normalize
let norm = normalize_to(&mut render.samples, render.sample_rate, TARGET_LUFS)…;
// 5. Extract φ
let audio = audio_features(&render);
let structural = struct_features(tree);
// 6. Non-finite check on the VECTOR
for (name, value) in Features::phi_names().iter().zip(features.phi()) {
    if !value.is_finite() { return Err(FeaturizeError::NonFiniteFeature { … }); }
}

Four things about that order:

The domain check is first, before the render. A term with a knob outside its range is not a candidate that happens to sound bad: it is a term whose $\varphi$ would be a lie, and the ~600 ms render is wasted on it either way. This is the gate that keeps the observation log clean: every row in the log came through here. It is also the gate that was missing when the 1e30 sentinel got in, because vetting is a gate on the sound and amp.sustain = 1e30 renders perfectly well.

Vetting is on the raw render. Its thresholds are about the patch’s real output level; measuring peak after normalization would make the ceiling meaningless.

Normalization is before extraction. Otherwise loudness leaks into every amplitude-sensitive coordinate.

There is a second finiteness check, on the vector. It costs one pass over forty-four doubles against a render that took most of a second, and it is the only thing standing between a NaN out of a spectral descriptor and a posterior fit that returns all-NaN $\theta$. It is a different error from OutOfDomain and names the coordinate rather than a genome site, because at that point the term was legal and the measurement went wrong.

Quarantine is not just hiding

A failed candidate is never played and never shown, and it also scores QUARANTINE_FITNESS = -50.0 (in auracle-session’s surrogate.rs) in the search target.

That is safety layer 2: evolution learns to avoid the pathological region rather than repeatedly sampling it. Hiding alone would leave the search wasting its budget in a place it cannot see is bad.

The five layers, in one place

Two upstream bugs

Both in quiver, both fixed there, and both worth knowing as the class of thing that lurks under randomly composed DSP:

• Q198. Oscillator phase accumulators latched NaN permanently on non-finite pitch (NaN − floor(NaN)), and the while phase >= 1.0 wrap style used by Wavetable and FormantOsc spun the audio thread forever on an infinite increment (voct_to_hz overflows at extreme V/Oct). An infinite loop on the audio thread is not a glitch; it is a dead tab. Fixed with a shared $O(1)$ wrap_phase that recovers non-finite values.
• Q199. Graph scatter now zeroes non-finite module outputs, so one module’s NaN/Inf can never poison another module’s recursive state through the routing buffers. Containment at the graph boundary; per-module input sanitization remains defense in depth.

Since quiver-dsp 0.3.0, voct_to_hz clamps pitch to ±32 octaves (Auracle pins 0.4.0), so the overflow Q198 recovers from can no longer be produced by pitch CV. What remains at the clamp is finite aliasing, which meets this gate like any other render.

φ_audio: perceptual descriptors

Eighteen dimensions, kept compact and put on axes a linear model can express a preference along.

Computed on Hann-windowed frames of the normalized mono render (2048 samples, 50% hop), plus a few time-domain and segment-local measurements. Every field is finite by construction, because vetting ran first.

The coordinates

The :p2 suffix is the stimulus generation tag, and it is the migration mechanism rather than a comment.

Why these axes and not the obvious ones

The model downstream is linear in $\varphi$, so the axis a feature lives on decides what preferences are expressible at all.

Frequency features are logarithmic, not linear in Hz

Brightness and pitch perception are octave-based. On a linear-Hz axis normalized by Nyquist, moving a patch from 200 Hz to 400 Hz (a full octave, an enormous audible change) shifts the coordinate by 0.009, while 8 kHz → 16 kHz shifts it by 0.36.

A linear model in that coordinate cannot represent a taste for basses a shade brighter: the entire usable range is swallowed by the bright tail of the pool. The preference is not hard to learn, it is inexpressible.

So log_axis puts centroid, rolloff, and ZCR on a shared octaves-above-20 Hz scale, normalized to $[0,1]$ at Nyquist:

$$\text{log_axis}(f) = \frac{\log_2!\big(\max(f, f_0)/f_0\big)}{\log_2!\big(\max(f_{\text{Nyq}}, 2f_0)/f_0\big)}, \qquad f_0 = 20\ \text{Hz}$$

20 Hz because below it frequency is not audible as pitch and the ratio scale stops meaning anything. Normalizing at Nyquist keeps the vector sample-rate agnostic.

Note that a zero-crossing rate is a frequency (two crossings per cycle), so it goes on the same axis:

$$\text{zcr_mean} = \text{log_axis}!\left(\frac{r \cdot f_s}{2}\right)$$

where $r$ is the crossing fraction. Leaving it as a raw fraction would put a frequency-like quantity on a non-frequency axis beside three that are on one.

Heavy tails are logged

crest spans 1 to 40+; tail_ratio spans three orders of magnitude. Standardizing either raw hands the model a coordinate whose z-score is near-constant for most of the pool and $+4$ for a handful of outliers: a coordinate that separates nothing except the outliers.

$$\text{crest} = \log!\frac{\text{peak}}{\text{RMS} + \epsilon}, \qquad \text{tail_ratio} = \log!\left(\frac{\text{RMS}_{\text{last 300 ms}}}{\text{RMS} + \epsilon} + 10^{-3}\right)$$

The $10^{-3}$ floor inside the tail log matters: a pluck fully decayed by the last 300 ms would otherwise send the log to $-\infty$, and “silent tail” and “very quiet tail” are the same judgment to a listener anyway.

The attack crossing is interpolated, not floored

Quantizing the 90%-of-peak crossing to the analysis-window index makes attack_s exactly zero for every patch whose first window is already at peak (most percussive patches), turning a continuous axis into a zero-inflated spike.

So the envelope uses a fine grid (4 ms window, 1 ms hop) and interpolates linearly between the last sub-threshold hop and the first one over it:

$$h^\star = (i-1) + \frac{0.9,\max(e) - e_{i-1}}{e_i - e_{i-1}}, \qquad \text{attack_s} = \log!\left(\frac{h^\star \cdot \text{hop}}{f_s} + 0.005\right)$$

The measurement window is onset → the second note’s onset (2.0 s under the v2 phrase), and the $+5$ ms inside the log keeps the fast end resolved instead of compressing every percussive patch into the same value.

Spectral definitions

Per frame, with magnitudes $m_i$ over $\text{bins} = 1024$ and $\text{power} = \sum m_i^2$:

Centroid. The magnitude-weighted mean frequency, then mapped by log_axis:

$$f_c = \frac{\sum_i i \cdot \Delta f \cdot m_i}{\sum_i m_i}$$

Rolloff. The lowest bin at which cumulative power reaches 85% of the total.

Flatness. Geometric over arithmetic mean of the power spectrum, clamped to 1:

$$\text{flatness} = \min!\left(1,\ \frac{\exp!\big(\tfrac{1}{N}\sum_i \log(m_i^2 + \epsilon)\big)}{\tfrac{1}{N}\sum_i m_i^2 + \epsilon}\right)$$

Flux. Normalized by the combined magnitude sum of both frames:

$$\text{flux} = \frac{\lVert m^{(t)} - m^{(t-1)} \rVert_2}{\sum_i m^{(t)}_i + \sum_i m^{(t-1)}_i + \epsilon}$$

Dividing by the current frame alone is the obvious choice and it explodes: a loud frame decaying into near-silence gives an enormous flux for a change that is barely audible. The combined denominator keeps it in roughly $[0,1]$.

Frames whose power is below $10^{-12}$ contribute to none of the spectral means: a silent frame has no centroid, and averaging in a zero would drag brightness down in proportion to how much silence the phrase happens to contain.

Segment-local coordinates

The last three are measured over one note’s gate-on span, and they exist because whole-phrase statistics conflate things a listener does not.

Roles are found by property, not position, which is what keeps them meaningful if the phrase changes:

• held: the first note.
• high: the highest note at least half an octave above the held one.
• chord: the first note with chord voices.

A phrase missing a role yields 0.0 for its features, which reads as “no evidence” rather than as a measurement.

held_centroid_std is the important one. centroid_std over the whole phrase conflates note-to-note register jumps with genuine timbral motion: a static patch played across two octaves has a large centroid_std. Restricted to the held note’s span the coordinate is register-constant by construction, so it is the axis on which “a filter sweeping at 0.4 Hz” and “a static patch” are different patches at all. It needs at least 3 frames in the span, or it reports 0.0.

high_ratio = $\log$ of the high note’s span RMS over the held note’s. Does the patch speak in the upper register, or does its filter choke it?

chord_flatness_delta = mean flatness over the chord span minus the held span. Intermodulation and mud when voices stack.

Motion bands

held_centroid_std says how much a held note moves. It cannot say how fast. Measured on one saw-into-ladder patch under a ladder of cutoff modulations (cargo run -p auracle-features --example motion_probe --release), a 0.55 Hz sweep and a 13 Hz flutter score 0.098 and 0.094, and stepped random motion scores like a 6 Hz LFO. A linear model on those coordinates cannot hold “slow breathing, not fast wobble”, which is the first thing anyone says about a texture.

Hearing sorts fluctuation by modulation rate: a filterbank over the envelope, not just its variance (Dau, Kollmeier & Kohlrausch 1997), and the band-wise modulation power of a sound is much of what makes it recognizable as a texture at all (McDermott & Simoncelli 2011). The three coordinates are that filterbank, cut to three bands.

Motion is measured over the held span, starting once the note has arrived, so the attack is not read as motion. That is 250 ms after onset (MOTION_SKIP_S, in audio.rs), or later if the level, smoothed over ≈ 46 ms, has not yet reached 97% of its peak (MOTION_ARRIVED). Two trajectories are taken at a 256-sample hop (MOTION_HOP, ≈ 172 frames/s); the spectral features’ own 43 frames/s would fold the fast band. One is brightness, $c_t = \log_2(\text{centroid}_t / 20,\text{Hz})$, in octaves. The other is level, $\ell_t = \max(\log_2 \text{RMS}_t,\ \log_2 \text{peak} - 10)$, where one unit is 6 dB (one doubling, the same currency as an octave of brightness). A dip reads at most 60 dB deep, so one frame of digital silence in a chopped sound cannot outweigh every audible wobble.

The arrival rule matters for pads. A 0.9 s swell measured from the fixed 250 ms alone read 4.3 octaves over the floor in the slow band, because a ramp is curved in log level and detrending leaves most of it.

Each trajectory is linearly detrended (a ramp across the span is drift, which held_centroid_std already carries), Hann-windowed, and transformed. With $r$ the detrended residual, $\sigma^2_r$ its variance, and $P(f)$ its modulation power spectrum, band $B$ gets the variance share

$$v_B(r) = \sigma^2_r \cdot \frac{\sum_{f \in B} P(f)}{\sum_{f > 0} P(f)}, \qquad \texttt{motion}_B = \tfrac12 \log_2!\big(v_B(c) + v_B(\ell) + 10^{-4}\big).$$

The result is a log standard deviation in octaves. The floor, $\tfrac12\log_2 10^{-4} \approx -6.64$, is a hundredth of an octave: a static tone reads it exactly in all three bands, so “still” is one value and not numerical noise. A phrase whose held span is shorter than 0.75 s reads the floor too.

Measured on the probe ladder, the band that reads highest follows the rate: 0.55 Hz lands in slow, 2.7 Hz in mid, 13 Hz in fast, and stepped random motion spreads across slow and mid as its spectrum says it should.

What it cannot say

It does not say whether motion is regular. Separating a periodic sweep from a random walk needs several cycles in the window, and the held span holds fewer than three cycles of anything in the slow band. Both candidate measures tried (the normalized autocorrelation peak and the harmonic share of the modulation spectrum) separate periodic from random cleanly at 2.7 Hz and above, and not at all below 1.5 Hz, which is exactly where evolving textures live. A coordinate that guesses there would be taught to the model as a measurement, so regularity waits for a stimulus with a longer held span.

Deliberately compact

Eighteen dimensions is a choice. The model is a mixture of linear experts, and interpretable axes are the point: “bright”, “noisy”, “slow attack”, and “long tail” are things LEARNING’s weights can name and a person can recognize in their own taste.

A 128-dimensional MFCC bank would carry more information and would be unreadable, and would make the cold start dramatically worse: every dimension is posterior variance to pay down before the model says anything at all.

Known collinearity

Measured over 1,200 prior draws (cargo run -p auracle-features --example pipeline_stats --release -- 1200), the variance inflation factors are mostly comfortable, with one cluster that is not:

These are the values with the grammar’s octave weights (Discrete sites); drawing the octave uniformly, as it did before them, gave 19.7, 12.9, and 6.1. The zero-crossing rate’s DC removal, when it shipped, took them from 18.4, 10.4, and 5.9 to 16.9, 9.7, and 5.9 (Open questions has the history).

That is the brightness cluster: three genuine measurements of one perceptual thing. It is left standing deliberately: dropping any of them discards real signal rather than redundancy, since they disagree in informative ways (a bright noisy patch and a bright tonal patch differ in ZCR-versus-centroid). A shared (fused) prior over the cluster would be a modeling change rather than a feature change. It is built and switched off (TasteConfig::fused_rho, 0 by default): it improved θ recovery on the closed-loop gate and made the climb worse, as Open questions records.

For contrast, φ_struct had two exact linear dependencies, which is a different and worse problem and was fixed by dropping columns.

φ_struct: structural descriptors

Twenty-six dimensions, free to compute.

These cost nothing: no compile, no render, only a walk of the term. That is what makes a screening cascade possible: a structure-only surrogate could prune candidates before the expensive render path. No such cascade is built yet (Directions §12). They also capture taste axes audio features cannot fully separate (“likes supersaws”, “likes deep modulated chains”).

The coordinates

Nineteen family counts:

n_vco  n_supersaw  n_noise  n_wavetable  n_pluck  n_formant  n_silence
n_filter  n_drive  n_time  n_mod_fx  n_reverb  n_dynamics
n_lfo  n_env  n_rand  n_follow  n_mod_shape  n_mod_logic

Seven term-level numbers:

mod_density  mod_depth_mean  amp_attack  amp_sustain  amp_release
chain_balance  frac_sidechained

Twenty-six in total, appended after the eighteen audio coordinates to give $\varphi \in \R^{44}$.

Families, not one column per module

StructFeatures keeps a raw counter per module kind internally (the Styles tab and the auto-namer both want “two filters”, not “two subtractive stages”), but NAMES and to_vec collapse forty-six productions into nineteen family counts, and three of them, AudioIn, Track and Capture, into none (see below).

Two reasons.

Nothing meaningful distinguishes them. n_fold, n_distortion, and n_bitcrush all answer “how much nonlinear color”. n_chorus, n_phaser, n_flanger, n_tremolo, and n_vibrato all answer “how much periodic movement”. A user who likes drive does not first decide which drive.

Per-kind columns arrive as near-indicator variables. The prior draws bitcrush at 2.5%, ring mod at 2%, and granular at 1.5%, so those columns are zero in ~19 of every 20 pool members. A coefficient fitted on a column that is almost always zero is estimated from a handful of rows, and the Styles tab would render it beside coefficients fitted on hundreds, at the same visual weight.

Measured over 1,200 draws, the extreme case: each of the four CV processors appears in under 4% of patches and each of the six combiners in under 1%. A column that is zero in 99 rows of every 100 is not a coefficient, it is a rounding error with a name in the UI.

Sixteen sparse columns would also cost sixteen dimensions of posterior variance for the cold start to pay down before the model says anything at all.

The step sequencer shows the rule applied to a newcomer. The prior draws it into about 3% of slots, so a column of its own would be exactly the near-indicator above. It joins n_rand, which has become the stepped CV family (StructFeatures::n_stepped): to a listener an S&H and a step pattern are the same gesture, a value that holds and jumps (or glides) on a clock, and they differ only in whether the values were drawn once into the genome or anew at every tick. It does not join the euclid in n_mod_logic, because a euclid emits a gate and a step sequence emits a value. The column keeps the name n_rand because stored observations carry φ names, and every row already on disk predates the step sequencer, so its n_rand already is its stepped-CV count. The panel labels the column “stepped mods”.

What is deliberately not in φ

size, an exact identity

Every audio node increments exactly one raw counter, so

$$\text{size} \equiv \sum_i n_i \qquad\text{exactly, for every tree}$$

Including it makes the design matrix rank-deficient. The Gaussian prior keeps the posterior proper, so nothing crashes and no test fails, but there is an unidentified ridge along which the MH chain random-walks forever. That wrecks mixing, splits each coefficient arbitrarily between size and the counts (so the per-feature weights the Styles tab renders mean nothing individually), and poisons the taste→grammar proposal tilt, which reads exactly those coefficients.

size − depth would be no better: still an exact linear combination of coordinates already present.

The field is kept for display and naming. It just never reaches the model.

A second, subtler identity

Dropping size alone was not enough, and a VIF sweep caught it: VIF $\approx 10^9$ on every column involved, which is what an exact dependency looks like numerically.

A tree is a forest of source leaves joined by productions that each take some number of audio children, so the leaf count exceeds the total branch count by exactly one:

$$n_{\text{vco}} + n_{\text{supersaw}} + n_{\text{noise}} + n_{\text{wavetable}} + n_{\text{pluck}} + n_{\text{formant}} + n_{\text{silence}}$$ $${} - n_{\text{mix}} - n_{\text{ringmod}} - n_{\text{comp}} - n_{\text{duck}} - n_{\text{gate}} - n_{\text{vocoder}} ;=; 1$$

Silence joins that sum as a source leaf, because that is what it is: it has no children, so it ends a branch exactly as a Vco does. Joining keeps this one equation with one dropped column, and $n_{\text{mix}}$ stays the column dropped. Leaving it outside instead would make the identity exact for a tree with no holes and slack for one with them: near-exact almost always, which is a worse thing to carry than an exact dependency: an exact one is unmistakable in a VIF sweep, and a near-exact one is a large number that looks like a judgment call.

Audio in: counted, and not a column

AudioIn is a source leaf too, and it has its raw counter, n_audio_in, so size is still the sum of the counts and the identity above, written over the raw counts, still holds. But it is not a column of $\varphi$: RFC-008 keeps $\varphi$’s shape, and at its prior weight (0 until live capture works, 0.5% after) the column would be zero in nearly every row. Leaving it out brings no dependency back, because the identity was never reachable from the retained columns: it needs n_mix, which is dropped, and each binary count separately, which the families hide. The shape coordinates count it with no help (chain_balance and frac_sidechained read arity from the tree, where it is a leaf), and what an input patch does to a signal reaches the model through $\varphi_{\text{audio}}$, measured on the audition clip.

Track and Capture are counted the same way, with n_track and n_capture and no column, and one more reason: the prior never draws either (they are player kinds), so a column would be zero in every drawn row. The shape coordinates read them from the tree: a TRACK is a binary node, a CAPTURE a unary one over what it records.

The identity holds exactly, for every tree. It became a general statement only when the four sidechained productions (comp, duck, gate, and vocoder) arrived, each taking two audio subterms exactly as mix and ring mod do.

That is one equation, so exactly one column has to go, and dropping more would remove real dimensions rather than redundant ones. With both binary counts gone, $\varphi$ could not tell a crossfade from a ring modulator at all, which are about as different as two nodes in this grammar get.

So n_mix leaves: it is the one determined by the others, and its proposal tilt is recovered from the source coefficients in the engine’s biased_prior. The other five stay, but never as columns of their own: ring mod lives inside n_drive, the vocoder inside n_filter, and comp/duck/gate inside n_dynamics.

Why n_dynamics is still safe

Worth checking rather than assuming, because n_dynamics is exactly $n_{\text{comp}} + n_{\text{duck}} + n_{\text{gate}}$ and it is a retained column, the only family whose members are all on the wrong side of the identity.

It is safe because the identity needs each binary count separately. n_ringmod is only ever visible summed with folds, distortions, and bitcrushers; n_vocoder only summed with filters and EQs. No linear combination of the retained columns isolates either, so the equation cannot be reconstructed. n_dynamics supplies three of the six binary terms and nothing supplies the other three.

Confirmed empirically: on the 1,200-draw sweep every structural coordinate comes back well under 10, with n_dynamics at 1.7 (1.9 when this was first measured).

depth, a weaker but real argument

VIF $\approx 21.7$. Not exact, so the posterior stays proper, but a coefficient that unstable is not individually meaningful, and the Styles tab renders these per-feature weights as though they were. Dropped.

Health of the retained set

Every family count comes back at 3.0 or under on the 1,200-draw sweep, the highest being n_noise. That is the reason the families exist; forty separate module columns would not have managed it. The term-level numbers run higher, and still well under 10: amp_attack is the highest of all twenty-six at 6.3, then mod_density 4.6, amp_release 4.3 and mod_depth_mean 4.1.

When the three most recent additions arrived they measured n_mod_shape 1.6, n_mod_logic 1.3 and mod_depth_mean 3.8, with mod_density rising from 2.7 to 4.1 as the one visible cost of adding a second modulation-shape coordinate beside it. The same sweep today reads 1.8, 1.2, 4.1 and 4.6.

Reproduce with:

cargo run -p auracle-features --example pipeline_stats --release -- 1200

The unit coordinates

Six of the twenty-six are UNIT_NAMES, a subset of NAMES rather than a reordering. Each is either a normalized genome site read straight through (amp_attack, amp_sustain, and amp_release) or a ratio of two counts, already in $[0,1]$ (mod_density, chain_balance, and frac_sidechained).

mod_depth_mean is not one of them. It is a mean of modulation depths (1 for a bare modulator, 2 for one shaped once), so it is 2 or more for exactly the shaped chains it exists to measure.

The distinction matters for display: these can be rendered as percentages honestly, whereas a family count cannot.

amp_sustain is also the coordinate the 1e30 sentinel killed; see the sentinel.

Standardization

A Gaussian prior over $\theta$ only makes sense on a common scale. The fitting of that scale is a view of the data, not the data.

Raw $\varphi$ scales vary wildly: counts 0–5, log-octave axes ~0–1, log crest 0–4. The standardizer is a per-dimension affine map

$$z_j = \frac{\varphi_j - \mu_j}{s_j}$$

re-fit at every posterior fit, over the union of the observation log and the live pool.

It persists with the profile, always

$\theta$ is only meaningful relative to the standardization that produced it, so a taste profile carries both or neither. A log without its standardizer is a set of numbers whose units have been lost.

The log stores raw $\varphi$, which is what makes re-fitting safe: a re-fit standardizer simply re-expresses the same evidence on a scale that still matches where the pool actually is. Had the log stored z-scores, the scale would be frozen at whatever the pool looked like on the day each vote was cast.

The inverse map exists for exactly one reason: migrating logs written before raw-φ logging. A legacy log plus the standardizer it was written under is the raw data, just encoded.

Robustness: a fault detector, not a policy

Standardizer::fit is the plain moments unless a column is provably runaway. On clean data it is bit-identical to the naive fit.

Per column:

1. Drop non-finite cells (a column that is entirely non-finite falls back to $\mu = 0, s = 1$, the reading of “no usable evidence on this axis”).
2. Compute the plain moments $(\mu, s)$.
3. Compute winsorized moments $(\mu_w, s_w)$ with the extreme 2% of each tail pulled in.
4. Use the winsorized pair only if $s > 10^6 , s_w$.

The constants, in auracle-taste’s standardize.rs:

const WINSOR_TAIL: f64 = 0.02;
const WINSOR_MIN_ROWS: usize = 10;
const RUNAWAY_RATIO: f64 = 1e6;

Finally $s_j \gets 1.0$ if $s_j < 10^{-9}$, so a degenerate column standardizes everything to itself rather than dividing by nothing.

Why not just winsorize always

Because it was tried first and thrown out, and the measurement is why.

Clipping 2% of each tail unconditionally took a 16-seed search_health --climb run from +1.877 ± 0.362 mean gain, climbing on 15 of 16 seeds, to +0.204 ± 1.347 on 11 of 16, with one seed at −18.2.

Trimming a real tail is not free. A data-hygiene fix that costs the search a standard deviation is not a fix. So the clip became a fault detector: plain moments unless the column is provably broken.

Why the threshold is $10^6$

The first guess was 8×, on the reasoning that clean columns differ “by a factor of order one”. The paired run said otherwise: 15 of 16 seeds came back bit-identical and the sixteenth went from +0.12 to −40.5.

So the threshold was measured.

cargo run -p auracle-features --example winsor_ratio --release -- 150

fits 150 clean 48-patch pools and reports the largest plain/winsorized $\sigma$ ratio per column. Over 6,000 column-fits the maximum is 14.6 (rms_std:p2), with chord_flatness_delta:p2 at 13.9, and still climbing with the sample, because a log-scale audio descriptor over a pool that happens to contain one near-silent patch genuinely has a tail.

Meanwhile a single $10^{30}$ in a column whose real values live in $[0,1]$ gives a ratio near $2 \times 10^{29}$.

$10^6$ sits five orders above anything clean $\varphi$ has been observed to produce and twenty-three below the fault, which is about as far from both edges as this quantity allows.

The tail size

$$k(n) = \begin{cases} 0 & n < 10 \ \mathrm{clamp}\big(\lceil 0.02n \rceil,\ 1,\ \lfloor (n-1)/2 \rfloor\big) & n \ge 10 \end{cases}$$

ceil, not floor. The first version used floor and was inert exactly where it was needed. The reference population is a 48-patch pool, and $\lfloor 48 \times 0.02 \rfloor = 0$, so nothing was clipped at the size the app actually fits at. The pre/post measurement came back bit-identical and said so.

Below 10 rows nothing is winsorized at all: with a handful of values the min and max are the spread, and pulling them in throws away the only information about it.

There is also a hi > lo guard, which keeps a legitimately rare column intact: when 96% of rows are the same value (a module that appears in two patches out of forty-eight) the tail is the column’s only information, and clipping it would flatten a real coordinate to nothing in the name of robustness.

Winsorizing rather than trimming

When it does fire, the extreme rows are pulled in, not dropped. The rows are not independent draws from a nuisance distribution: they are the patches the player actually met, and a real extreme patch is evidence about where the pool is. Winsorizing keeps its vote and takes away only its leverage on the units.

Two properties, both tested

A single escaped row cannot kill a column. Fifty values spread over $[0,1]$ plus one $10^{30}$: unwinsorized, the outlier owns the mean and the scale, every real patch standardizes to the same place, and the column is dead. The model can never learn from an axis whose fifty honest values are separated by $10^{-30}$ of a standard deviation. The test asserts $\sigma$ moves by less than 0.05 and that the coordinate still separates two real patches by more than 3.

Clean columns come out bit-identical to the plain moments. The load-bearing property, asserted with assert_eq! on floats, because “close enough” would let the regression back in, over a heavy right tail, a near-constant column, a bipolar one, a count with a legitimately extreme member, and a five-row column below the floor entirely.

One implementation detail exists to protect that property: the column stays in row order and the quantiles come off a copy. Floating-point addition is not associative, so summing the sorted column would move the mean by a ULP on clean data, and the whole claim is that clean data comes out bit-identical.

Where this fits in the defense

The fault this detector exists for is fixed upstream of here: clamp_domains on load, FeaturizeError::OutOfDomain before the render, the load-time repair. This is the line that means the next escape costs a coordinate’s precision rather than the coordinate.

Layers above should make this unnecessary. It exists anyway, because in the sentinel incident the value got through everything that was supposed to stop it.

Faces

A face is a picture of a render: its spectrum in bands and slices of time, compared with the bank. It is not a feature. Nothing in $\varphi$, the taste model or the vetting gate reads it.

The app draws every sound as its face (the guide’s a sound’s face). The measurement is auracle_features::face; the comparison with the bank is apps/web/faces.js, and one renderer draws a face at every size, from a bank row’s icon to a full screen, apps/web/vessel.js.

Where it is taken

Inside every featurization (featurize_memo), from the same normalized render $\varphi$ is measured on, and carried beside $\varphi$ on the memo row (CachedFeatures::face). Every render already passes through there (the serial fill, the farm’s farm_render, a generation’s walks, an offer, an edit), so a face costs no render of its own: 1.66 ms natively against a 146 ms featurization (1.1%, examples/face_cost.rs over the 62 presets), and 2.5 ms in wasm against 201 ms (auracle-wasm/examples/face_cost.mjs).

Samples are read as the f32 the audition buffer holds, so the face of the featurization’s render and the face of the stored audition are the same bytes. A row stored before faces existed has none and is still current $\varphi$ (the RENDER_EPOCH does not move for it); its face is completed by a render when the app asks for it.

The measurement

Hann-windowed frames of 2048 samples, hop 1024, of the mono render $x$.

Bands. FACE_BANDS = 40 bands with edges evenly spaced in log frequency from FACE_LO_HZ = 35 Hz to FACE_HI_HZ = 14 kHz (about a fifth of an octave each):

$$e_k = 35 \cdot 400^{k/40}, \quad k = 0, \dots, 40.$$

A band’s value is the mean power density over its edges. With $P_j$ the power in FFT bin $j$ (covering $[j - \tfrac12, j + \tfrac12)$ in bins) and $o_{bj}$ the length of band $b$’s overlap with bin $j$,

$$B_b = \frac{\sum_j o_{bj}, P_j}{\sum_j o_{bj}}.$$

A band narrower than one bin (every band below about 150 Hz at 44.1 kHz) reads the bin it sits in rather than nothing, and white noise reads the same in every band. (Prototype v2’s data summed whole bins, and its two narrowest bands read empty.)

Slices. The render is cut into FACE_SLICES = 12 equal spans of time, and a frame belongs to the slice its center falls in. On the standard phrase (5.05 s) a slice is 0.42 s: five slices of the held C4, one of the C5 stab, two of the dyad, four of the low C3 and its release. Each slice’s spectrum is the mean of its frames’ power; the long-term spectrum is the mean over every frame.

Levels. Each spectrum is in dB relative to its own loudest band, so a face shows shape and not level (the render is loudness-normalized already), floored at FACE_FLOOR_DB = −60 dB. Each slice’s loudness is its mean power in dB relative to the loudest slice, with the same floor. A slice under about −170 dBFS is silence: all floor.

Encoding. FACE_LEN = 532 bytes, each a level in FACE_STEP_DB = 0.5 dB steps above the floor: the long-term spectrum (40), the slices (12 × 40), their loudness (12). It serializes as one base64 string, about 700 bytes beside a memo row of about 1 KB.

Against the bank

The app knows which sounds the bank shows, so the comparison is made there, over the long-term spectra $L_s$ of the bank’s sounds $s \in \mathcal B$ (the pool, less what was cut):

$$\mu_b = \frac{1}{|\mathcal B|}\sum_{s} L_{s,b}, \qquad \sigma = \max!\Big(3,\ \sqrt{\tfrac{1}{40|\mathcal B|}\textstyle\sum_{s,b}(L_{s,b} - \mu_b)^2}\Big).$$

The spread $\sigma$ is one number pooled over every band of every sound, as prototype v2 took it, floored at 3 dB (FACE_SPREAD_FLOOR_DB) so a bank of near copies does not blow a fraction of a dB up to full width. A spectrum $S$ is drawn as

$$v_b = \frac{S_b - \mu_b}{\sigma}.$$

Below FACE_MIN_BANK = 4 faces in the bank there is nothing to compare with, and no face is drawn.

When it is taken again. The bank’s $\mu$ and $\sigma$ are recomputed when the set of the bank’s faces changes (a sound added, replaced or cut; at most once a frame), and the faces are drawn against them only when they have moved since the faces were last drawn by more than FACE_RESTAT_DB = 0.25 dB in a band or FACE_RESTAT_SPREAD = 1% of $\sigma$. A smaller change moves a row's 24 px face by under a tenth of a pixel at the bank's usual spread (about 13 dB), and by about a third of one at the 3 dB floor; the 150 px card's by under half a pixel, and about two at the floor (a band’s half-width moves by $R \cdot 0.35,\Delta v$ at the mean). The recomputation is $O(40|\mathcal B|)$; redrawing is the cost, so the bank’s rows in view are redrawn the next frame and the rest when the page is idle (2–3 ms in the next frame for a pool of 40, against 17–22 ms when all forty were redrawn at once).

The drawing

As prototype v2 draws it (A.face): the vessel is mirrored about its center, low bands at the base, with half-width

$$w_b = R,\sigma(1.4, v_b)\cdot k$$

for a box of half-width $R$ ($\sigma$ here the logistic function), so a band at the bank’s mean is half the box wide. The 40 values are smoothed over 2 bands either side (1 on a face 36 px tall or more) and joined with quadratic curves through their midpoints. The outline is the long-term spectrum ($k = 1$); under it each slice draws a faint layer with $k = 0.35 + 0.65,\ell$ and opacity $0.05 + 0.11,\ell$, where $\ell = \operatorname{clamp}(1 + \text{loudness}/30\ \text{dB}, 0, 1)$, and a slice with $\ell < 0.25$ draws none (FACE_LAYER_RANGE_DB).

Large faces (the share card, a full screen) add the specimen’s glow, a blur of 14 to 30 px on the outline, and the floor’s reflection: a line of light under the vessel and its outline mirrored in it, faint and fading over a third of its height. A slot shows its face drawn once per bank, at the screen’s density, as an image.

Keys and caching

A face is filed under its render namespace and render key, "<cache_namespace>/<render_key>", as a farm row is (persistence, the web runtime). The engine worker copies a face out of the memo (a least-recently-used map a generation’s walks churn) the first time it is asked for, and keeps it in memory and in an IndexedDB store stamped with the namespace: a build whose renders differ cannot read another’s faces. What the worker holds in memory, what the memo holds and what a resident audition gives are answered at once; the store is looked up in its background lane, and a face none of them has is rendered in a lane of its own below that, after the bank has finished arriving, behind a refit, a guess or a cable probe, and dropped if the row asking for it has left the view. Such a render is not kept, so it pushes no audition out of the cache. A face’s render already running (about half a second) is the most it can hold anything up by.

The presets’ faces ship with the app. A preset’s render is fixed, so every preset’s face is rendered ahead of time, natively, through the same engine surface the worker uses, into apps/web/preset-faces.json (make preset-faces), with the render namespace and the reference clip it was rendered under and each preset’s render key. The page draws a preset’s face from it, filed under the same key, without asking the engine, where the namespace is the session’s and, for a preset with an AUDIO IN, while the session hears the reference clip; anywhere else the engine renders it as above. A test renders every preset again natively and fails while the file differs by a byte (crates/auracle-wasm/tests/shipped_faces.rs), and another renders every preset in the built wasm, as the worker renders a preset’s face, and fails while one of them differs from the file’s, or is filed under another key (tests/web/boot_agrees.spec.js): a face is quantized to half a decibel, so a last-digit difference between the two builds could move one preset’s band by a step.

The stage’s live outline (PERFORM’s stage mode) is measured as a face is: the output’s latest 2048 samples, through the same Hann frame and FFT, read as each band’s mean power density over the same fractional bins (faces.js createLiveMeter, bandWeights), into buffers made once. Not the analyzer node’s own spectrum, which is Blackman-windowed: on a C3 sawtooth it read a low band 16.5 dB away from the face. A test feeds the meter the engine’s own fixture (one frame of that sawtooth and the face the engine takes of it) and holds every band to the face within 1 dB (it agrees to 0.24 dB); the same frame through Blackman fails it.

A sound of your own

A recording you bring is measured the way a patch is, on the part of φ a recording can measure. It takes a place among the sounds, its nearest are named, and a generation can be bred toward it.

This is the engine and the worker's side of Plan-005 task 11. The app does not offer it yet: the card that takes a dropped file is still to be built.

A recording is not the phrase

Every patch is measured on the standard phrase: a held C4, a C5 stab, a dyad and a low C3 with a release window, with rests between them. Each coordinate of φ is a statistic of that render. A recording is one sound of something else entirely, with no notes the engine knows of. So a coordinate means the same thing on a file only if it does not depend on what the phrase plays.

That was measured, not argued. examples/file_phi.rs (in auracle-features) renders every preset on three stimuli that are not the phrase (a legato melody with no rests, a drone, short stabs over two octaves), measures each render as a file, and compares the result with the same preset's φ on the phrase. The preset is the truth: a file of that patch should land where the patch does. A coordinate counts as measured by a file when, on every stimulus, its correlation with the phrase value across the presets is at least SURVIVES_R $= 0.9$ and its root-mean-square difference is at most SURVIVES_RMSE $= 0.5$σ of the presets' spread on the phrase (two presets drawn at random differ by about 1.4σ). Every σ in this table is that one: the presets' spread, not a session's. Run it with cargo run -p auracle-features --example file_phi --release; it also prints each coordinate's bias.

62 presets on the phrase; 62, 56 and 62 measured as files (six presets fade below the trim before half a second of drone has passed).

The measured coordinates are not unbiased. A file reads a little brighter than its preset does on the phrase: zcr_mean by +0.35σ on the melody and +0.30σ on the drone, centroid_mean and rolloff_mean by +0.09 to +0.17σ. Within the bar, so they are measured; but a recording sits a shade brighter among the sounds than the patch that made it would, and its nearest sounds lean that way.

A one-shot shorter than the half second a file must hold does not measure them all: with a single G4 of 0.25 s added to the stimuli, zcr_mean (0.55σ) and bass_fraction (0.62σ) miss the bar, and they still miss at 0.5 s (0.54σ, 0.61σ). One short note at one pitch says too little about weight and brightness, which is why FILE_MIN_SECONDS stays at 0.5 s.

What a file measures is its spectral balance: how bright it is (centroid_mean, rolloff_mean, zcr_mean), how noisy (flatness_mean) and how much weight it has below 250 Hz (bass_fraction). Those depend on what the sound is. The rest depend as well on what was played:

• Level and dynamics (rms_mean, rms_std, crest) carry the phrase's four rests and its release window, and a recording has neither.
• Movement (centroid_std, flux_mean) over the whole phrase is mostly its jumps between registers, and a file's is whatever it plays.
• The attack is the phrase's held C4 arriving, and a file's first event is something else.
• The tail is the phrase's release window; a trimmed file's last 300 ms are wherever the sound stopped.
• The six role coordinates (held_centroid_std, high_ratio, chord_flatness_delta and the three motion bands) each read one note of the phrase by its role, and a file has no such note.
• Every structural coordinate describes a patch, and a recording has none.

So a file is placed by 5 of φ's 44 coordinates. The other 39 are masked (FILE_MASKED and the structural half; file_observed() is the whole mask). A gate test re-measures half the presets on every build and fails when the mask and the measurement disagree.

How a file is measured

featurize_file takes what the page decoded, mixed to mono, at its own rate, and measures it as featurize measures a render:

1. Bounds. A rate from 8 to 192 kHz, at most FILE_INPUT_MAX_SECONDS $= 120$ s in, every sample finite. A refusal is a flag the app words (bad_rate, too_long, too_short, non_finite, silent), never text.
2. Trim. The sound runs from the first 10 ms window within TRIM_DB $= 60$ dB of the loudest to the end of the last one. Silence inside the recording is kept; it is part of the sound.
3. Cut. At most FILE_MAX_SECONDS $= 30$ s of sound, from where it starts, and at least FILE_MIN_SECONDS $= 0.5$ s.
4. Resample to the phrase's 44.1 kHz with a windowed sinc (16 zero crossings, Blackman window, cut at 0.97 of the lower Nyquist). Every frequency coordinate is normalized at Nyquist, so this is what puts a 48 kHz file's brightness on the same axis as a render's. A file already at 44.1 kHz is not touched.
5. Normalize to TARGET_LUFS $= -18$ under the same peak ceiling, as loudness normalization does for every render.
6. Measure with the same audio_features a render goes through. Nothing in it changes for a file. Its first-note window is the phrase's own (onset to the second onset, 2.0 s), and its role coordinates find no note and read their "no evidence" values, which the mask then ignores.

Measuring a render's φ is unchanged by any of this: no coordinate, constant or step of featurize moved.

What the page sends

The page decodes the file, mixes it to mono, cuts it to 120 s and resamples anything above 48 kHz down to 48 kHz before it posts it. The engine measures at most the first 30 s of sound, and the samples are copied into the engine's memory, which wasm never gives back: two minutes grow it by about 42 MB at 48 kHz and 108 MB at 192 kHz. The analysis is one call the worker cannot interrupt; for 30 s of sound it takes 0.16 s at 44.1 kHz, 0.31 s at 48, 0.52 s at 96 and 0.94 s at 192 (auracle-wasm's examples/own_cost.mjs, wasm under node on an M3 Max), most of it resampling.

What each refusal asks of the card:

• too_long: more than 120 s reached the engine. Cut it and send it again.
• too_short: under half a second of sound once trimmed. Nothing to retry; the card says the sound is too short to place.
• silent, non_finite, bad_rate: nothing in it can be measured.
• After any refusal the sound brought before is still the session's: the card asks own_sound to redraw it.

Missing coordinates

What a masked coordinate becomes depends on what reads the sound, and none of it claims to know the coordinate's value:

• Distances leave them out. The nearest sounds are ranked by Euclidean distance in standardized φ over the five measured coordinates. Filling a masked coordinate with the pool's mean would pull every distance toward the center of the pool and call the most ordinary patch the nearest.
• The tilt has no factor for them, which is the same as integrating them out (below).
• Anything linear reads them at the mean, where they add exactly nothing. The map's projection is one such reading (below). A utility $\theta^\top z$ would be another, and the observation log already puts a coordinate an old vote lacks at the standardizer's mean for the same reason: zero contribution, exactly "no evidence". Nothing reads the sound's utility today.

Its place among the sounds

The sound's $z$ is its raw φ standardized by the session's standardizer, the same scale every pool member's is on, over the five coordinates it has.

Its nearest sounds (Engine::own_nearest, Engine::own_nearest_presets) are ranked by

$$d(x) ;=; \Big(\sum_{j \in O} \big(z_j(x) - z^*_j\big)^2\Big)^{1/2},$$

where $O$ is the set of measured coordinates and $z^*$ the file's. TASTE's map is a projection of this same Euclidean space (PCA over standardized φ), so near means what the map draws as near, without the projection's loss. The app had no nearest sounds before this, so there was no other metric to match. The presets are ranked from the measurements the app already ships (perform-wirings.json, regenerated by make perform-wirings), back to raw φ and standardized by this session's scale: no preset is rendered.

Its place on the map (TasteMap::own) is the map's own projection of the five measured coordinates, on the map's axes $a_1, a_2$ about its center $\mu$:

$$x ;=; \sum_{j \in O} a_{1j},(z^$$j - \mu_j), \qquad y ;=; \sum{j \in O} a_{2j},(z^_j - \mu_j),

which is every other point's projection with each masked coordinate at the map's mean. The sound is placed on the map; it is not one of the points the axes are fitted to, so bringing a sound does not move the map.

That was chosen by measurement, in examples/own_census.rs (in auracle-session). Each target preset is put into a taught pool, so the map draws it, and its recording is placed. Error is the distance to the preset's own point, as a share of the map's spread (the RMS distance of its points from the center), over 18 placements (3 sessions × 6 presets):

The posterior mean, $\big(A_O^\top A_O + \sigma^2 \Lambda^{-1}\big)^{-1} A_O^\top (z^*_O - \mu_O)$ with $A = [a_1\ a_2]$, the axes' variances $\Lambda$ and the variance $\sigma^2$ they leave unexplained, shrinks a point measured on few coordinates toward the center; here that cost more than it saved. The last row says where the error comes from: a recording costs almost nothing over the phrase on the same coordinates, and the mask is what costs. Five coordinates put a sound within about a third of the map's spread of where its whole φ would, which is what the prototype's card means by "placed by its spectrum".

Breeding toward it

Engine::refine_toward_jobs opens a generation exactly as EVOLVE POOL does, with two differences. Its parents are the refine_seeds pool members nearest the sound, not the best ranked: breeding toward a sound starts from what is already near it. And every walk samples a target tilted toward the sound (TowardFitness):

$$\pi(x) ;\propto; p_{\text{grammar}}(x), \exp!\Big(\beta,\big(f(x) - \min\big(\tfrac{\gamma}{2},d(x)^2,; F\big)\big)\Big), \qquad d(x)^2 = \sum_{j\in O}\big(z_j(x) - z^*_j\big)^2,$$

where $f$ is the taste surrogate $\E[u_\theta(\varphi(x))]$, $\beta = 2$, $\gamma$ is OWN_GAMMA $= 4$ and $F$ is OWN_FLOOR $= 25$.

Read as Bayes, this is the taste's own target times a Gaussian likelihood $\mathcal N\big(z^*_O;, z_O(x),, \tau^2 I\big)$ with $\tau^2 = 1/(\beta\gamma)$: the patches you would like, weighted by how well each explains the recording as a measurement of its sound. A masked coordinate has no factor, which is that likelihood integrated over it. At $\gamma = 4$, $\tau \approx 0.35$σ of the session's spread. That is the same size as the error a recording makes on the coordinates it measures (0.03 to 0.43σ in the table above), but those are σ of the presets' spread, a different scale, so it is a choice of size made with the census below, not a calibration of the file's error.

The floor is the likelihood of a contaminated measurement: the recording is the patch's sound with noise $\tau$, or a sound this grammar does not make, and then distance says nothing more. It is also what keeps the walk out of patches that do not vet. A proposal that does not vet has no φ to measure, so it keeps its quarantine score ($-50$) untilted; an unbounded pull would rank it above every patch more than $\sqrt{100/\gamma} = 5$σ from the target, and a first census without the floor saw strongly pulled walks end on one; with it, none did. Half the quarantine's depth keeps every listenable patch above quarantine for any taste above $-25$, and still pulls out to $\sqrt{2F/\gamma} \approx 3.5$σ.

The walk stays exact Metropolis–Hastings, as an aimed offer does: the kernel is untouched and the tilt is a deterministic function of the patch, so every acceptance is the ratio of this target, and the state a walk ends on is a draw from it. The tilt costs no render: the taste surrogate has just featurized the proposal through the same memo. A proposal that does not vet keeps its quarantine score. The target rides in the generation's context (WalkContext::toward), so the render farm walks the same tilted target the engine would. A generation without a target walks exactly as before; at $\gamma = 0$ the tilted walk is the untilted one, bit for bit.

Children are admitted by the bar every generation's are: a child must please the taste more than the member it would displace. So the engine breeds toward a sound only after the first fit, as EVOLVE POOL does; before it, Breed toward it adds the nearest presets (below).

Measured

examples/own_census.rs: three sessions (a pool of 48 and a taste taught by a synthetic listener over 60 duels), six target presets recorded on the melody, five walks of 40 steps a target, every arm from the same job seeds, so the arms are paired walk by walk. cargo run -p auracle-session --example own_census --release reproduces these tables (its defaults are 3 6 1,2,4,8 5), and its placement error lines the placement table above. Distances are in σ of the session's spread over the five measured coordinates, mean ± standard error over 90 walks: to the recording's $z^*$ at the walk's start and end, and at the end to the preset itself (its phrase φ on the same coordinates), which is the truth the recording stands in for. $\Delta\E[u]$ is the child's expected utility minus its parent's.

From the parents nearest the sound, which is what a breed toward it does:

From the taste's own parents (the best ranked, as EVOLVE POOL breeds from), which says whether the pull works from farther away:

Tilted walks end nearer than untilted ones from the same jobs by 2.03 ± 0.16σ from the nearest parents and 1.50 ± 0.15σ from the taste's (paired by walk, γ = 4). Untilted, a walk from the nearest parents wanders off the sound as it climbs the taste; tilted, it stays near and still pleases the taste more than its parent. From farther away the pull costs taste (−0.56 at γ = 4), which is the trade the target states. γ = 4 is the smallest pull whose walks from the nearest parents end nearer than they began, and from the taste's parents it ends nearest both the recording and the preset: at 8 the floor leaves the farther walks unguided. Of the 90 γ = 4 children from the nearest parents, absorbed into their generations as the app would, 86 were admitted and 4 were not.

What is not done, and what the card will do

The card is the app's half, still to be built: the worker answers own_sound_set, own_sound, own_sound_clear and refine with toward: true, and nothing sends them yet. Where the prototype shows what the engine does not do, the maintainer decided the card's behavior (Plan-005 task 11):

• In the bank, never in a pair. The prototype lists the recording among the presets and plays it from there, and so will the card: the page keeps the decoded audio in IndexedDB, so it plays after a reload too. In the engine the sound has no tree, so it is never dealt in a pair, held as a patch or bred from; the session keeps only its measured coordinates, by name, because an autosave holding half a minute of samples would be megabytes the engine never reads.
• Before the first fit, Breed toward it adds the nearest presets, as the prototype does: own_nearest_presets names them and load_preset adds them, with no taste needed. After the first fit it breeds the tilted generation above.
• The children grow from their parents, the pool members nearest the sound, leaning toward the recording; the prototype's buds from the dropped face would show a fact the engine does not record (ADR-012).
• Hold it plays the recording through the named controls once audio in is live (Plan-007), the UI stream's work.
• Nearest, and the map, are of other sounds. The prototype ranks presets by its 40-band face and places the recording on a map of the 62 presets. The engine ranks pool members and presets, separately, over the five coordinates, and places it on TASTE's map of the pool and what you have heard. The face itself is the page's to draw from the decoded file, as for any render.

Not done in the engine:

• More of φ. Five coordinates are what a recording measures under today's φ. A recording's movement, attack and tail would need coordinates defined without the phrase's notes, which is a change to φ and owes a revalidation. A change to φ also owes a re-measure of the mask: the gate test fails until FILE_MASKED agrees with file_phi again.

Utility as a max of experts

A candidate is as good as its best style thinks it is. Two more obvious designs cannot represent a cross-island comparison at all.

The form

A candidate $x$ has the feature vector $\varphi(x)$, which the standardizer maps to $z(x)$ with per-feature means $\mu$ and scales $s$. The taste model holds $K$ styles, and style $k$ is a weight vector $\theta_k$: a linear functional on $z$. Utility is the maximum over styles, not a weighted mixture:

$$u(x) = \max_{k \in 1..K} ; \theta_k^\top z(x), \qquad z(x) = \frac{\varphi(x) - \mu}{s}$$

At $K = 1$ this reduces exactly to Bayesian linear regression on $z$, which is a useful property: the mixture is a strict generalization with no special-casing at the boundary.

One posterior draw’s utility (TasteSample::utility_mix):

pub fn utility_mix(&self, phi: &[f64]) -> f64 {
    self.theta.iter()
        .map(|t| dot(t, phi))
        .fold(f64::NEG_INFINITY, f64::max)
}

Why a maximum

Taste is multi-modal. One person can love dark drones and bright plucks (“ambient-me” and “acid-me”), and those are not points on one axis. A single linear utility would average them into a preference for neither, and would then be confidently wrong about both.

The max form gives each island its own style, and every judgment, including a duel across two islands, compares candidates on the shared scale $u = \max_k u_k$. A dark drone and a bright pluck are both scored, each by whichever style rates it highest, and the comparison is well-formed.

Two rejected designs, and why

A per-session style latent $z_s$

“One mood per session: sample which style is active, then use it.”

Fails because it cannot represent several islands inside a session. A user who auditions a pad, then a bass, then a pad in one sitting is not switching moods; they have two tastes at once. Whenever the session’s latent is wrong for the current candidate, every observation in that session is scored by the wrong style.

A per-observation marginalized style

“Marginalize over which style judges each observation.”

Fails on a sharper point: it forces both duel items through the same style, so a cross-island comparison is unrepresentable. There is no style under which “the drone beats the pluck” is a sensible statement if the drone lives in style 1 and the pluck in style 2, and a duel between them is exactly the question the acquisition rule will ask.

This is not a theoretical objection. A synthetic bimodal user exposed it: the marginalized mixture failed to beat $K = 1$. Adding capacity made the model no better, which is the signature of capacity the likelihood cannot use.

What max-utility buys structurally

There are no discrete latent sites at all. No style assignment to sample, no categorical variables, no label-switching during inference to fight. Every site in the model is an f64, which means fugue’s generic adaptive single-site MH applies unchanged, with no custom kernel and no Rao-Blackwellization.

Label permutation is resolved post hoc instead, by TastePosterior::aligned.

$K$ is an upper bound, not a claim

$K = 5$ by default (SessionConfig::k_styles, in engine.rs), and the fitted number of live styles grows with evidence.

Nothing enforces that; it falls out. A style with no evidence to explain stays near its prior, and style_share reports what fraction of the pool each style actually claims as its best. A style claiming ≈0% is idle: the player’s taste has fewer islands than $K$, and the app dims it rather than inventing a name for it.

So $K$ is capacity, and the data decides how much gets used.

The prior, and the correction $K$ forces

$$\theta_{k,j} \sim \mathcal{N}(0, \sigma_\theta^2), \qquad \sigma_\theta = \frac{1}{\sqrt{d}; s_K}$$