Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Auracle

A playable modular synthesizer that learns what you like, and can show you what it learned.

The launch film: what Auracle is, what it feels like to play, and what is underneath. 1:38 · chapters and transcript

Auracle generates patches by evolutionary search, plays them to you, and asks which one you prefer. From your answers it fits a model of your taste, with uncertainty you can inspect, and uses it to steer the search. Over a session it stops guessing and starts proposing.

It is also just a synthesizer. Four-voice polyphony, a keyboard, MIDI, an arpeggiator, a patchable rack with typed cables and forty-two modules. You can ignore the model entirely and play it like an instrument.

The PATCH view: a patch bank on the left, an eight-module rack wired with green audio cables and amber modulation cables, the node bank catalogue on the right, and a keyboard docked along the bottom.
PATCH. The current patch as a rack you can turn, rewire and lock, running live while you edit it.

What makes it different

Sound design tools usually make you choose. Presets and randomizers are fast and shallow: you audition until something works, and nothing accumulates. Patching from scratch is deep and slow. Genetic-algorithm synths tried to bridge the gap with star-a-generation workflows, but they forget everything between sessions and cannot tell you why they suggest what they suggest.

Auracle treats the problem as inference instead:

  • Every patch is a term in a typed grammar: a tree whose types are signal kinds. Every mutation, every crossover and every edit you make by hand produces a patch that is still valid and still playable.
  • Your taste is a model with a posterior. It is built from a handful of independent style lenses, so you are allowed to like several unrelated things. It carries uncertainty, and it predicts every vote before you cast it, so you can check whether it was right. The TRUST tab is where it reports on itself.
  • The search proposes toward you. What the model learns reshapes how evolution proposes, not only how it scores. Lock the parts you love and refinement leaves them alone.
  • One compiler serves both. The patch you play live is the same one that was evolved, vetted and measured. There is no separate "render version".

For the machinery rather than the workflow, see the Reference, which carries the math.

The shape of a session

Four views, one loop between them.

ViewShowsWhat you do there
PERFORMthe soundPlay it with controls named for what they do; let it wander; hear offers
PATCHthe patchHear it, play it, turn its knobs, rewire it, lock what you like
EVOLVEthe questionTwo candidates; pick one. This is what teaches it
TASTEthe answerWhat it thinks your taste is, how sure it is, whether it has been right

PERFORM is where you play; EVOLVE is where you teach; PATCH is where you open the hood. TASTE is where you go to find out whether it is working.

The shortest version

Open it, pick 3 of 9 presets when it asks, then answer duels in EVOLVE. After a dozen or so picks press EVOLVE POOL and listen to what it bred. That is the whole loop.

What to expect

Auracle is pre-1.0. The instrument is finished enough to play for hours and the taste loop is closed end to end, but:

  • It takes real evidence to learn anything. A handful of duels is not a taste model. Expect the first useful proposals after a dozen or two picks, and confident ones considerably later. From a cold start it takes hundreds of duels, which is why the three-pick warm start exists.
  • It will tell you when it does not know. Early on, TRUST will say the model is not beating a coin flip. That is the display working, not failing.
  • The save format may change between versions. Your session lives in your browser and there is a migration path, but export anything you care about.
  • Desktop only, for now. A phone or small tablet gets a stand-in screen instead; see browser support.

Where to go next

Your first session

Fifteen minutes, start to a model that proposes.

Open the instrument. Nothing to install. Everything below happens in one browser tab, and it all persists when you close it.

0. Boot

The engine compiles, then fills a pool of candidate patches. Each one is generated, compiled, rendered as a fixed five-second phrase, checked for pathology and measured. That is about forty renders, so the boot bar takes a moment.

You do not have to wait for all of it. At 8 patches the first duel is dealt; the rest fill in behind you while you play. On a machine with cores to spare the renders run in parallel.

Nothing plays unvetted

Every candidate is rendered and inspected before it can reach your speakers: finite samples, a peak ceiling, not silent, not DC-dominated. Evolution does produce screaming resonance and silent duds; the gate is why you never hear them. A patch that fails is quarantined, and the search is told to avoid that region.

1. The warm start: pick 3 of 9

A card headed WHICH THREE DO YOU LIKE?, with nine named presets in a three-by-three grid — First Bass, Acid Line, Solo Flight, Coin Toss, Ghost Bell, Morph Pad, Long Room, Ricochet, Wrong Number — each with a one-line description, and SKIP and PICK ANY THREE buttons below.
The warm start. Nine presets, one per family. Three picks, eighteen observations.

On first run you are shown nine presets, drawn one per family from the built-in library and then filled out to nine, and asked to pick three.

Do it. It takes thirty seconds and it is worth 18 pairwise observations: each of your three picks beats each of the six you passed over. That is the difference between a model that has an opinion by the end of your first session and one that does not.

Pick on sound alone. There is no wrong answer and you are not committing to anything; the model treats these like any other preference, and they fade with time like any other.

You can re-run it later from the ⋯ menu → Re-run the three-pick warm start.

2. Answer some duels

Go to EVOLVE. You get two candidates, A and B.

The EVOLVE view: two duel cards side by side, each with a name, a rendered waveform and SAMPLE, BENCH and CHOOSE buttons, under a teaching meter reading 44 picks in.
EVOLVE. Two candidates and one question. The strip above counts down to the next refit.
  • 1 / 2 play the sample: the same fixed phrase for both, so you are comparing patches and not performances.
  • Click a card to play that candidate live on the keyboard instead, if the phrase is not telling you enough.
  • ← / → choose.

Answer ten or fifteen, and go fast. A duel is a gut reaction and the model handles noise; deliberating does not make the data better.

Tip

If neither is any good, that is still an answer: pick the less bad one. What the model learns from a duel is a direction, and "both mediocre but this one less so" is a real direction. There is also skip if a pair tells you nothing.

Watch the strip above the cards. It counts your picks and says when the model will next redraw its map. When it does, the E of the wordmark lights: that is the listening lamp, and it means a fit is running.

3. Look at what it thinks

Go to TASTE.

The TASTE map: a dark field scattered with amber dots of varying size and glow, three named style chips above it, and a legend reading less / would like and sure / unsure.
The map. Every patch you have heard, placed by sound and structure. Glow is how much it thinks you would like it; size is how sure it is.

Early on this will be sparse and the styles will be provisional. Two things are worth checking even now:

  • STYLES. Does any lens have a name that sounds like something you like? The names are generated from what each lens weights, so "drive & fold + chorus" means the model has noticed you leaning that way.
  • TRUST. It will probably say it is not beating a coin flip yet. Good. It is telling you the truth, and that page explains why a plain hit-rate would have lied to you here.

4. Breed a generation

Back in EVOLVE, press EVOLVE POOL.

The model takes your best patches, walks each one a short distance on what it now believes, and injects the children into the pool. The walk samples your taste rather than only climbing it, so most children land above their parent and some land below: those are marked exploring, and your next picks decide whether they were worth it. The EVOLUTION strip below reports what each step did, in plain terms:

gen 31 ⚡ evolution on #90 → #91 · attack 0.59→0.83, decay 0.45→0.28,
release 0.13→0.82, +1 more, +noise, −distortion, −filter · Δtaste +0.65

Then keep duelling. New candidates are in the mix now, and the questions get better as the model gets less uncertain.

5. Keep what you like

Anything worth keeping:

  • ★ stars it. That is an observation, and it teaches the model.
  • save it. That is storage: it moves the patch to my patches and exempts it from eviction. It teaches the model nothing.

Two controls, two different jobs, and it is worth knowing which one you want.

Then what

You now have the loop. From here:

Your whole session (bank, names, taste history, style names, layout) autosaves as you go and restores when you come back. Press ? in the app at any point for the full key map.

Running it yourself

Hosted in a browser, from a release bundle, or from source.

In the browser, hosted

auracle.alexnodeland.com/play/ is the live build. Every push to main deploys it, and so does every tagged release.

Nothing to install, and nothing leaves your machine: the engine is WebAssembly running in your tab, and your bank and taste model live in your browser's storage. There is no account and no server to send anything to.

From a release bundle, offline

Every release attaches auracle-vX.Y.Z-web.zip, the prebuilt instrument, no toolchain required. Unzip it and serve the directory over HTTP:

unzip auracle-vX.Y.Z-web.zip
cd auracle-vX.Y.Z-web
python3 serve.py        # → http://localhost:8642

Any static server works (npx serve, php -S, …), but it must be HTTP, not file://. The instrument uses module workers, and browsers refuse to load those from a file URL.

The bundle is built from the same commit as the tagged live site, so the two are identical.

From source

Auracle's foundations (quiver-dsp, fugue-ppl, fugue-evo) come from crates.io:

git clone https://github.com/alexnodeland/auracle.git
cd auracle
make wasm     # build the engine into apps/web/pkg
make serve    # → http://localhost:8642

You need a Rust toolchain with the wasm32-unknown-unknown target and wasm-pack. make wasm puts ~/.cargo/bin first in PATH: a Homebrew rustc earlier in the path lacks the wasm standard library and fails confusingly.

To work on Auracle rather than with it, see CONTRIBUTING.md.

Use the bundled dev server

make serve runs apps/web/serve.py, which sends Cache-Control: no-store. Plain python3 -m http.server does not, and a browser's heuristic cache will keep serving a stale worker.js or .wasm across rebuilds. That looks like a rebuild that changed nothing, or an engine and a UI from two different commits.

At a booth

For a kiosk or a show floor, turn on Booth mode in the ⋯ menu, or open the app with ?booth on the URL (?booth=30 sets the idle time to thirty seconds; the default is a minute).

  • Attract. With nobody at the keys, the instrument plays itself in PERFORM, cycling through a curated set of patches. It holds a chord progression, moves two named controls under an invisible hand (the XY pad follows), lets Wander turn the knobs, then grows an offer in B and blends it in.
  • Hand over. Any key, click, touch, wheel or MIDI note stops it on the spot. The visitor is holding whatever was playing, with Wander still and Blend home. Nothing attract does is logged or counted as a pick.
  • Next visitor. shift+esc (or New visitor in the ⋯ menu) forgets the taste profile and starts again with the warm start. Booth mode and PERFORM's measured controls are kept, so the demo set stays instant.

Visit the booth set's patches once while setting up (Glass Pad, Acid Line, Loom, Undertow, Sub & Sparkle, Detune Dream, Wobble Board, Cathedral). PERFORM keeps each measurement across reloads, so after that no visitor waits for one. A MIDI controller with eight knobs is picked up automatically: the first eight knobs you turn claim the six named controls, Blend and Wander.

Browser support

Auracle needs a current desktop browser. Specifically it needs AudioWorklet, WebAssembly, module workers and IndexedDB, all of which have been standard for years. It uses them hard.

Chrome / EdgeRecommended. Best worker throughput, and Web MIDI works
FirefoxFully supported. Web MIDI works once you allow its site permission
SafariSupported. No Web MIDI. Boot is slower; render workers are capped

Web MIDI works in Chromium browsers and in Firefox. Without it everything still works from the computer keyboard and the on-screen keys; see Playing it.

Handheld devices

A coarse pointer with a viewport narrower than 620px does not boot the engine. You get a stand-in screen asking for a desktop, with a look around anyway link if you want to see the interface.

This is deliberate. Boot costs about forty audio renders, and a phone would pay for all of them and then have nowhere to draw a rack, a bank and a keyboard at once. A real handheld layout is still to be designed.

Tablets are supported if the viewport is big enough. Every rack gesture works under a finger: knob drags, cable pulls, locks, the ⋯ menus. Anything a mouse reveals by hovering is shown outright on a touch device, because hover-to-reveal on a tablet means never.

What it costs your machine

  • CPU on boot. Around forty renders, spread across min(cores − 2, 6) background workers, or two if the device reports 4 GB of memory or less. Set ?farm=0 in the URL to force the single-threaded path.
  • CPU while playing. Four voices of modular DSP on a real-time audio thread. Modest, but a browser doing heavy work in another tab can cause dropouts.
  • CPU on a refit. Seconds of Markov-chain inference, off the audio thread. You can keep playing through it.
  • Storage. Your session in IndexedDB. Tens of megabytes at most, dominated by the observation log.

Overrides

A few knobs, for when the defaults are wrong for your machine:

?farm=kUse exactly k render workers. 0 is the serial path
localStorage["auracle-renderers"]The same, persisted

The candidate pool is identical at every worker count, including zero: the draw stream is indexed and absorbed in index order. If a worker dies mid-boot, the fill falls back to the serial path over the same draws.

PERFORM — the sound under your hands

Eight controls with names that mean the same thing on every patch, six pads, and nothing that stops to ask you a question.

PATCH shows what a sound is made of: every module, every knob, by address. PERFORM is for playing it. You reach for brighter, not for node/0#cut, and the instrument works out which of this patch's knobs make it brighter.

It is the first tab. The patch is the one already sounding; PERFORM does not load anything of its own. The keyboard dock below is the same one every view shares.

What is on screen

PERFORM on the Ceiling preset: eight round controls in a row (Bright, Snap and Motion in white, Body, Grit and Space in amber, then Blend and Wander), a touch row, six large pads, a B strip saying an offer is waiting, and an under-the-hood list of six knobs with bars and values.

From the top:

The header. The patch's name, a status line, and a small scope. The status line says what PERFORM is doing: measuring how this patch moves…, 4 of 6 controls reach this patch, wander: drift, paused — your hands are on it.

Eight controls in a row. Six named controls (Bright, Snap, Motion, Body, Grit, Space), then Blend and Wander. Each named control is bipolar and its centre is the sound as it is now. A small amber dot on the outer ring shows where the sound measures on that axis, relative to the patches in your session, so a patch that is already very bright has its dot near the right stop.

Six pads. Keep · Back · Offer · Take · Peek · Freeze, below.

The B strip. One line, labelled B, that says whether an offer is waiting and where it came from.

Under the hood. The patch's own knobs that the controls (and Wander) are turning right now, each as a bar with its value in its own units and a tick where it sat when this sound became home. Turn Motion and you watch the envelope's decay and the filter's mod depth move; let Wander drift and the knobs it carries away from home join the list. Click one to open its module in PATCH, pulsing where it is. PATCH shows the sound you last kept: what PERFORM plays is live until you press Keep, and then PATCH has it too.

how this works. A disclosure with a short version of this page. It is closed at rest.

First steps. Until you have done each once, a strip under the header lays out the loop: play a key, turn a lit control, press Offer. Each step ticks off as you do it, and the strip goes away when all three have.

Show measurements in the ⋯ menu adds the numbers behind each control to its tooltip: purity, reach in σ, the verified halves, and the knob gains.

The named controls

ControlLow · highWhat moves in the sound
Brightdark · brightWhere the spectrum's energy sits: its centroid and rolloff
Snapbloom · snapA faster attack and a spikier peak-to-average level
Motionstill · restlessHow much a held note moves, across slow sweeps, pulsing and flutter
Bodythin · fullThe share of energy below about 250 Hz
Gritsmooth · roughHow noisy the spectrum is rather than tonal
Spaceclose · farHow loud the tail is after the notes stop

Each is a direction in what the instrument can hear. The motion bands are what Motion listens to; the rest are perceptual descriptors of the same standard render the taste model hears.

The name is fixed. The knobs behind it are not. The first time PERFORM shows a patch, it nudges each of the patch's knobs once, renders the result, and measures how the sound moved. Each control is then wired to at most four of the patch's knobs, the ones that move the sound most purely in the named direction. A full turn moves any one knob at most half its range.

Hover a control to see which knobs it moves, how purely, and how far it measured. The line under its name lists the knobs.

Measuring costs one render per knob, plus up to four more per control to check the result, so a large patch takes a moment. Until the session's pool has warmed up there is nothing to measure against, and the status line says so.

Turning them

Drag up / downTurn it. The full range is about 180 pixels
shift + dragFine
Double-clickBack to the centre
Near the centreA light detent, so the centre can be found by feel
Long-press (about half a second, without moving)Hear it

Turning a control changes knob values only. The voices take them without a recompile, so a held chord keeps sounding through the turn.

Long-press to hear it

A long-press plays the control to you: over about two and a half seconds it sweeps to the low end, across to the high end, and back to where it was. If no note is held it plays a C3 for the length of the sweep. This is the fastest way to learn what a control does on this patch, since the same name moves different knobs on different patches.

Half-closed controls

Sometimes a control can only go one way. A patch with no movement at all cannot be made stiller, and the knobs that would make it so may do something else instead. On First Bass, turning Motion down made the sound very slightly more restless, which is the opposite of the label.

So every half of every control is checked on real renders before it is offered. A half that did not move the sound the way its word says is closed: the ring is drawn only on the side you can turn toward, the control will not go past the centre on the other side, and the line under it says so:

at the still end

Amber, dashed: search controls

A control drawn in amber with a dashed ring is a search control. This patch's knobs cannot honestly make that change. A patch with no drive cannot get rougher by turning a filter, and a patch with no delay or reverb cannot get much farther away. Measured over the preset library, Grit and Space are search controls on most patches for exactly that reason.

The line under it reads turn to ask for it. Turning it about a third of the way to either end and letting go does one of two things.

Where one change would give it something to turn, that change is made.

ControlWhat it gets
Bright, BodyA tone EQ at the end of the chain (below any reverb, chorus, phaser or flanger), set flat, so the sound does not change until you turn it
Space, turned upA longer amp release (≈250 ms), because every effect here sits before the amp envelope and a reverb's tail is cut at note-off

It goes onto the workbench as one undo step. The patch is measured again, and the control is set to where your hand left it. The toast names what it now turns. The graft is made once per control per patch, and never twice: a patch that already has an EQ does not get a second one.

Otherwise (Snap, Motion, Grit, Space turned down, or a graft that still did not reach it):

  1. The control springs back to the centre. No knob moved.
  2. An offer is grown from the current sound and arrives in B, with a note saying what you asked for.

Grit has no graft because of how it is measured. Grit is spectral flatness, or noisiness. A drive adds harmonics, and harmonics read as Bright. A bitcrusher is transparent only at 16 bits, where turning it changes nothing measurable.

What the offer is and is not

The offer is a variant grown from where you are, on the same walk evolution uses. It is not yet aimed at the direction you turned. It is a structural variant (it may add or change a module), so it can contain the drive or the reverb the patch lacked, but nothing steers it there. Listen before you take it.

Opening the circuit

Everything PERFORM does lands on real knobs, and PATCH shows it while it happens. A knob PERFORM is playing away from its kept value, because a control turned it or Wander moved it, carries a second amber pointer at the value actually sounding, and its readout shows that value in amber. The green pointer is the kept value. Keep writes the amber into the patch, and the two pointers become one. Hover the amber pointer to see which control is turning it.

The XY pad

Under the pads, beside the under-the-hood strip, is an XY pad: two named controls under one finger. It starts as Bright across and Motion up; either axis can be any of the six. Drag to play both at once, double-click to go back to the centre, or use the arrow keys when it has focus (hold shift for fine steps). The pad follows the knobs, so turning Bright on the dial moves the dot too.

Only an axis whose control reaches the patch moves. An amber control's end words are struck through on the pad and a note says so. The pad has no "turn to ask" gesture; use the dial for that.

Blend, Peek and the B slot

An offer is a second patch, loaded into a second voice set that follows the same hands. Every note you play sounds on both. You hear B by crossfading to it, never by a jump:

  • Blend sets the mix, from home at the left to offer at the right.
  • Peek plays B alone for as long as you hold it. Let go and the mix returns to wherever Blend is.
  • Take makes the offer your sound.

The crossfade is equal-power, so the overall level stays roughly steady across it, and B is played at matched loudness: it is normalized to −18 LUFS, the same way every patch is. A louder sound reliably wins a comparison, so without that the crossfade would be a volume knob.

The named controls turn A, the sound you are on. They do not change the offer.

Wander

Wander sets how alive the patch is on its own. It is one dial with four regions, left to right:

RegionWhat happens
stillNothing moves unless you move it
offerEvery 24 seconds or so, if B is empty, an offer is grown into it
driftThe knobs glide to a nearby setting the walk prefers: one move every 36 seconds at the left of the region, every 14 at the right, each glide taking 6 to 4 seconds
roamThe same, with longer walks and so bigger moves: one every 12 to 7 seconds, gliding in 3 to 2

Wander only runs while PERFORM is on screen. When the walk finds nothing it prefers nearby, the status line says nothing nearby it likes better — staying and the sound stays put.

Structure never changes on its own. Drift and roam move knob values only, and they respect the locks you set in PATCH. A new module only ever arrives as an offer in B, and only becomes your sound if you take it.

Hands on, it waits. Touching any control or pad, or moving one from MIDI, pauses Wander for three and a half seconds. A touch in the middle of a glide stops the glide where it is, and the sound stays there. It never snaps back and never finishes the move behind you.

Tap to hold. A short tap on Wander (or the Freeze pad) freezes it where it is. The dial reads held. Tap again to release.

The pads

Pad
KeepMake the sound you hear home. The controls' positions are written into the patch, which goes onto the workbench as one undo step, so PATCH shows it. The controls then re-centre on it
BackGlide back to home, the last sound you kept or loaded
OfferGrow a variant from here into B
TakeMake the offer in B your sound. It becomes home
PeekHold to hear the offer alone
FreezeFreeze Wander. Same as tapping the Wander dial (not the dock's hold, which latches notes)

Keep puts the sound on the workbench. It does not save it to your bank; do that from PATCH as usual.

Nothing opens a dialog

Nothing reachable from PERFORM opens a modal. A player in the middle of a phrase cannot answer a question, so everything PERFORM needs to tell you arrives as a line in the status bar, the B strip or the note lane, and everything it offers you is a pad you can ignore. The comparison PATCH asks for before evolve from this is here as Keep and Back, which you press when you like.

Before you have taught it anything

Offers and drift walk toward your taste. Before there is a fitted model there is no taste to walk toward, so they are drawn from the grammar instead, which is what the model believes before it has any evidence. They still only ever land on patches that pass the vetting gate. PERFORM says which you are hearing:

drifting through the grammar — no taste yet
an offer is waiting, drawn from the grammar — it has not learned your taste yet

Once a model has been fitted, the same lines read drifting toward your taste and grown toward your taste.

What PERFORM teaches the model

An offer you heard and answered is a pick. An offer is the model's proposal played against the sound in your hands, which is the question an EVOLVE duel asks, asked without stopping the music. Once you have heard B, the answer counts:

YouIt records
Take itB over what you had
Press Offer againWhat you had over B

"Heard" means Peek held, or Blend past half, for at least a second while notes were sounding. An offer you take or pass on without hearing it teaches nothing. A Take waits eight seconds before it counts, and its toast has a don't count it button: taking a sound to hear it in place is not always a verdict.

Both directions count, deliberately. A log that only recorded takes would be the model hearing its own proposals agreed with. The answers enter the model exactly as duels do, and they are tagged perform_offer, so TRUST scores them as their own stream (offers you took or passed) beside dealt duels. If answers given mid-performance turn out less reliable than dealt ones, that is where it will show.

Keep, Back, control turns and Wander are still only logged. A Keep might mean I love this or hold on a moment; a turn is a gesture, not a verdict.

MIDI

Plug in a controller and turn its first eight knobs: they take PERFORM's eight controls, in the order you turn them. Channel pressure brightens and the mod wheel drives Motion. See MIDI for the whole map, including learn, endless encoders and soft takeover.

For how the controls are wired and checked, with the measurements, see the reference: Performance: named controls and the drift walk.

PATCH — the patch

One patch, in full, playable while you take it apart.

PATCH shows a single patch as its whole rack: every module, every cable, every knob at its true position. It is running live the entire time. Turn a knob and you hear it on the next note you play.

The PATCH view, with the bank on the left, the rack centre, the node bank on the right and the keyboard docked below.
PATCH. The bank on the left, the rack in the middle, the node bank on the right, the keyboard docked below. Everything here is live while you edit it.

What is on screen

From the top:

The subject block. The patch's name, its id, and a short structural summary (wsqr·mix·cho). The ▶ plays the standard sample.

The toolbar. The edit controls (commit, my edit is better), the layout and view controls (freeform / chain, snap, reset, detail, belief, map), the locks, and ⚡ evolve from this. All covered in Reading and editing the rack.

The next-step chip. An amber line that always says what to do now ("Gen 31 bred new patches — hear them ▸"). It is a suggestion; clicking it takes you there.

The belief row. What the model thinks of this patch and why:

MODEL'S GUESS 0.80 · chorus & sweeps +0.78 · body −0.09 ·
drive & fold −0.08   under your style 2 lens

That is a prediction (how likely you are to prefer it in a duel), the three coordinates contributing most, and which style lens is currently judging it. When the model has no basis for a claim, this row says so instead of printing a number. See Reading what it learned.

Beside it, the budget: 8/24 modules · 4/6 depth · 1/3 mod depth. These are the ceilings evolution searches within. A hand-built patch past them is refused, and one at them has no room left to grow.

The rack. The patch itself. See the rack chapter.

The scope. Bottom right of the frame, tracing the output while you play. Configurable from ⋯ → Scope & analyser… (waveform or spectrum, tap point, FFT size, colour, corner, size, trigger, freeze).

The spec strip. The line under the rack that describes whatever you are pointing at, in the catalogue or in the patch.

HELD. The staging tray. Anything you unplug, delete or bypass lands here instead of vanishing, and stays across a reload. Drag it back onto any lit ○ to put it in.

The quick-pick strip. TEACH plus the current duel pair, so you can vote without leaving PATCH.

The keyboard dock. Playing it.

The three things PATCH is for

Hearing a patch properly

The standard sample is five seconds and identical for every patch, which is what makes candidates comparable. It is not a performance, though. Play the patch from the keyboard. Hold a chord. Run the arpeggiator. A patch that sounds thin on the sample can be excellent under your hands, and the sample cannot tell you that.

Changing it

Every knob is live and every structural edit is a grammar operation, so you cannot break the patch into something unplayable. Drag knobs, click selectors, drag cables between typed jacks, arm a module from the catalogue and place it. Undo with ⌘Z.

Changes are staged until you commit. Committing inserts the edited patch into the bank as a new candidate, leaving the original alone.

This is the part that is easy to miss. Lock the knobs or the wiring you like, then press ⚡ evolve from this: refinement mutates everything except what you locked. Locked addresses are excluded from the search outright. See locks.

An example

Find a patch whose character you like but whose envelope is wrong. Lock every knob except the envelope. Evolve. You get variations that differ only where you allowed them to.

Getting a patch here

  • Click any row in the bank.
  • Click the ⌖ on either side of a duel in EVOLVE.
  • Click any dot on the taste map.

All three land the patch on the workbench, live and editable.

EVOLVE — the duels

Two candidates, one question, and the machinery that turns your answer into a better next question.

Two duel cards side by side with rendered waveforms, SAMPLE / BENCH / CHOOSE controls, a teaching meter above and a generation lineage log below.
EVOLVE. Two candidates and one question. The meter above counts down to the next refit; the strip below says what the last generation changed.

The duel

Two cards, A and B. Each carries a name, an id, and its rendered waveform. The names are generated from what the patch is, so Round Wash and Gritty Swell mean something.

1 / 2, or ▶ SAMPLEPlay the standard five-second phrase
Click the card bodyLoad that candidate live on the keyboard
← / →, or CHOOSE A/BVote
⊕ BENCHSend it to the workbench in PATCH without voting
↻Deal a different pair
skipThis pair is uninformative; do not record anything

Both sides play the same phrase. That is the point: audio features are only comparable across patches under an identical stimulus, so the sample is a fixed five seconds: a held C4, a C5 stab, a C4+E4 dyad, and a low C3 with a long release tail. The reference explains why each segment is there.

Clicking the card instead gives you the patch live under your hands, which is often the faster way to tell two near-ties apart.

Vote fast

A duel is a gut reaction. The model is built for noisy answers and averages over them; a carefully deliberated vote is not worth more than a quick one, and deliberating is how a session stops being fun. If you cannot tell, press skip. A coin flip recorded as a preference is worse than no data.

The teaching meter

The strip above the cards is the session's state of play:

The teaching meter: six pips, then the line 44 picks in. Every 6 it redraws your taste map. Beside it, ◇ unbiased probe — picks like this one score the honesty meter, a skip button, and EVOLVE POOL at the right end.
The teaching meter. Six pips to the next refit, the count so far, and a mark on the duels that were drawn at random rather than chosen.

The pips count down to the next refit. Between refits your votes still count: each one is folded into the model immediately by reweighting, so the next question responds to the last answer. A refit is the expensive version: full Markov-chain inference over the whole log, a few seconds, off the audio thread. When one runs, the E of the wordmark lights.

◇ unbiased probe marks a duel that was drawn at random rather than chosen. Those are the ones that can score the model's honesty without circularity. See TRUST.

Why the pair sometimes looks like a near-tie

Because it often is one, on purpose. A pair the model already knows the answer to teaches it nothing. The default pairing is uniformly random over the pool, which makes every duel an unbiased calibration sample. There is also an information-seeking mode that deliberately serves near-ties. Either way, "these two sound similar" frequently means "this is a question worth asking".

EVOLVE POOL

Breeds a generation.

The engine takes the ten highest-scoring patches in the pool and runs a short Metropolis–Hastings walk from each, mutating structure and parameters with the proposal distribution tilted by what your taste model has learned, then injects the children. Weakest members are evicted to make room; anything you have saved is exempt.

It is local hill-climbing on what the model believes, not a draw from the target distribution. In practice that means children resemble their parents, and a generation moves the pool rather than replacing it. The reference is precise about this.

Nothing happens if there is no fitted model yet; there is no direction to climb in. Answer some duels first.

The EVOLUTION strip

What each generation did, per step:

gen 31 ⚡ evolution on #90 → #91 · attack 0.59→0.83, decay 0.45→0.28,
       release 0.13→0.82, +1 more, +noise, −distortion, −filter · Δtaste +0.65
gen 30 ✎ your edit on #49 → #90 · leaf processor→source,
       mod depth 0.24→0.30, mod follower→no mod, +vco, −delay

Parameter moves are named and shown as before→after; structural moves as +module / −module. Δtaste is how much the model's estimate of the patch moved. The sparkline to the left is the pool's utility over generations.

Hand edits appear here too, tagged ✎ instead of ⚡. The lineage records everything that produced a patch, not only what the machine did.

A working rhythm

  1. Answer duels until the meter fires a refit. Ten to fifteen is a good first batch.
  2. Check TASTE. Has a style separated out? Is TRUST improving?
  3. EVOLVE POOL and listen to the children.
  4. Repeat. When a child is genuinely good, take it to PATCH, lock what you like, and ⚡ evolve from this for variations around it.

TASTE — the model's mind

Four views of one posterior: where your patches sit, what your styles are, what each one listens for, and whether any of it should be believed.

TASTE is full-screen and read-only. Nothing here changes the model; it is the model reporting on itself.

The style chips across the top are shared by all four tabs. Each carries a generated name, its share of the bank, and a ▸ that auditions that style's exemplar. Click a chip's name to rename it. The name persists and is used everywhere the style is mentioned.

MAP

A dark field scattered with amber dots of varying size and brightness, three style chips above, and a legend reading less / would like and sure / unsure.
MAP. Every patch you have heard, placed by sound and structure. Glow is how much it thinks you would like it; size is how sure it is.

Every patch you have heard, placed by sound and structure. It is a 2D projection (principal components of the feature space), and the footer tells you how much of the variance those two axes capture, typically around half. Worth knowing before you read too much into a distance.

The orientation is pinned, so the map does not mirror itself between one recompute and the next — somewhere you recognise stays where you left it. The axes themselves still turn slowly as your taste and the bank move, because they are computed from the patches you have actually heard.

ChannelMeans
GlowPosterior mean utility — how much it thinks you would like it
SizePosterior uncertainty — how sure it is
HueWhich style lens claims it

The size channel is easy to miss and it is the useful one. A big dim dot is "I have no idea about this". A small bright dot is "I am confident you like this". Early in a session everything is big; that is what a cold start looks like.

Click any dot to open that patch on the workbench.

STYLES

Three named style lenses stacked vertically, each with a pool-share percentage and five horizontal amber bars naming its strongest coordinates.
STYLES. Each lens with the share of the pool it claims and the five coordinates it weights hardest. A lens at ≈0% is idle.

Your taste as separate lenses. Each shows its name, the share of the bank it claims, and its strongest coordinates.

This exists because taste is not one direction. You are allowed to like dark drones and bright plucks, and a single linear model would average them into a preference for neither. Auracle fits up to five lenses and scores every patch as its best lens's opinion, so a duel across two islands is still a well-formed comparison.

Lenses appear as evidence arrives. Early on you will have one; more separate out as the model finds structure it cannot explain with fewer. A dim lens claiming almost none of the bank is idle. Your taste has fewer islands than the model has capacity for, which is common and not a fault.

DIRECTIONS

A coefficient plot: named perceptual coordinates down the left, horizontal amber bars extending left and right of a centre line, each with a thinner whisker showing the credible interval.
DIRECTIONS. Every coefficient with its credible interval. A long bar whose whisker crosses the centre line is a guess, and the display says so.

What each lens listens for, coordinate by coordinate. Bar length is the weight; the thin whisker behind it is the credible interval.

Read the whiskers, not the bars. A long bar with a whisker that crosses the centre line is a coefficient the model has not established: a guess that happens to be pointing somewhere. A short bar with a tight whisker is a real, small preference. Both are shown, because hiding the uncertainty is how a model starts sounding more certain than it is.

The coordinates are named in perceptual and structural terms: chorus & sweeps, drive & fold, body, amp attack, mod density. Where a coordinate is what one of PERFORM's controls is made of, it carries that control's word: body is bass weight, grit is spectral flatness, space is the tail, snap is the crest. The reasons the model gives and the knobs you play say the same thing. What each coordinate measures is in the reference.

TRUST — is its confidence honest?

A reliability diagram: dots plotted against a dashed diagonal labelled perfectly honest, each with a vertical whisker and a sample count, above a line reading 33 forecasts, Brier 0.268, not beating a coin flip yet.
TRUST. Forecasts against outcomes. On the dashed diagonal the model is exactly as confident as it deserves to be; the whiskers say how little each dot is standing on.

This is the tab that makes the rest trustworthy.

Every duel is forecast before you answer it. The model commits to a probability that A wins, then your answer arrives. Those are out-of-sample, one-step-ahead predictions, and this diagram scores them: the dashed diagonal is the model's claim, each dot is what happened at that confidence level, and the whisker is how much a bucket that size could wobble by chance.

Underneath, the numbers:

  • Brier score. Mean squared error of the forecasts. Lower is better; 0.25 is what always saying "50/50" scores. Reported as skill against that baseline, so 0 means no better than a coin and 1 means perfect.
  • check duels. The same score restricted to the randomly-drawn probes. This is the number without an asterisk.
  • hit rate. Kept so you can see how misleading it is.

Why not just show accuracy

Because accuracy is not a proper scoring rule, and here it would lie. A model that says 0.51 every time and is right 51% of the time scores exactly like one that says 0.99 and is right 51% of the time. Worse, an information-seeking pairing rule deliberately asks near-ties, so the hit rate is pinned near 50% by construction: a perfectly calibrated model would look like a coin flip and you would conclude it had learned nothing. Brier skill moves when sharpness improves, which is what you want to watch.

Split out at the right, the same scores by where the answer came from: dealt duels, edits you heard, edits you only asserted, and offers you took or passed in PERFORM. A hand edit you committed after listening and one you committed by ticking my edit is better make the same claim in the log, and there is no reason to assume they are equally reliable. This is how you find out.

"Not beating a coin flip yet (n=33)" is the correct thing to see early. It means the display is honest and you have not yet given it enough to work with. Keep duelling.

The patch bank

Three separate collections, each with its own rules.

The bank rail: three bank tabs — evolution 40, my patches 1, presets 61 — above a list of rows, each with a name, prediction percentage, play button, five stars and a save icon.
The bank rail. Three collections, and a row for each patch carrying what the model predicts you would say about it.

The rail on the left holds three of them:

BankWhat it is
evolutionThe live pool the model reasons over and breeds from
my patchesWhat you saved. Yours, permanent, never evicted
presetsThe hand-made library, browsed in place

The ? in the bank head walks you through what a generation is and what evolving costs.

Reading a row

Each row carries a name, an id, a prediction, stars and a save control:

One bank row, outlined in green because it is the row the cursor is on: a diamond glyph, the name Round Wash, the prediction 80% and the id #35 on the right, and below them a play triangle, five filled stars, a save icon, and a horizontal bar drawn at the same 80%.
One row. The green outline is the row you are on. Everything else on it is described below.
  • The name is generated from what the patch is, and you can rename it.
  • The percentage is the model's prediction: roughly, how likely you are to prefer this patch in a duel. It is blank when the model has no basis for a claim.
  • The bar under the row is the same value, drawn.
  • ▶ plays the standard sample.
  • ★★★★★ rates it. This is an observation and it teaches the model.
  • 💾 saves it. This is storage and it teaches nothing.

Stars are not saves

Two controls, two unrelated jobs.

★ is a judgement. It enters the observation log as an ordinal rating and moves the taste posterior. Rate honestly, including rating things low.

save is storage. It copies the patch into my patches and exempts it from eviction. It records nothing about your preferences.

Merging them is tempting and wrong. The pool evicts its lowest-utility members, so the moment a rating decides what survives, people rate strategically to protect patches, and every protective over-rating is a preference you never held.

If you like it, save it

The evolution pool is a working set with a fixed size, and breeding a generation evicts its weakest members. A patch you starred but did not save can be evicted. Stars are for teaching; save is what keeps.

Eviction and pins

The pool holds 40 vetted candidates. Injecting children removes the weakest to make room, by posterior utility.

(The engine's library default is 48; the web app asks for 40. If you see 48 quoted in the reference, that is why.)

Saving pins a patch so eviction skips it. Pins are capped at a quarter of the pool, so it can never be pinned solid and leave the search nowhere to put new candidates. The head shows your pin budget when you are near it.

Presets

Sixty-two hand-made patches across seven families — bass, lead, keys, pad, texture, perc, weird — browsed in place: clicking one loads it on the workbench without adding it to the pool.

They are worth playing through early even if you intend to evolve everything. They are what the warm start samples from, and they cover the palette's range more evenly than the prior does.

Keyboard

The bank is a single tab stop. Reach it with Tab, then:

↑ ↓Move the cursor
EnterOpen the patch
1–5Rate
mSave

The save key is m rather than s because s is a note in the computer keymap, and note letters get through even when a control has focus. Binding save to it would have played a D every time.

Rows announce their full state to a screen reader (name, id, saved, rating, prediction), because the row's buttons sit outside the tab order and the label has to carry what they encode.

Reading and editing the rack

Every knob is an address in the genome, which is why turning one teaches the machine something.

Rack detail: wavefolder, mix, chorus and wavetable modules with labelled knobs reading FOLD 49%, RATE 8.23 Hz, BAL +4.0 dB, MORPH 85%, joined by green audio cables and amber modulation cables ending in named destinations PITCH, THRESHOLD, DEPTH and MORPH.
Two cable colours, two meanings. Green carries audio; amber carries modulation, and its cable says what it lands on.

Reading it

Green is sound. Amber is the model's mind, and modulation. That rule holds everywhere in the instrument.

  • Modules are plates with a title, a ⋯ menu, and their controls. Knobs wear a value arc and read in musical units (840 Hz, 24 ms, −6.0 dB, +12 ¢, 8.23 Hz) rather than a normalized 0–1, because you are being asked to make a musical judgement and 0.63 is not one.
  • Jacks are small rings labelled in / out. Their colour tells you the signal kind, and only matching kinds will connect.
  • Audio cables are green and run left to right through the signal chain.
  • Modulation cables are amber, and each one ends in a named destination: PITCH, THRESHOLD, MORPH, DEPTH. A modulation cable pulses at its modulator's rate, so you can see a 0.2 Hz sweep before you hear it.
  • The last module is always ENV / OUT: the amp envelope and the output stage. Every patch has one, with a limiter compiled in ahead of it that you cannot remove.

The rack scales to fill its frame and centres itself. At small sizes the detail auto setting drops knobs from plates once they are too small to grab, so a very large patch shows as bare plates until you zoom in.

HomeFit the whole patch
.Fit what you are on
⌘0Actual size
⌘− / ⌘=Zoom out / in
ctrl + wheel, or pinchZoom at the pointer
wheel, or drag on bare canvasPan
space + drag, or middle-dragPan from anywhere on the canvas
mapShow the minimap, bottom-left
shift-click the minimapBookmark a spot
shift + 1–9Jump to a bookmark

Zoom runs 0.30×–2.50×, and it fits to the frame on load (capped at 2.2× there).

Turning knobs

Drag a knob, or focus it and use ↑/↓; hold Shift for fine. Click a selector (saw, square, −2 oct) to cycle it. A step sequencer's bars are knobs too: press one where you want the step to sit and drag (more on the step sequencer).

Every edit is a one-site write at that knob's trace address. The patch is re-rendered and re-vetted before it can be auditioned, and the live instrument is re-patched immediately so held notes keep sounding.

Edits are staged. The toolbar's commit inserts the result as a new candidate, leaving the original intact. ⌘Z / ⇧⌘Z undo and redo.

my edit is better is a separate claim. Ticking it teaches the model an "edit beat original" duel, which the TRUST tab scores separately from duels you actually listened to.

Hit targets are bigger than they look

A knob's whole face is grabbable, including under its ticks and value arc, and a jack's ring responds across its full diameter. If you remember these feeling fiddly, try again.

Layout

The first button cycles three layout modes, and its label shows the one you are in:

chainThe signal path on one baseline
compactThe same path, packed tight
freeformYours. Drag a plate by its faceplate and it snaps to the grid; hold shift to place it freely

Then:

snapPin everything where it currently sits, on the 24px grid. This is how you start hand-arranging an evolved patch
resetThrow away the hand positions and re-lay along the signal chain
detailauto drops knobs when plates get too small to grab; force it on or off
beliefTint each plate by what the model believes about its family: amber toward, red away, stronger where it is certain. Off by default

Positions are kept per patch, survive a reload and a generation of ⚡, and travel inside an exported patch file. If a hand layout has spread past anything the frame can show, snap re-lays it from the signal chain instead of pinning it somewhere you cannot see.

Locks, and evolving from here

  • Click a knob's lock dot to freeze that knob.
  • Click a module's ▢ to freeze the whole module.
  • lock knobs / lock wiring freeze every parameter, or the whole structure.
  • clear locks releases everything.

Then ⚡ evolve from this: refinement mutates everything except the locked addresses.

A proposal that would change, delete or create any locked address is rejected. Both directions matter: allowing a birth at a locked address while rejecting the death that would undo it lets the search drift into locked structure and stay there.

One limit. A lock is a set of exact addresses, so a structural move that grows a brand-new address inside a locked module is not caught, because that address existed in neither version. "Locked" is a promise about addresses, not about subtrees.

The ⋯ menu

Per module: bypass, delete, replace with…, insert after….

The last two hand off to the node bank with the socket already chosen and lit, so there is one module inventory in one place.

Anything you bypass or delete goes to the HELD tray rather than disappearing, and stays there across a reload.

Exporting a patch

From ⋯ → Export this patch (JSON) or Export as image… (PNG or SVG, at a scale and background you choose). The exported image contains the patch: an Auracle PNG or SVG can be imported back, so a screenshot of a rack is also the rack.

Wiring and the node bank

Forty-two modules, each one honest about what the model does and does not know about it.

The catalogue

The PATCH view with the node bank open on the right: eight groups of modules down a rail, each entry carrying a transfer-function glyph, a name, a port signature and a θ bar, with the formant oscillator's spec card opened beside it.
The node bank, with a card open. Every entry says what it does to a wave, what it takes and gives, and what the model makes of it.

The rail on the right of PATCH is the instrument's inventory: forty-two modules in eight groups, ordered along the signal path: sources → shape → filter → space → motion → dynamics → combine → modulation. That way "what goes after a filter" is a question the ordering answers.

Every entry carries four things at rest:

  • A transfer-function glyph showing what this does to a wave.
  • The name a synthesist would use.
  • A port signature in both phosphors: what it takes and what it gives.
  • A θ bar with a ±σ whisker: what the model thinks of this module. It appears only once the model has been fitted and at least five patches in the pool use it. Below that it draws a dash.

That threshold matters. "The model barely likes this" and "the model has never seen this" are completely different statements and should not look alike.

Searching it

/ focuses the index. It matches by sound as well as by name: grit finds distortion and bitcrush, wander finds sample-and-hold random, vowel finds the formant oscillator.

The spec card

Hovering or focusing an entry opens its card:

The formant oscillator's spec card: a glyph, the name FORMANT, the port map out — audio, mod → vowel, a sentence describing it, its default parameters, a heard-as line, and a note reading in 6 of 40 patches, the model has looked and has no lean either way, θ 0.05 ± 0.17, an interval that straddles zero.
A spec card. What the module does, what it takes and gives, what it arrives set to, and — only where the evidence supports it — what the model makes of it.

Five things:

  1. One sentence in the instrument's voice.
  2. The port map.
  3. The parameters it will arrive with.
  4. What the model believes, with four ways of saying nothing: not measured / not fitted / too few examples / here is the belief, with its interval. The card above shows an interval straddling zero, which means the model has looked and found nothing.
  5. heard as: what the feature extractor can and cannot pick up about this module. Chorus's card says outright that the model will never learn it, because the feature vector has no stereo-width coordinate.

That fifth line tells you when your preference is real but invisible to the machinery. In that case, starring patches that use it will not teach the model what you think it is teaching.

Placing a module

Arm and place is the primary path:

  1. Click an entry. It is now in your hand.
  2. Every socket it can legally go into lights up and names what will happen there: green inserts ahead of what is in the socket, amber replaces it.
  3. Click a lit ○ to place. Esc to put it down.

Press-dragging from an entry also works, and a missed drop tells you so.

Every placement is one undo step, and the confirmation toast offers take it out.

From the keyboard

The whole path has a keyboard equivalent:

TabReach the catalogue (one tab stop per group)
↑ ↓Walk the entries
EnterArm the module
↑ ↓Then walk the lit sockets, each one announced
EnterPlace
EscPut it down

Dragging cables

Drag from an out jack. As you drag:

  • Every legal input lights up. Illegal ones do not, and the dragged module's own subtree is excluded, so you cannot create a cycle.
  • The cable snaps within a tolerance.
  • Dropping into empty space opens the catalogue filtered, with the socket pre-chosen.
  • An illegal drop says why.

Click-source-then-click-target reaches the same place, with roving focus.

If you drop an output onto something that already has a consumer, you get a pinned two-choice offer naming both consequences in plain English: "A copy: one output cannot feed two places."

Modulation chains

A modulation input does not take "an LFO". It takes a modulation term, which can be a chain: s&h rand → quantize → slew before it ever reaches a cutoff. The rack draws the whole chain in amber.

Consequences in the interface:

  • Dropping a CV shaper onto an occupied slot wraps what is already there rather than evicting it.
  • The socket tells you which of fill / replace / wrap you are about to do.
  • Depth is bounded, so a modulation cannot be wired to swamp its destination.

The step sequencer

steps is the one modulator you draw rather than dial. Under its three knobs (rate, length, glide) sits a row of eight bars, one per step: press a bar and drag up or down to set that step, or focus it with the arrow keys and use Up/Down like any other knob. The line through the middle is "no push"; a bar above it pushes the destination up, a bar below pushes it down.

Cable it to a cutoff, a wavefolder or a wavetable's morph and the timbre plays a rhythm of its own. Glide at zero gives hard steps; turned up, each step slides into the next.

length decides how many of the eight bars play. The ones past it are greyed but not gone: they stay in the patch, you can still set them, and lengthening the pattern brings them back. Evolution treats every bar as its own knob, so it can change one step of a pattern without touching the others, and a lock on a bar (press L with it focused) holds that step while the rest evolve.

Nearly every module carries a modulation slot with a named destination; on the oscillators the slot bends pitch. The exceptions are the ones with nowhere sensible to send it: noise, whose only control is a colour switch, and mix and ring mod, whose two inputs are both audio and whose single knob is the blend.

Binary modules

Six processors take two inputs, and the distinction matters when you wire them:

Second input
mix (crossfade), ring modaudioMerges two chains into one
comp, duck, gate, vocodercontrolReal sidechaining, in a typed tree

In the second group the second input is a control signal, not audio, and the rack will not let you wire it as though it were.

IN THIS PATCH

Above the catalogue, what the current patch is made of. Clicking a pill jumps to that module in the rack.

The HELD tray

Anything you unplug, delete or bypass goes here, and stays across a reload. Drag it back onto any lit ○ to put it in.

Collapsed, the rail keeps its name and the count of what is held below it, so staged work is never hidden silently. The rail's width, its collapsed state, and which groups are folded all persist.

Playing it

Four voices, three ways in, and an arpeggiator.

The current patch is always live: four-voice polyphony, with oldest-note stealing and silent-tail voice parking. Every edit you make on the rack re-patches the running instrument, so held chords survive a patch change without a click.

Three ways in

The on-screen keys

Mouse or touch, with glissando — press and slide. The keybed shows the computer keymap on the keys it covers.

The computer keyboard

An Ableton-style layout:

white:  a  s  d  f  g  h  j  k  l  ;  '
black:   w  e     t  y  u     o  p

z / x shift octave, from a = C0 to a = C7, so the letters reach C0 to C8: an 88-key piano's compass, and a few notes below. The left of the dock always shows the current anchor (a = C4).

Letters only play when the interface does not want them

Note letters reach the synth only when focus is not in a control, and they get through even when it is. That is why m saves a patch in the bank instead of the obvious s: s is a note, so binding save to it would have played a D every time.

MIDI

Plug in a keyboard and it works: velocity, pitch bend and the sustain pedal. The dock's right side shows the MIDI state; click midi there for the mapping panel.

A controller with knobs works too, with nothing to set up. The first eight knobs you turn claim PERFORM's eight controls in the order you turn them, and the panel's learn remaps any of them. Endless encoders are recognised from what they send. Ordinary pots pick a control up as they pass through its position rather than snapping it, which matters because Wander moves the controls under a pot that has not moved. Channel pressure brightens the sound and the mod wheel drives Motion. Incoming MIDI clock sets the tempo. The mapping is remembered per device.

The sustain pedal sustains. A note you release while the pedal is down keeps ringing until the pedal lifts, and lifting it releases exactly those notes. Notes still under your fingers keep sounding. Strike a sustained note again and it belongs to your finger again. The pedal is separate from HOLD, the dock's latch; it used to be wired to it.

The whole map, including bend range and how encoders are detected, is in Keyboard and MIDI.

Web MIDI works in Chrome, Edge and the other Chromium browsers, and in Firefox, which asks the first time whether to add a site permission for it. Safari has none; there the other two ways in still play. Whenever MIDI is not available the dock reads midi ?, and the MIDI panel says why, with a connect midi button that asks again.

MIDI plays one tab. The browser hands your controller to every tab that asks for it, so with Auracle open twice, the tab you used last plays MIDI and the other stands aside: its dock reads midi ○, and a click anywhere in it takes MIDI back. The computer keyboard already worked that way.

The dock

Control
HOLDLatch: notes stay on until you play them again
◼Panic. Kills every voice immediately
⇕ tallGrow the dock; the rack re-zooms into what is left
keysKeybed width, 1–4 octaves
ARPThe arpeggiator, below
UNI ×4Unison — stack detuned copies per note, trading polyphony for width
gldGlide (portamento) between notes
● RECBounce your playing to a WAV
volOutput level

The keybed width defaults by input device: three octaves for a mouse, two for a finger. The narrow sizes anchor on the computer keymap's octave, so what you see matches what your keyboard plays. Both height and width persist.

The arpeggiator

PATTERNup / down / up-down / random
RATEDivision: 1/4, 1/8, 1/16 or 1/8 triplet
TEMPOBPM
RANGEHow many octaves it walks
GATENote length as a fraction of the division
SWINGShuffle

It is sample-accurate: it runs inside the audio engine rather than on a page timer, so it does not drift and it does not stutter when the interface is busy.

SYNC (next to ARP) puts a patch's step sequencers on the same tempo. Each one plays the musical division nearest the speed it was evolved at, so a pattern that ran at 3.7 steps a second becomes 8ths at 120 BPM, and all of them restart together with the first key you press, on the same beat the arp starts. MIDI start restarts them too, and from then until a MIDI stop the clock pulls them back onto its beat once a beat. A five-step pattern still cycles against the bar; that is the point of it. Turning a sequencer's rate knob with sync on moves it between divisions rather than off the grid. Sync changes only what you hear live: the model still auditions every patch free-running.

Recording

● REC captures your playing to a WAV: the real output, post-limiter, at the session sample rate. Press it again to stop; the file downloads.

This records performance, not the standard sample, and it is the right way to capture a patch you like. The five-second audition phrase exists to make patches comparable to each other.

Per-patch loudness

Every patch is loudness-normalized (to −18 LUFS) before you hear it, in audition and in feature extraction.

Louder reliably wins A/B tests, so without normalization the taste model would learn "I like loud" and dress it up as a preference about timbre. If a patch seems quieter than you expect, that is the normalization working.

If it does not make sound

In order of likelihood:

  1. The pool is still warming up. The first duel is dealt at 8 patches.
  2. No patch is loaded. Click a row in the bank.
  3. The browser has not granted audio. Browsers require a gesture before starting an audio context. Click anywhere, or press a key.
  4. The patch is muted as unvetted. A pinned strip says so, and stays visible until it is resolved.
  5. Voices are stuck. Press ◼.

More in Troubleshooting.

What the model learns from

Four kinds of answer, one model, and a few things that feel like teaching but are not. A duel can be dealt in EVOLVE or answered while you play in PERFORM.

The taste model, animated: what it hears, what a pick tells it, how it keeps score, and how it searches. 1:49 · chapters and transcript

The four signals

Everything you tell Auracle enters one observation log and conditions one latent quantity: a utility u(x)u(x), "how much this person would like patch xx". The signals differ only in how they connect an answer to that utility, and there are three ways: a duel, stars and keep/kill.

SignalWhereWhat it says
A/B duelEVOLVE, or the quick-pick strip in PATCHAA scores higher than BB
an offer answeredPERFORM: Take an offer you heard, or ask for anotherThe same duel, between the sound you were playing and the model's offer
★ starsAny bank rowThis patch's utility falls in the band that rating covers
keep / killA bank row's cut (kills only)This patch is above / below where I'm drawing the line today
edit beats originalmy edit is better, on commitThe same duel: my edited version scores higher than what I started from

Duels are the primary signal. They have the best statistical properties and the lowest cognitive load: people compare two things reliably, and assign absolute numbers to one thing inconsistently, including against themselves an hour later.

If you only ever do one thing, do duels.

About stars

A star rating is not treated as the number three. It is treated as "this patch's utility sits between two learned cutpoints", and the cutpoints are fitted alongside everything else. That is what makes the scale survive drift: if you go through a generous phase and then a harsh one, the model can move the cutpoints instead of concluding your taste changed.

Rate honestly, including low. A star is a judgement, and rating things you dislike is information.

About keep / kill

Keep/kill is modelled against a per-session threshold the model also fits. "Feeling picky today" is represented rather than treated as noise, so a session where you kill almost everything is read as a strict session rather than a change in your taste.

A bank row's cut records a kill once its seven-second undo window closes; undo inside it and nothing is recorded. Nothing records a keep yet: the triage screens that would emit one have not been built.

What is not a signal

Listen time, replays, exports and how long you hovered are not recorded as preferences. They are cheap to collect and easy to misread: a long listen can mean fascination or confusion.

Saving a patch is also not a signal. See stars are not saves.

In PERFORM, only an answered offer is a signal. Taking an offer you heard, or asking for another after hearing it, is a duel (above). Keep, Back and control turns are logged with your session and not fitted. See what PERFORM teaches the model.

The warm start

On first run you pick 3 of 9 presets.

That single ~30-second interaction is worth 18 pairwise observations: each of your three picks is recorded as beating each of the six you did not pick. It exists because the cold start is severe. From nothing it takes hundreds of duels, and eighteen observations before you have answered a single one is the difference between a model that has an opinion by the end of your first session and one that does not.

The nine are drawn one per family first from the 62-patch library, then filled from what is left, so the first thirty seconds span the space rather than landing in one corner. Only those nine are loaded, which keeps the first run short and most of the pool free for what the search finds.

Re-run it any time from ⋯ → Re-run the three-pick warm start.

When it learns

Two mechanisms, at two speeds.

Between refits: reweighting. Every vote is folded in immediately by importance sampling, where the draws the model already has get reweighted by how well each one predicted your answer. It costs almost nothing, and it is what makes the next question respond to the last answer. Without it the pairing rule would read a frozen model and re-ask the same question until the next full fit.

At a refit: inference. Full Markov-chain inference over the entire log, a few seconds of work off the audio thread. This is where the model can change its mind, discover a new style lens, or re-fit the star cutpoints.

The teaching meter counts down to the next refit: at most every six duels, and only when the between-fit reweighting has run out of road. That condition is measurable. The effective sample size of the reweighted draws falls as the weights concentrate on fewer and fewer of them, and once it has collapsed far enough the model would be claiming more certainty than it has. That is the trigger to pay for a real fit. The wordmark's E lights while one runs.

Recency

Old votes fade. An observation h places back in the log carries weight

wh=0.5 h/150w_h = 0.5^{,h / 150}

so about 150 observations ago is worth half as much as your latest. Your taste is allowed to change, and a model that weighted a vote from three sessions ago equally with one from a minute ago would fight you when it did.

How long what you told it keeps mattering. At a half-life of 150, a vote from three hundred observations back still carries a quarter of a fresh one's weight.

What moves the model most

Roughly in order:

  1. Duels between genuinely different patches. The most information per answer.
  2. The warm start. Eighteen observations for thirty seconds, available once per reset.
  3. Duels the model got wrong. A surprising answer moves a posterior further than a confirming one. This is also why the pairing rule serves near-ties.
  4. Stars, in volume. Weaker per observation, but cheap, and they anchor the absolute scale that duels alone cannot pin down.
  5. Hand edits committed with my edit is better. These carry a lot: a direction in genome space, and the claim that the direction was good. TRUST scores them separately, because an asserted improvement and a heard one may not be equally reliable.

What it cannot learn

Worth knowing, so you do not spend a session teaching something that cannot be received.

The model sees each patch through a fixed set of measurements: eighteen perceptual descriptors of a standard render plus twenty-six structural counts. If a preference is not visible in those coordinates, no amount of voting will convey it. The clearest case is stereo width: the feature vector has no coordinate for it, so the model will never learn that you like chorus for its width. The chorus module's spec card says so in its heard as line.

Preferences about performance are largely invisible too — how a patch responds to velocity, how it behaves in a fast run — because the audition phrase is fixed and modest. What the phrase does and does not reveal is spelled out in the reference.

How to check

Before spending a session teaching a preference, read the heard as line on the modules involved. If it says the model cannot pick it up, believe it, and use save and your own naming instead.

Reading what it learned

How to tell a real preference from a coefficient that happens to be pointing somewhere.

For a technical audience: the taste model and the search as the code computes them, and why each piece has the form it does. 2:46 · chapters and transcript

The TASTE view documents what each tab shows. This page is about reading it well: the interpretation mistakes that are easy to make, and how the interface tries to stop you making them.

Four states, and what each means

The instrument distinguishes four, and never lets two of them look alike:

It saysIt means
not measuredThe feature vector has no coordinate for this. It never will
not fittedNo posterior yet. Answer some duels
too few examplesFewer than five patches in the pool use it. Not enough to fit a coefficient
a value ± an intervalHere is the belief, and here is how much to trust it

A dash is not zero. "The model is indifferent to this" and "the model has never had a chance to form a view" are different statements, and one grey bar cannot say both.

Read the interval, not the bar

The single most useful habit.

In DIRECTIONS, every coefficient is drawn with a credible interval behind it. If the interval crosses the centre line, the model has not established that coordinate: the bar is a guess that happens to point somewhere, and it will likely point elsewhere after ten more duels.

A short bar with a tight interval is worth more than a long bar with a wide one. The former is a small preference the model is sure of; the latter is noise with confidence.

Drag the evidence slider. Early on every interval straddles zero, and the individual bars mean nothing even though they point somewhere. As observations accumulate the intervals narrow and coefficients start clearing zero one at a time. Red whiskers are the ones that have not.

The same logic runs the node bank's θ bars, which is why they draw a dash below five supporting patches. A coefficient fitted from three examples would otherwise look exactly like one fitted from three hundred.

Size on the map is uncertainty

On the MAP, glow is how much it thinks you would like a patch and size is how unsure it is. People read glow and ignore size.

  • Small and bright. Confident it is good. Worth playing.
  • Big and bright. It might be excellent. This is where to explore.
  • Small and dim. Confident it is not for you.
  • Big and dim. It knows nothing. Also worth exploring, for a different reason.

Early in a session everything is big. That is what a cold start looks like, and it is why the first generation you breed is not very targeted.

Also read the variance footer: the two axes typically capture around half the variation in the feature space, so two dots close together are probably similar and two far apart are probably different. It is a projection, not a map of the territory.

Styles are lenses, not genres

A style lens is a direction in feature space that explains some of your answers. It is not a genre and it is not a mood. The generated names (drive & fold + chorus, dynamics + plucked strings) describe coefficients, not music.

Two things follow:

  • A lens claiming almost none of the bank is idle. The model fits up to five and lets the data decide how many get used. Having two live lenses and three idle ones is not a failure; it means your taste, as measured by these coordinates, has two islands.
  • You can rename them, and should. Click a chip's name. Once *"drive & fold
    • chorus"* is "the mean one", every place the style appears becomes readable at a glance. The name is yours and it persists.

The prediction on a bank row

The percentage is roughly "how likely you are to prefer this patch in a duel against an average pool member". It is a posterior mean, so it already accounts for the model's uncertainty by averaging over it, which means a confident 80% and an unsure 80% look identical here.

If you want the uncertainty, that is what the map's size channel and the belief row's interval are for. The row is a ranking aid, not a measurement.

Trust, and what to expect over time

TRUST is the tab that decides whether any of the others deserve belief. A realistic trajectory:

StageWhat TRUST says
First session, < 20 picksNot beating a coin flip. Correct and expected
20–60 picksSkill crosses zero and wobbles. Buckets too small to read
Beyond thatSkill climbs; dots settle near the diagonal

Two failure shapes worth recognising:

  • Dots consistently below the diagonal on the right. It is overconfident: when it says 80% it is right less often than that. Usually a sign it has locked onto a coordinate that was coincidental. More duels, especially ones you expect to surprise it, is the fix.
  • Skill stuck near zero with many observations. Either your preference is not visible in the feature space (see what it cannot learn), or your answers are inconsistent, which happens: some days you are not choosing on one axis.

The number to watch is check-duel skill rather than overall skill. The overall number is measured on questions the model helped choose; the check duels are drawn at random.

Why a low score early is the honest one

Auracle forecasts every duel before you answer it, then reports its own error against a proper scoring rule. A number produced that way can come out badly, and early on it does. That is what makes it worth reading later.

When it is working

You will notice it before the numbers say so:

  • The duels get harder — both candidates are plausible.
  • Generations produce children you want to keep rather than children you want to skip.
  • The belief row's explanation matches your own reason for liking a patch.
  • A style chip's name is one you would have written yourself.

That last one is the real milestone.

Your data

It is in your browser, it is yours, and it never leaves unless you export it.

Where it lives

Everything is in your browser's IndexedDB, under the origin you loaded the app from. There is no account, no server and nothing to sign into. The engine is WebAssembly running in your tab; no audio, no patch and no vote is transmitted anywhere.

Practical consequences:

  • A different browser, or a different machine, is a different session.
  • The hosted build and a locally-served copy are different origins, so they do not share a session.
  • Clearing site data clears your session. So does a browser "clear browsing data" sweep that includes site storage.
  • Private / incognito windows get a session that dies with the window.

What is saved

Autosaved continuously as you work:

The evolution poolEvery candidate, with its features and lineage
my patchesEverything you saved
NamesPatch names and style names you set
The observation logEvery duel, star, keep/kill and edit claim
The posteriorThe fitted model, plus its standardizer
Layout and settingsRack positions, dock size, keybed width, scope config, node-bank state
The HELD trayWhat you unplugged, across reloads

Restore runs across background workers, so a large session comes back without a long stall.

Exporting and importing

All from the ⋯ menu.

Taste profile

Save taste profile writes a JSON file containing the observation log and the standardizer it was recorded under.

Both, always, together. The model's coefficients are only meaningful relative to the scaling that produced them, so a log without its standardizer has lost its units. The log is the source of truth; the fitted posterior can be recomputed from it.

Load taste profile brings one back. This is how you move a taught model to another machine or another browser.

Individual patches

Export this patch writes JSON. Import a patch accepts .json, and also .png and .svg.

Patches as images

Export as image… renders the rack to PNG or SVG at a scale and background you choose. The image contains the patch: an exported Auracle PNG can be imported back and will produce the same patch, so a screenshot of a rack posted in a chat is a shareable patch.

Imported files are content, not code

A patch file names things: its own name, its module labels. Those names are escaped everywhere they are displayed, including when they arrive from an imported file, so opening a patch someone sent you cannot run anything in your session.

Recordings

● REC in the dock bounces your playing to a WAV. That is a normal audio file and nothing about it is Auracle-specific.

Resetting

⋯ → Reset taste profile… clears the observation log and the fitted model. It asks first.

This is the right move when you have been teaching it something it cannot see, or when you want to start a different taste from the same pool. It does not clear my patches; saved patches are storage, not evidence, and they survive a taste reset.

To clear everything, clear the site's data in your browser.

Version changes

Auracle is pre-1.0 and the save format may change between versions. There is a migration path: sessions written by older builds are upgraded on load, and observations recorded under an older audition phrase keep their structural coordinates while their old-stimulus audio coordinates are marked "no evidence" instead of being mixed into a scale they were never comparable with.

That said: migrations are code, and code has bugs.

Before updating, export

Save taste profile and export any patch you would be annoyed to lose. It takes ten seconds, and it is the only backup that exists.

Keyboard and MIDI map

Everything bound, in one place. ? in the app shows the same map without leaving it.

Notes

An Ableton-style layout across the bottom two rows:

black:    w  e     t  y  u     o  p
white:  a  s  d  f  g  h  j  k  l  ;  '
a w s e d f t g y h u j k o l p ; 'Play notes
z / xOctave down / up

Note

Note letters only reach the synth when focus is not in a control, so typing in a name field does not play a melody. This is also why the bank's save key is m rather than s.

Global

spaceAudition the current patch
[ / ]Step through the bank
1–5Rate the patch you are on
mSave the patch you are on
pIn presets, play the row
⌘Z / ⇧⌘ZUndo / redo a workbench edit
?Key map and gestures
EscClose a dialog, or put down an armed module

In EVOLVE

1 / 2Audition A / B
← / →Vote A / B
⌘ZTake back a vote

The rack canvas

HomeFit the whole patch
.Fit what you are on
⌘0Actual size
⌘− / ⌘=Zoom out / in
ctrl + wheel, or pinchZoom at the pointer
wheel, or drag on bare canvasPan
space + drag, or middle-dragPan from anywhere
shift-click the minimapBookmark this spot
shift + 1–9Jump to a bookmark

Inside the rack

Tab reaches the rack as a single stop, then:

← →Move between controls
↑ / ↓Turn the focused knob
shift + ↑ / ↓Fine
LLock the focused control

The bank

Tab reaches the bank as a single stop, then:

↑ ↓Move the cursor
EnterOpen the patch
1–5Rate
mSave

The node bank

/Focus the search index
TabReach the catalogue: one stop per group
↑ ↓Walk the entries
EnterArm the module. It is now in your hand
↑ ↓Then walk the lit sockets, each announced
EnterPlace it
EscPut it down

The search matches by sound as well as by name: grit, vowel, sidechain, wander.

Gestures

Drag a knobChange it; you hear it immediately
Click an enum plateCycle it (saw, square, −2 oct)
Drag from an out jackPull a cable; every legal input lights up
Drag a wired in jack off its socketUnplug. The chain goes to HELD
Drag from HELD onto a lit ○Put it back
Click ⋯ on a plateBypass, delete, replace with…, insert after…
Click ▢ on a plateLock the module so evolution cannot touch it
Click a knob's lock dotLock just that knob
Drag a plate by its faceplateMove it (freeform mode); shift to ignore the grid

In PERFORM

A focused control (reach it with Tab):

↑ / →Turn up
↓ / ←Turn down
shift + arrowFine
HomeBack to the centre (Blend: to home; Wander: to still)
EnterHear it: a sweep through both ends and back

With the mouse: drag up or down, shift for fine, double-click to centre, long-press to hear it, a short tap on Wander to hold it. See PERFORM.

MIDI

Plug in a keyboard and it works, with no configuration. Plug in a controller with knobs and they work too.

MessageDoes
Note on/offPlays, with velocity
Pitch bendBends every voice. Range ±2 semitones by default; ±7, ±12, ±24 or ±48 in the MIDI panel
Sustain pedal (CC 64)Sustains. Notes you release while it is down ring until it lifts
Mod wheel (CC 1)Drives Motion, unless you learn CC 1 onto another control
Channel pressureDrives Bright: pressing harder turns it from the centre toward bright
Any other CCThe first eight you move claim PERFORM's controls, in order
MIDI clockSets the tempo
CC 120, CC 123All sound off / all notes off: the same as ◼

Web MIDI works in Chromium browsers and in Firefox, which asks once whether to add a site permission for it. Safari has none; there the computer keyboard and the on-screen keys still play. When MIDI is not available the dock reads midi ?, and the panel says why and offers connect midi to ask again.

With Auracle open in more than one tab, MIDI plays the tab you used last. The others read midi ○ and play nothing from MIDI until you click in one.

The MIDI panel

Click midi in the dock (it reads midi ● when a device is connected). The panel lists PERFORM's eight controls, what drives each, and two buttons per row:

  • learn: the next CC you move is bound to this control. Any CC it replaces is unbound.
  • clear: unbind this control.

Below the rows: a switch for auto-mapping (first knobs you turn claim free controls), the bend range, and the incoming clock tempo.

Knobs you just turn

With auto-mapping on, the first eight distinct CCs you move claim PERFORM's controls in the order you move them: Bright, Snap, Motion, Body, Grit, Space, Blend, Wander. Each claim is announced (mapped: CC 74 → Bright). The mod wheel and the sustain pedal are left out, because they already mean something.

The controls are measured when PERFORM first shows a patch, so a mapped knob moves nothing on a patch PERFORM has not measured yet. Open PERFORM once and the knobs work from any view.

Endless encoders

A relative encoder is recognised from what it sends, with nothing to set. An ordinary pot only sends when its value changes, so it rarely sends the same number twice in a row. An encoder sends the same small tick over and over. Once a CC has sent a few values that repeat like that and sit where encoder ticks sit, it is followed relatively and the note lane says so (CC 21 is an endless encoder). Both common encodings are recognised: two's complement and offset-around-64. One tick moves a control 1% of its travel.

When in doubt it treats a CC as an ordinary pot. A pot mistaken for an encoder would be unusable; an encoder mistaken for a pot is only jumpy.

Soft takeover

An ordinary pot does nothing until it passes through the control's current position. Then it takes over. This is often called pickup.

It matters more here than on most instruments, because the controls move without the pot. Wander drifts the sound and re-centres the controls, and you can turn a control with the mouse or the keys. Without pickup, the first nudge of a pot left at three o'clock would snap a control that is now at nine. Whenever a control moves by the mouse, the keys or Wander, the pots bound to it have to pick it up again.

The mod wheel works the same way. With Motion at its centre, the wheel takes over as it passes its halfway point; below that it makes the sound stiller, above it more restless. Channel pressure is not picked up: it only ever brightens from the centre, and letting go (pressure back to zero) returns Bright to the centre.

Clock

MIDI clock sets the tempo, which is what the arpeggiator follows. The tempo is a least-squares fit over the last two beats of clock ticks, so a single late tick moves it by a fraction of its lateness rather than all of it. It needs one full beat of ticks before it reads anything, updates when it moves by more than 0.4 BPM, and stays within 30–300 BPM. A gap of more than a second is read as a stop rather than a very slow tempo.

Start is a restart: a running arpeggio begins again from its first note if a chord is held, and with SYNC on the step sequencers go back to their first step. From a Start until a Stop, the clock also pulls the synced sequencers back onto its beat once a beat. Stop silences nothing, and continue is ignored.

Per device

The mapping, the auto-mapping switch and the bend range are remembered for each device, or combination of devices, in this browser. Plug the same controller in tomorrow and its knobs mean what they meant today.

Performance controls

Not keyboard-bound, but this is where people look for them:

HOLDLatch notes
◼Panic. Kills every voice
ARPPattern, division, BPM, octave range, gate, swing
UNIStack all four voices, detuned
gldGlide between single notes; chords stay clean
● RECBounce your playing to a WAV
⇕ tallFull-height keybed
keysKeybed width, 1–4 octaves

Accessibility

What works, how, and what does not yet.

Auracle is a dense expert tool. Coverage is uneven, and this page says where.

Keyboard

Everything structural is reachable from the keyboard, including wiring.

The design principle is one tab stop per region, arrows inside it. Tabbing through several hundred rack controls would be unusable, so the bank is a single stop, the rack is a single stop, and the node bank is one stop per group. Arrows move within.

The full map is in Keyboard and MIDI. The path most worth knowing is placing a module without a mouse:

Tab to the catalogue → ↑↓ to a module → Enter to arm it → ↑↓ walks the legal sockets, each one announced → Enter places it.

Focus is always visible, and dialogs return focus to whatever opened them.

Screen readers

  • The bank announces its cursor. Rows carry ids and the list carries aria-activedescendant.
  • Rows carry their whole state in the label (name, id, saved, rating, prediction), because the row's buttons sit outside the tab order and the label has to encode what they would have said.
  • Sockets announce what will happen when you arrow onto them: whether placing here inserts, replaces or wraps.
  • Transient messages go to an aria-live toast region.
  • Persistent conditions such as a muted unvetted patch or a crashed engine go to a pinned role="alert" strip that stays until the condition is resolved, rather than a toast that vanishes before it is read.

Touch and coarse pointers

Every rack gesture works under a finger on a tablet: knob drags, cable pulls, locks, the ⋯ menus.

Two rules carry it. Controls that own a drag claim the gesture before the browser can, which lets the rack frame keep its own panning. And affordances a mouse reveals by hovering (knob lock dots, the bank's stars and cut) are shown outright on a coarse pointer, because hover-to-reveal on a tablet means never. Small glyphs get an invisible finger pad, created only for coarse pointers, so desktop hit areas are unchanged.

Hit targets

Hit areas are measured with elementFromPoint rather than eyeballed. A knob's whole face is grabbable, including under its ticks, track and value arc, and a jack responds across its full ring diameter rather than only where its outline is painted.

Colour and contrast

Text meets 4.5:1 against its background. The palette has two tiers for this: a text tier that clears the ratio, and a separate stroke tier for wire glow and jack rings, where contrast rules do not apply.

Colour is never the only channel. Green versus amber distinguishes audio from modulation, but modulation cables also terminate in a named destination, and signal kinds are carried by jack labels as well as colour. Style islands are hue-coded on the taste map and named in text everywhere they appear.

Motion

The rack pulses modulation cables at their modulator's rate, which carries information rather than decorating. The documentation site honours prefers-reduced-motion. The instrument does not yet gate its own animations on it, which is listed as a gap below.

Known gaps

  • No handheld layout. A coarse pointer under 620px gets a stand-in screen instead of the instrument. Deliberate for now: boot costs ~40 renders that a phone would pay for and have nowhere to display. It does mean Auracle is unusable on a phone.
  • prefers-reduced-motion is not honoured in the instrument. The docs site respects it; the rack's pulsing cables and the boot animation do not.
  • The taste map is visual only. The STYLES and DIRECTIONS tabs carry the same information as named coefficients and are the accessible route to it, but the map's spatial reading is not available another way.
  • Screen-reader coverage is deepest where it was tested. The bank and the wiring path were built and verified against a screen reader. The scope configuration and the image exporter were not.
  • No high-contrast theme. The palette clears AA but there is no AAA mode and no way to raise contrast beyond it.

If you hit something not listed here, an issue is genuinely useful.

Troubleshooting

No sound

Check in this order.

  1. The pool is still filling. Boot runs about forty audio renders. The first duel is dealt at 8 patches; the rest arrive behind you.
  2. No patch is loaded. The subject block will say no patch loaded. Click a row in the bank.
  3. The browser has not granted audio. Browsers require a user gesture before an audio context can start. Click anywhere or press a key.
  4. The patch is muted as unvetted. A pinned strip says so and stays until resolved. A render that came back non-finite, silent or DC-dominated is never played. Load a different patch.
  5. Voices are stuck. Press ◼ in the dock.
  6. The output level is down. The vol slider at the far right of the dock.
  7. The tab is muted, or the OS is sending audio somewhere else. Check both.

It asks for a desktop

A coarse pointer with a viewport narrower than 620px does not boot the engine. That is deliberate; see browser support. The look around anyway link sets a session flag and reloads past the gate, but there is no handheld layout behind it.

On a tablet, rotating to landscape is usually enough.

Boot is very slow, or stalls

  • First load compiles WebAssembly. Once. Subsequent loads are much faster.
  • Restoring a large session re-renders your saved bank. This runs across workers and the bar moves; a big session can take tens of seconds.
  • Safari caps the render workers and boots more slowly than Chromium. Expected.
  • A worker that fails falls back to the serial path over the same draws, so it costs time and not content. A job retired after two attempts logs a console warning.

To force the single-threaded path, add ?farm=0 to the URL.

A rebuild changed nothing

You are almost certainly serving with a cache. Use make serve (which sends Cache-Control: no-store) rather than python3 -m http.server. A browser's heuristic cache will keep serving a stale worker.js or .wasm, and late no-store headers do not dislodge an already-cached module worker.

Worse than "nothing changed": you can end up with an engine and a UI from two different commits.

Audio dropouts and clicks

The instrument runs on a real-time audio thread.

  • Another tab doing heavy work can starve it. Close it.
  • A refit is running. A few seconds of inference. It runs off the audio thread and should not cause dropouts; if it does, that is worth reporting.
  • Clicks on patch change should not happen. If you hear one, that is a bug.
  • Unison ×4 with the arpeggiator at a fast division is the heaviest configuration available, and the first place to look.

A MIDI controller does not play

The dock's right side reads midi ● when a device is connected. midi ? means the page cannot reach MIDI at all; click it, and the panel says why:

  • Safari has no Web MIDI. Use a Chromium browser or Firefox.
  • Firefox asks whether to add a site permission for MIDI. Answer the prompt; if it never appeared, press connect midi in the panel.
  • Access was refused earlier. Allow MIDI for the site in the browser's site settings (the icon left of the address), then press connect midi.

midi ○ means another Auracle tab is playing MIDI. Close it, or click anywhere in this one to play MIDI here. (The browser sends your controller to every tab that asks, so before this a second, older tab played every note too: a preset or a control changed in one tab seemed not to apply.)

midi — means MIDI works and the browser sees no device: replug it, and it appears without a reload. On Windows, a device another program has open cannot be opened by the browser too; close that program and replug.

Evolution does nothing

EVOLVE POOL does nothing at all when there is no fitted posterior; there is no direction to climb in yet. Answer some duels first.

A generation produces no new patch when the walk was rejected, or landed on a patch the pool already holds. This is reported as "no proposal beat its parent". It is normal occasionally, and persistent when:

  • The patch is at its budget ceilings (24/24 modules), leaving no room to grow. Check the budget line in PATCH.
  • Everything is locked. Locks are exact, and locking every address leaves the search nothing to do.
  • The pool is pinned solid. Pins are capped at a quarter of the pool, but it is worth checking if you have been saving a lot.

An edit did not take

  • Nothing to commit. The commit button is disabled until you have changed something.
  • The edit was refused as out of domain. A value outside a knob's range is refused rather than recorded.
  • The bench shows the previous patch. Reload, and report it.

The model is not learning

First, check TRUST rather than your impression. Then:

  • Fewer than ~20 picks. It is genuinely too early.
  • Your preference may not be in the feature space. The clearest case is stereo width, which has no coordinate at all. Read the heard as line on the modules involved; it will tell you outright. See what it cannot learn.
  • You have been saving instead of starring. Saving teaches nothing.
  • Check-duel skill is the honest number. Overall skill is measured on questions the model helped choose.

If it has learned something wrong, ⋯ → Reset taste profile… clears the log and the model, and leaves your saved patches alone.

Everything is broken / the engine crashed

A crashed engine shows a pinned alert strip rather than a toast, and it stays until resolved. Reload the page; your session is autosaved and will restore.

If it crashes again on the same session, that is worth an issue. Include the console output.

I lost work

Your session is in your browser's IndexedDB and autosaves continuously. It is gone if:

  • Site data was cleared, by you or by a browser cleanup.
  • It was a private / incognito window.
  • You are on a different browser, machine, or origin. The hosted build and a local copy do not share storage.

There is no server-side copy; there is nothing to recover from. The only backup is the one you exported. See Your data.

Reporting something

github.com/alexnodeland/auracle/issues.

Useful to include: browser and version, what you did, the console output, and the patch exported if it is about a specific one. Debug hooks live at window.__aur and window.__aurLog.

Glossary

Terms the interface uses, in the sense it uses them. The Reference defines the same things formally; this page is for reading the app.

Audition

Playing a candidate's pre-rendered, loudness-normalized buffer, rather than the live patch. Everything you hear in a duel has already been through the vetting gate, which is why an unvetted patch can never reach your speakers.

Bank

One of three collections in the left rail: evolution (the live pool), my patches (what you saved), presets (the built-in library). See The patch bank.

Belief row

The line under the toolbar in PATCH saying what the model thinks of the current patch and which coordinates drove that. It reports a silence rather than a number when it has no basis for one.

Brier skill

How much better than a coin flip the model's duel forecasts have been. 0 is chance, 1 is perfect and certain, negative is worse than guessing. Shown in the menu bar and on TRUST.

Budget

The ceilings evolution searches inside: modules, tree depth, modulation depth. Shown in PATCH as 8/24 modules · 4/6 depth · 1/3 mod depth. A patch at its ceilings has no room to grow.

Candidate

A patch in the evolution pool. Has a stable id, a rendered audition buffer, a feature vector and a lineage.

Check duel

A duel whose pair was drawn at random rather than chosen by the pairing rule. Marked ◇ unbiased probe. Calibration measured on these is the number without an asterisk.

Duel

Two candidates, pick one. The primary teaching signal.

Feature vector (φ)

The forty-four numbers the model sees each patch through: eighteen perceptual descriptors of the standard render, twenty-six structural counts of the term. If a preference is not visible in these, it cannot be learned.

Generation

One round of breeding. Takes the pool's best patches, walks each a short distance uphill on the current model, and injects the children, evicting the weakest to make room.

Genome / term

The patch's real representation: a tree in a typed grammar, not a parameter list. The rack you see is compiled from it.

HELD

The staging tray under the rack. Anything you unplug, delete or bypass goes here rather than vanishing, and stays across a reload.

Lens

See style.

Lineage

The record of what produced a patch: which parent, which step, what changed, and how much the model's estimate moved. Shown in the EVOLUTION strip.

Lock

Freezing a knob, a module or the whole structure so refinement cannot touch it. A locked address cannot be changed, deleted or created.

LUFS

The loudness unit every render is normalized to (−18 LUFS). Louder reliably wins A/B tests, so without it the model would learn "I like loud" and present it as a preference about timbre.

Named control

One of PERFORM's six controls: Bright, Snap, Motion, Body, Grit, Space. Each is a fixed direction in what the instrument can hear, with the same name and the same two end words on every patch. What it turns is measured per patch: at most four of that patch's knobs, chosen because they move the sound most purely in that direction. See PERFORM.

Offer / B slot

A variant grown from the sound you are playing, held in a second voice set called B that plays every note you play. You hear it by crossfading with Blend or holding Peek, at matched loudness, and it replaces your sound only if you press Take. An offer may change structure; nothing else in PERFORM does. See Blend, Peek and the B slot.

Pickup

Soft takeover for a MIDI pot: it does nothing until it passes through the control's current position, then follows your hand. It stops a pot left in one place from snapping a control that Wander, the mouse or the keys have since moved. See soft takeover.

Pool

The evolution bank: 40 vetted candidates the model reasons over and breeds from. (The engine's own default is 48; the web app configures 40.)

Posterior

The fitted model with its uncertainty: a distribution over possible tastes rather than a single best guess. Everything the app shows about confidence comes from its spread.

Prediction

The percentage on a bank row: roughly how likely you are to prefer this patch in a duel. A posterior mean, so it averages the uncertainty away. For the uncertainty itself, read the map's dot sizes.

Quarantine

What happens to a candidate that fails vetting: never played, never shown, and scored so badly that the search learns to avoid that region.

Refit

Full inference over the whole observation log: seconds of work, off the audio thread. Between refits, votes are folded in by the cheaper reweighting path. The wordmark's E lights while a refit runs.

Sample

The standard five-second audition phrase, identical for every patch. Audio measurements are only comparable under an identical stimulus, which is what makes it fixed. It is a measuring instrument, not a demo. Play the patch from the keyboard to judge it.

Search control

A named control drawn in amber with a dashed ring: this patch's knobs cannot honestly make the change it names (no drive to make it rougher, no reverb to make it farther). Turning it moves no knobs. It springs back and asks for an offer in B instead. See search controls.

Standardizer

The scaling that puts the forty-four raw feature values on a common footing. Saved with the taste profile, always, because the model's coefficients are meaningless without it.

Style

One lens of your taste: a direction in feature space that explains some of your answers. A patch is scored by whichever lens likes it most, which is what lets you prefer several unrelated kinds of sound at once. Up to five; a lens claiming almost none of the bank is idle. Nameable, and worth naming.

Taste model

The whole fitted object: style lenses, star cutpoints, session thresholds, and their uncertainty.

Trace address

The name of one site in the genome: node/0#cut, amp#attack, node/0/m#rate. Panel knobs, hand edits, locks, live parameter handles and search proposals all use the same scheme, so the rack and the genome cannot drift apart.

Utility

The latent quantity everything conditions: how much the model thinks you would like a patch. It is a function it infers rather than a score stored per patch, which is why it can rank a patch it has never shown you.

Vetting

The gate every render passes before it can be heard or measured: all-finite, under a peak ceiling, not silent, not DC-dominated. Evolution does produce screaming resonance and silent duds; this is why you never hear them.

Wander

PERFORM's dial for how alive the patch is on its own: still, offer (variants appear in B), drift (the knobs glide through nearby settings the search prefers), roam (bigger and faster). It never changes structure, it pauses while your hands are on the controls, and a tap holds it. See Wander.

Warm start

The three-of-nine preset pick on first run. Worth 18 pairwise observations for about thirty seconds of work, which is how the model gets past a cold start that otherwise takes hundreds of duels.

Films

Short films about Auracle: what it is, how to play it, and how it works underneath. Captions are on by default, and every film's full transcript is printed under it.

Everything you hear in them is Auracle: the music is scored for its own voices and played by its engine. The narration is synthetic (Kokoro-82M, offline).

Start here

Auracle 1:38

The launch film: what Auracle is, what it feels like to play, and what is underneath.
  1. 0:00 The problem
  2. 0:12 Auracle
  3. 0:19 Two patches, one pick
  4. 0:25 Real circuits
  5. 0:34 Playing it
  6. 0:46 Offers
  7. 0:58 Underneath
  8. 1:14 Every note
  9. 1:34 Play it
Transcript

Every synthesizer has a sound in it that's yours. Finding it means turning hundreds of knobs, one at a time. Auracle is a synthesizer that searches for your sound. It plays you two patches. You pick the one you like better. Every pick teaches it your taste, and it grows new patches toward it. Not samples. Real modular circuits, built and wired from scratch. Then you play it. Turn Bright, and it finds the knobs that make this patch brighter. Let it wander, and the knobs turn themselves toward your taste. Press Offer, and a new version grows from the sound in your hands. Blend into it. Take it, or pass. Either way, it learns. Open the circuit any time. Every knob is real, and you can watch the performance turn them. Underneath, a model of your taste bets on every choice before you make it, and keeps score in public. Every note in this film is Auracle. Free, open source, and running in your browser. Play it today.

How it works

How Auracle learns what you like 1:49

The taste model, animated: what it hears, what a pick tells it, how it keeps score, and how it searches.
  1. 0:00 Choosing, not describing
  2. 0:11 What it listens for
  3. 0:28 A pick is evidence
  4. 0:38 Every taste that still fits
  5. 0:47 More than one taste
  6. 0:58 Forecasts, scored
  7. 1:11 The search
  8. 1:24 Reading what it learned
  9. 1:33 Learning while you play
  10. 1:40 In the open
Transcript

You know which of two sounds you like, long before you can say why. So Auracle never asks you to describe a sound. It asks you to choose. Behind every choice, it listens for the things you hear: how bright a sound is, how noisy, how it starts, and how fast it moves. That's eighteen measurements of every patch's sound, all from the same short phrase, and twenty-six more of how the patch is built. Each pick is evidence: you liked this set of measurements more than that one. Many tastes could explain one pick. A few picks rule most of them out. Auracle keeps every taste that still fits, weighted by how well it fits. With every answer, that cloud of possible tastes draws tighter. And taste isn't one direction. You can love dark drones and bright plucks. So the model keeps several lenses, and a sound only has to please one of them. Before every duel, it writes down a forecast. Afterwards, it checks. The TRUST view shows how honest those forecasts have been, even when the answer is: no better than a coin flip, yet. Then it searches. Evolution proposes new patches from a grammar of modules, and your taste tilts every proposal toward what you'll like. Thousands are heard silently. Only the best few ever reach you. You can read what it learned: a map of every patch you've heard, the styles it found, and each direction with its uncertainty. And when you play, it keeps listening. An offer you hear, then take or pass, counts just like a duel. Your taste, learned in the open. And it never leaves your browser.

Under the hood 2:17

For engineers: the genome, audition, features, the taste model, search, PERFORM's wiring, and the web runtime.
  1. 0:00 Five crates
  2. 0:11 The genome
  3. 0:23 Compiling to DSP
  4. 0:31 The audition
  5. 0:40 Features
  6. 0:55 Utility
  7. 1:15 Calibration
  8. 1:24 Search
  9. 1:39 PERFORM's wiring
  10. 1:56 The runtime
  11. 2:06 Read it, run it
Transcript

Auracle is a Rust workspace of five crates, compiled to WebAssembly. Here's how a patch becomes a sound, and a choice becomes a model. A patch is a term in a typed grammar: a probabilistic program over modules. Every knob and every structural choice has a trace address, so a whole patch is one draw from a prior. It compiles to a quiver signal graph, which runs one sample at a time with no allocation on the audio path. Every candidate plays the same standard phrase, normalized for loudness, through a vetting gate that rejects silence, clipping and DC. From that phrase come eighteen perceptual features, from brightness and noisiness to envelope shape and three bands of modulation rate. Twenty-six structural ones come from the patch itself. Every one is standardized. Taste is a utility: the maximum over a few linear experts on those features. A duel, a keep or a cut, a star rating: each has its own likelihood. The posterior is sampled by Markov chain Monte Carlo, and each new answer reweights those samples until a refit is due. Every duel is forecast before it's answered. Each forecast is scored with a proper scoring rule, separately for each kind of evidence. Search targets a Boltzmann distribution: the grammar's prior, tilted by expected utility. Refinement is Metropolis-Hastings on the trace, through fugue-evo. A lock is exact conditioning. PERFORM's named controls are fixed directions in that standardized space of sound. For each patch, a finite-difference Jacobian and a ridge solve wire each control to its knobs. Every half of every control is then checked on real renders. In the browser, the engine runs in a worker, and the voices in an AudioWorklet. A render farm measures candidates in parallel. Every claim here has a measurement behind it, in the reference. Read it, run it, and change it.

The math 2:46

For a technical audience: the taste model and the search as the code computes them, and why each piece has the form it does.
  1. 0:00 Intro
  2. 0:06 Utility
  3. 0:23 Likelihoods
  4. 0:44 Posterior
  5. 1:01 Calibration
  6. 1:17 Acquisition
  7. 1:31 Target
  8. 1:49 Refine
  9. 2:03 Locks
  10. 2:14 Perform
  11. 2:37 Outro
Transcript

The math inside Auracle, and why each piece has its shape. Each patch becomes forty-four features, standardized to one scale. Utility is the maximum over a few linear experts, never their average. So you can love dark drones and bright plucks, and each is scored by its own best lens. Three kinds of answer feed that one utility. A duel is Bradley-Terry, logistic in the utility difference. Cutting a patch is a kill, judged against a bar fitted per session. A picky day moves the bar. Not the taste. Stars fall between fitted cutpoints, so a harsh rater moves the cutpoints. With no hidden lens labels, every parameter is a real number. So plain Metropolis-Hastings fits it, and keeps five hundred draws. Between fits, each answer reweights the draws, exactly and nearly free. When the weights collapse, it pays for a refit. Each duel is forecast before you answer, then scored by Brier. Brier is a proper rule, so only an honest probability scores best. Accuracy cannot see overconfidence. Each kind of evidence gets its own score. Which pair should it ask about? Picking the most informative pair only tied random pairs. Thompson sampling lost. So pairs are random, and every duel is also an unbiased check. Search aims at a Boltzmann target, the grammar's prior times the exponential of beta times expected utility. The prior supplies parsimony as a probability, not a penalty to tune. Beta, at two, is the one dial between browsing and optimizing. Refinement is Metropolis-Hastings on the trace, through fugue-evo. It walks forty steps from each of the ten best patches. Keeping where each walk ends climbs the target instead of sampling it, which suits a shortlist. A lock is exact conditioning. Moves that change, delete or create a locked address are rejected. Checking births as well as deaths keeps detailed balance. PERFORM's controls are fixed directions in standardized sound. Bright is centroid plus rolloff. Each patch gets its own Jacobian from one nudged render per knob, since knobs act differently in each. A ridge solve picks at most four knobs for each control. Each half is then rendered for real, and closes if it stops moving the right way. Every constant here is in the reference, with its measurement where there is one.

The sound engine 2:49

For audio engineers: the patch graph, the modules and their types, compilation, the audition phrase, loudness, vetting, the features, and the live voices.
  1. 0:00 Intro
  2. 0:07 Graph
  3. 0:23 Modules
  4. 0:41 Compile
  5. 0:54 Phrase
  6. 1:12 Vetting
  7. 1:23 Loudness
  8. 1:39 Features
  9. 2:10 Live
  10. 2:29 Farm
  11. 2:39 Outro
Transcript

This is how Auracle makes sound, from the patch graph to the live voices. Underneath is quiver, a modular synthesis library in Rust. On each tick, one sample moves through the whole graph. Continuous knobs are atomic values the audio thread reads, so turning one needs no recompile. The palette has forty-two modules, from a plucked string to sidechained dynamics. The filter is a state variable design, or a diode ladder that saturates harder one way. Audio and modulation are separate Rust types, so a mistyped patch cannot even be built. Every voice ends with a DC blocker where needed, an exponential envelope, and a limiter. Resonance and feedback are capped, so filters cannot oscillate and delays cannot run away. For comparison, every patch plays the same five second phrase. It holds a C, stabs an octave higher, and plays a two note chord. It ends on a low C, with a long release. The random seed is reset every render, so the samples repeat bit for bit. First, each raw render goes through a gate. It fails silence, runaway peaks, and signals dominated by DC. What fails is never played. Loudness is measured the broadcast way, with K weighting and gated blocks. Each patch is matched to minus eighteen loudness units, since louder wins comparisons. The gain stops short of clipping instead of limiting, so timbre is untouched. From that render come eighteen audio features. Four measure the spectrum's brightness and its movement, on a logarithmic frequency axis. Texture, level and envelope take seven more, and one measures the bass. Three are read from single notes. Three more are bands of motion on the held note. The bands run from half a hertz to two, and from two to eight. The fastest runs from eight to thirty. Twenty-six structural features come from the patch, with no render. Live, the same compiler builds four voices inside an AudioWorklet. Four more play PERFORM's offers, crossfaded at equal power. In steady state, the audio thread allocates nothing. A patch change fades out, rebuilds the voices in silence, and carries your held notes across. Auditions render in parallel, on up to six workers. Draws are indexed and absorbed in order, so the pool is identical at any width. One compiler serves search and stage, so what you play is what the model measured.