Live update: Experimental learning recipes now connect scored practice scripts to simultaneous live playback, bass swaps and high-pass sweeps. Verified phrase sync and musical-quality validation remain incomplete. Earlier sequential-only descriptions below record the prior milestone.

Current implementation

The Learning studio now indexes 63,038 external track IDs and runs bounded, private diagnostic practice on the configured local pool. Its canvas replays actual control telemetry with rendered audio. It does not yet deploy a learned quality critic.

For the current user-facing acceptance target, see DJ GPS MVP and training/manual feedback. The live prototype supports takeover, stored parameterized sequential fades and bounded Kimi K3 guidance; professional phrase-aligned mixing and continuous model learning are not complete. See live recipes and adviser. Raveform research metadata is now imported; it is not yet used in live recommendations.

Earlier infrastructure milestones added Qdrant retrieval and an explicit capability-gap assessment, the expanded vocal benchmark, and Kubernetes GitOps deployment.

The September 2026 platform demo provides offline mixing with two to four actors rotating over two decks. Separately, aidj-club-emulator now provides four independent CDJ services feeding a dedicated shared mixer service. Its five-process test and Docker build/runtime smoke test pass. The Docker test verified two simultaneous isolated clubs (ten healthy containers), all four audio strips, shared faders, MIDI control and authentication. The live operator UI can control the independent club runtime, but the offline planner is not yet connected to live four-CDJ execution.

The primary deployment target is now four-CDJ festival B2B, with Docker/API instructions. The table below describes the existing platform offline renderer, not the new emulator's capabilities. The bosai-dsp evaluation records a reviewed candidate and a reproduced echo-tail issue; that crate is not linked into the runtime.

Area	Implemented	Remaining
Audio	Symphonia decoding, Rubato resampling to stereo 48 kHz, Signalsmith key-locked tempo changes, complementary three-band EQ, low-pass filter, faders, stereo WAV	CPAL output, headphone cue, loops, effects, realtime callback
Library	Human reference annotations (downbeats, phrases, vocals) are stored and served but read by nothing; UUID identity, exact-file hash deduplication, original retention, tags, Chromaprint, MongoDB metadata or local SQLite index, basic BPM/key estimates, waveform, bar energy, LUFS/true peak, manual review, paused source scan/queue, Rust ONNX pilot timelines/embeddings, filtered Qdrant retrieval with Mongo revalidation, searchable metric UI, PCM WAV/M3U8/rekordbox XML export	Validated vocal/section/phrase analysis, pairwise transition scoring, native player USB databases
Actors	Separate personalities and memory, partner handoffs, feasible shortlist, Rig structured-output adapter with Kimi K3 configuration, explicit local-planner baseline; since 2026-09-14 a live roster of independent DJs whose turns alternate in the club	Live model quality evaluation with configured provider and real music; the offline renderer keeps its own actor list, not yet unified with the live roster
Sessions	Frame scheduling, events/decisions/manifests, pause/cancel, WAV export, same-build replay with hash verification	Portable replay across machines/builds, resume after process crash, and the MVP acceptance metrics beyond clipping/silence: beat alignment, missing-analysis counts and declared pass/fail thresholds
UI	B2B configuration, library import/review, progress, decisions, recording playback/download, replay and event inspection	Realtime performance UI, hardware tools

The default profile is ClubBaseline. Agent input excludes PCM and exact fader/EQ state; unavailable vocals, headroom and section labels remain null. Library forecasts are estimates, not live measurements.

Local planner is not an LLM. Model mode requires AI_BACKEND, AI_BASE_URL, and AI_MODEL; optional AI_API_KEY stays in the daemon. Invalid model output fails the session unless explicit fallback is enabled, in which case the fallback is recorded. Planning runs before offline rendering, so UI progress is render progress, not speaker-time playback.

Generated demo music is procedural test material. A completed synthetic mix demonstrates execution and replay, not professional transition quality. Imported grids must be reviewed before retrieval accepts them. Real music and model-backed listening evaluation remain required before calling the full product MVP complete.

The original /booth four-deck metadata playground remains separate from the audible /b2b session renderer. Its manual controls do not control a rendered session. No hardware capability or crates.io ownership is claimed. All owned workspace packages use prochain- and disable publishing.

See local development, world model, and library.

Virtual club integration

See Virtual club and LAN demo for command-driven transitions, recorded mixer visualization, Prochain-owned emulator source, the experimental LINK bridge, XDJ-AZ MIDI mapping and the Windows/Kubernetes validation gates. Real rekordbox connectivity is not yet certified.

The new aidj-ui /clubs operator page connects to the independent club emulator for live four-deck/shared-mixer controls and supports a registry of virtual or hybrid setups. It keeps engine tokens on the local UI server. AI ownership labels are descriptive; the offline B2B planner is not yet connected to live handoff execution. Four rekordbox titles, mixer discovery and audible Windows monitoring were confirmed on 2026-09-11; modern CDJ-3000X/A9 fidelity and physical mixer routing remain unvalidated.

AI analysis and transition memory (2026-09-12)

Native whole-asset/one-second descriptors and short-sample ingestion now complement the reviewed library. Versioned transition recipes compile into deterministic controls; controlled pair auditions and complete rendered overlaps populate durable MongoDB or SQLite memory with separate technical measurements and human ratings. The UI exposes /transitions, recipe editing, auditioning, ranking and review. Both model observations and the local planner receive evidence pooled on the recording pair, falling back to a bucketed musical signature. This is an offline learning foundation, not trained preference inference or live four-CDJ orchestration. See scope, formulas and roadmap.

Shared metadata can now use prochain_aidj in MongoDB. Audio and replay artifacts remain on disk. Analysis revision checks protect concurrent updates; distributed session control and shared-volume provisioning remain outside this storage change. See storage architecture.

The offline music analysis service now separates scanning, native import and optional Rust ONNX inference. A 6,005-file inventory and bounded real-track pilots are stored in MongoDB; full-library processing remains paused. Raw classifier scores are explicitly unqualified for vocal exclusion, and generated transition regions do not approve tracks for playback.

Analysis v2 adds 2-second musical timelines, local tempo evidence, multiscale section hypotheses, optional music-trained voice and tagging heads, and bounded DJ context. See measured results and limitations. Full-library processing remains paused.

Live autopilot milestone (2026-09-13)

See Live guidance and autopilot MVP for the new server-side planning/control loop, owner-authorized Start, takeover, pool selection and MongoDB event journal. The initial recipe is a non-overlapping sequential fade. Phrase-aligned blends and a musically reviewed 30-minute acceptance set remain separate milestones; numerical analysis tests do not authorize those claims.

Structure-aware transition planning (2026-09-14)

Transitions are planned from each track's analysed structure instead of a fixed slot grid. prochain-arrangement joins the stored musical_analyses report to a recording on pcm_sha256 and analysis revision, caches the result beside the track, and turns sections, drop and energy events, vocal windows and neural downbeats into phrase-aligned mix-in and mix-out candidates. Candidate downbeats come from the four-bar phrase grid, the downbeat nearest each section boundary, and the downbeats one whole overlap before a drop. Without a current report it degrades to a declared regular bar grid rather than cueing silently at the first beat.

plan::transitions ranks pair mix points — exit position, entry cue, overlap length and technique — on cue quality, harmonic fit, vocal collision, energy delta and phrase alignment. Both executors use it: the offline B2B session schedules elastically, so track length is musical rather than a uniform slot, and the live booth begins each overlap at the planned exit with the operator dwell as a ceiling.

The learning loop records that musical context. evaluation::Context carries a MixContext; learning::FEATURES grew from six recipe-shape inputs to twelve, and evidence pools on the recording pair before falling back to a bucketed musical signature.

What this does not establish: nobody has listened to these transitions. Section, phrase and vocal labels remain unverified model estimates, the twelve-feature dataset has no labelled rows, and no trained model is loaded at ranking time. Rendering still refuses to execute without a reviewed native grid.

Known gaps this update exposed: no API route returns a track's arrangement, so the UI cannot show the intended mix points; the orchestrator resolves arrangements one Mongo query per uncached track; and the reviewed phrase_beats grid now coexists with the arrangement's downbeat grid, enforced only on the audition path.

Learning loop: found not learning, made able to (2026-09-14)

A review of the live database found the loop producing data and learning nothing: 1,028 rendered attempts, 1,027 of them excluded from ranking and training by a diagnostic flag that meant two unrelated things at once, zero human reviews so the training set was empty, and an automatic objective whose spread (0.034) swamped every recipe factor it swept (bass-swap position: 0.0007). Practice was also switched off in settings. Kimi had been proposing sensible one-factor hypotheses against a metric that could not resolve them, and had said so in its own stored notes.

Deployed the same day: provenance in place of the flag, so practice renders count; overlap-health-2, a per-deck measure of bass and top-band collision, level dip and pile-up and seam lurch, kept separate from technical health; blind pairwise comparisons with a server-side selector; a pairwise trainer with an explicit human approval gate and a bonus bounded to ±0.10 in both rankers; a per-genre prior from 43,290 human transitions; overlaps to 128 beats; a loop-status panel and factor table in the UI. Practice was re-enabled and the first renders scored by the new evaluator arrived: health 0.994, transition quality 0.70, for an 11.8 dB hole in the overlap the old score could not see.

What this does not establish: nothing learned has been demonstrated on real renders. Zero comparisons exist, so no model has been trained or approved, and the ranker improves through measurement and human-practice priors, not learned preference. Nobody has listened.