Proposed next experiment · not a capability announcement

From a musical forecast
to a responsive partner.

Make the interaction contract and runtime work on the existing 5k corpus before scaling the same forecast task to 20k. Keep the accepted checkpoint and listening set as a baseline; do not discard what already works.

The target is straightforward: you keep playing right hand, Cadence produces a useful left-hand part, and future output adapts to newly received playing. A MIDI upload followed by a prerecorded answer is not this target.

This page distinguishes source findings, our measurements, and design choices. It is a proposal for review, not authorization for an unbounded training campaign. No inference model runs on this page.

Domain ownership comes first

Engineering plan Reuse existing owners and public interfaces. Do not create a second scheduler in the web UI or make the MIDI I/O library responsible for musical judgment.

score       MIDI messages, note/pedal lifecycle, ports and score I/O
session     session clock, observed/held state, scheduling, commit log
  stream    adapt incoming device/browser events to the session input
  inference incremental decoding and cache/rollback integration
model       checkpoint loading, vocabulary compatibility, decoder/cache
duet        causal accompaniment serialization and training task
forecast    preserve the accepted fixed-prefix RH → RH+LH task
demo        connection/start/stop controls, visualization and transport
corpus      build causally available training examples and frozen splits
training    bounded fine-tunes, validation and durable checkpoints
evaluation real-clock replay, counterfactuals, traces and listening

The current code already contains MIDI ports, session-loop machinery, held-note state and cache primitives. Those are reusable implementation pieces—not evidence that the accepted forecast checkpoint is compatible with the older duet/session token contract, or that the old accompaniment behavior is musically useful.

Execution started · CPU implementation gates first

The first interaction fine-tune

Starting point: our accepted 5k / step-500 checkpoint. Not base Aria and not random initialization. Preserve that checkpoint and its listening examples; the interaction candidate is a separate run with a fresh optimizer.

Engineering choices StreamMUSE remains the primary interaction/scheduling reference and Moshi the multistream reference. Other sources constrain interpretation; they are not extra architecture requirements. This section specifies our first test, not a claim that either paper validated it.

The first snapshot tier uses 1/5/10-second observed contexts; candidate leads of 0/250/500/1,000 ms and target spans of 0.5/1/2 seconds. These are experimental training settings, not validated latency budgets. Zero lead is a diagnostic case, not assumed deployable. Initial encoding uses censored note durations plus held-state flags; sustain-pedal behavior is not yet qualified.

Recorded LH history and prior commitments are teacher-forced during the first corpus build; deployment conditions on actual generated and played history. That mismatch remains an explicit evaluation target. Valid silent future windows are retained rather than forcing every example to contain a note.

What the pilot actually established

Our experiment These are Cadence measurements, not claims borrowed from papers. The fixed-prefix decoder is already causal/autoregressive relative to its supplied prompt; missing continuous conditioning does not make its architecture inherently non-causal. AR1AM4

Prior symbolic-music work also uses autoregressive likelihood training; that fact does not establish live capability. MA4AM4 Our corpus begins with transcribed performances and predicted hand assignments, not error-free note/hand truth. AD2PH1 The model's memorization disclosure and the distinction between Pruned pretraining data and our Deduped selection prevent us from asserting pretraining independence. AR2AD3

A 20k forecast run might improve coverage or consistency. It would not, by itself, answer the missing questions about incoming events, actual generated history, scheduling and recovery. That prioritization is our judgment—not a theorem about dataset size.

The live information contract

Design decision At each decision time t, condition on real RH events received by then, actual past LH output, and any LH output already committed for playback. Predict upcoming LH—not an invented human continuation presented as input. SM2MO5

Predicted future RH may remain an internal hypothesis, but only genuine device/replay events may update observed human state. A player's new event must not be replaced with the model's guess. Stop/panic is an explicit safety exception: cancel future output and release AI-owned notes without confusing them with the player's notes.

Latency is a measured budget

This is our sign convention and scheduling contract, not a copied equation. Report time to the first schedulable note, steady-state throughput, p50/p95 delay, late events and underruns separately. Total-shot generation time is neither first-note latency nor acoustic end-to-end delay. SG3SG4SM3

Start with one model/hardware configuration and select lead/commit budgets from measurements. Freeze those budgets before an evaluation run. If the system only works with a long delay, label that honestly; do not make a prerecorded response look live.

Implementation sequence

Each stage earns the next. MIDI first; no microphone transcription, new audio codec or large-model rewrite in the initial scope.

Definition of done

A turn-taking keyboard demo can be a valuable intermediate result. It must remain labeled as turn-taking, not substituted for this simultaneous-interaction gate. GH1GH2

Claims we will not build on

Decisions for review

1. Product target: continuous LH accompaniment is the target; turn-taking remains an explicitly separate milestone.
2. Initial input: MIDI keyboard/browser notes, not microphone audio. Keep synthesis local where practical.
3. First training scope: the verified 5k corpus and accepted model family, with a tested causal-task migration—not a 20k labeling campaign by default.
4. Timing: measure before selecting and freezing the lead/commit budgets. Report delays honestly rather than adopting a universal perceptual threshold from another setup.
5. Learning: supervised causal visibility first; any generated-history/RL or audio-factorization experiment needs its own hypothesis and matched evaluation.
6. Acceptance: real causal traces and useful continuous human playing, not model activity or a single polished clip.

These are proposed decisions. Citations motivate or constrain them; no paper is being used as authority for a design choice it did not test.

Primary-source claim ledger

Every literature point used in this plan

Ten primary papers/cards/documentation sources, 34 claim records. Each record exposes the claim, a short exact excerpt, a precise location, its scope limit, and our intended use. Noncontiguous excerpts are separated with an ellipsis. Source findings are not automatically Cadence findings.

Coverage, verification and limits

This is an exhaustive ledger of the literature premises used by this proposed plan, not an exhaustive survey of all interactive-music research. Secondary chat summaries are not treated as primary evidence. ArXiv links identify the inspected version; moving model cards and documentation reflect the 18 September 2026 inspection. Section and paragraph references are identified at the granularity actually checked; documentation line numbers can drift.

The source audit was followed by adversarial checking. A coordinator pass additionally checked the streaming paper's sign/delay equations and Moshi's delay-training section. The result is still a reviewable draft, not a guarantee of infallibility. In particular, first-note/tail latency, causal-task learning, robustness to a new player and musical responsiveness remain experiments to run.

The exact four-slot/384-frame preprocessing recipe discussed earlier is not adopted or relied on here; a repository-level audit would be needed before treating those implementation details as our specification. Cadence currently uses Aria-compatible event timing, not that tick-grid recipe. We make no novelty/first-system claim, no universal impossibility claim, and no claim of commercial clearance.

All literature-derived claims above map to this ledger. Domain placement, state ownership, test procedures, budget notation, stage order and acceptance criteria are explicitly our engineering proposals. Pilot results are our observations; model-generated future RH is never presented as observed human input.