The listening loop

barline lets an agent reason over code and audible evidence in one loop. The model does not receive raw human hearing; it receives source, live engine state, measured audio features, deterministic offline analysis, and provenance.

The cycle

1. Orient: get_status.studio identifies the current canvas, active file, selected source range, primary active playback source, and all simultaneous output-clock playback source ids.
2. Read: get_song returns the complete current project and its source revision.
3. Edit: edit_file, write_file, or another source/project tool mutates the authoritative Yjs document.
4. Compile: the browser stages the new program. Success commits it at a bar boundary; failure leaves the last good audio running.
5. Hear live: get_status confirms compile state, playback position, per-track balance, loudness, spectrum, Audio Session health, I/O, and sync.
6. Measure canonically: render_and_measure renders an exact revision and bar window offline for deterministic production metrics and provenance.
7. Iterate: compare the evidence with the musical goal, make a smaller next move, and repeat.

Live evidence

get_status is the fast feedback path. While playing, it includes:

• transport and playhead;
• master RMS, waveform peak, and log-spaced spectrum;
• per-track post-fader levels;
• integrated and short-term LUFS;
• true peak in dBTP;
• instantaneous master spectral features;
• Audio Session ownership, clock, output identity, routes, PDC/latency, underruns, quality tier, asset/worklet readiness, and MIDI sync.

These readings answer “did it compile?”, “is it audible?”, “which track is dominating?”, and “is the engine healthy?”. They are momentary and tied to the current play position.

Canonical offline evidence

render_and_measure is the trusted production read. It returns:

• integrated and short-term loudness;
• true peak, crest factor, RMS, and peak;
• full-band and low/mid/high stereo correlation plus side-to-mid energy;
• transient count, rate, and normalized strength;
• a 32-band spectrum;
• multi-bar key, scale, tempo, and onset-rate evidence when reliable;
• exact source revision, bar window, sample rate, tails, devices, assets, fallbacks, degradations, latency ledger, and render fingerprint.

Use matching bar windows for A/B comparisons. compare_to_reference adds loudness and per-band deltas against the stored reference profile. You can also name an arrangement section (and repeated occurrence), or isolate one track/return bus. render_audio returns native MCP audio for short bounces plus a resource link, which is the agent’s route to actual audition rather than inferring taste from metrics.

Production Proof

Production Proof composes the same evidence over the full arrangement:

• source and compiled revision freshness;
• compile and arrangement shape;
• live engine, worklet, and asset health;
• offline LUFS and true peak;
• referenced assets/devices and any fallback or degradation;
• revision-bound render completion and provenance.

Checks remain pass, warning, failure, or pending. There is no synthetic quality score, and a successful browser render does not replace producer listening or target-hardware testing.

Change Request A/B

A Musical Change Request compares complete source file sets and stable musical source ids, then renders matching excerpts for base and branch. Through MCP, read both songs and run the same render_and_measure window against each open target before merging.

Example goals

• “Make the kick hit harder”: adjust source, confirm the kick level rose, then compare crest and true peak so added impact did not become clipping.
• “Bring the bass into balance”: compare per-track levels live, then measure a repeated multi-bar window for low-end and loudness changes.
• “Match this reference more closely”: use compare_to_reference, address the largest tonal/loudness delta, and remeasure.

The discipline is simple: change one meaningful thing, verify the revision, listen live, measure offline when the decision matters, and keep the evidence.