Skip to main content

Live guidance and autopilot MVP

The product principle is continuous guidance with optional execution authority. A manual choice is new context, not an error: cancel automation, preserve what is playing, and recalculate. Mode changes retain the current session and its history.

See DJ GPS acceptance and remaining work for the full manual/auto/hybrid target, and training and feedback for the new offline regression foundation. Live event logging is not yet automatic model improvement.

First operational slice​

Live clubs now provides a pool picker, Start autopilot, energy target, Skip next, Take control and Stop playback. Pool selection initially shows up to 100 matching tracks from the owner's library; filter BPM and deselect unsuitable recordings. The UI offers 30- or 60-minute sessions and up to three minutes per track. The controller stops when time expires or the pool is exhausted; it does not repeat tracks to fill the requested duration. Browser audio still requires Listen to master. Closing the browser stops monitoring, not the server-side session.

The Rust supervisor in booth-api observes the actual distributed mixer and players, chooses and preloads the next track, and alternates decks 1 → 3 → 2 → 4. That exercises both DJ positions; it does not yet represent two independent AI personalities. Guidance, co-pilot and autopilot use the same session context. Co-pilot can execute one recommended transition, then relinquishes authority. Manual commands switch to guidance before executing, and the observer responds to a newly selected playing track within the configured pool.

Honest transition capability​

The deployed recipe is sequential_fade_v1: four seconds fading the current channel to silence, followed by four seconds fading the next channel in. The incoming track starts only after the outgoing channel is silent and paused; all other channel faders must also be zero. Playback uses original tempo. This is a conservative fallback, not a phrase-aligned, beatmatched blend, echo-out, bass swap or professionally validated transition.

Fades execute per sample in the Rust mixer, not by streaming fader commands from an LLM or browser. Manual channel-fader changes cancel that channel's envelope; Take control cancels all envelopes. Already accepted engine work is drained before a manual replacement is allowed. A pending decode/network operation can delay acknowledgement (bounded by request timeouts); the UI must wait for it.

The supervisor checks the sample clock, expected controls and prepared engine track identity before handing over. An external control change, replaced track, unexpected audible channel, engine failure or journal failure relinquishes automation. Recovery requires an explicit user action; it never silently resumes an autonomous set after process restart. Take control preserves current audio; Stop playback pauses the decks. The normal master output remains 0.70 at startup. Per-track trim only attenuates, using available loudness/peak measurements.

Selection and evidence​

Candidates are restricted to the requested workspace-owned pool, excluding played and explicitly skipped tracks. Ranking uses estimated tempo distance, energy target and matching estimated key. When available, the existing Qdrant retriever contributes a small similarity term after Mongo freshness validation. Missing vector evidence falls back to metric ranking. Scores are ranking costs, not percentages or calibrated probabilities. No live LLM backend is invoked by this first controller. Models remain outside the audio timing loop.

Planning context includes incoming and outgoing dj-region-evidence-1 summaries where current analysis exists. Good level stability, a small neural timing-fit residual or a high classifier score does not approve beatmatched overlap. Raw analysis and approval identities remain unchanged by autopilot.

Authority, persistence and deployment​

Only the booth owner may start full-booth automation, change modes/energy or request a one-shot transition. An assigned human DJ can take control. Listeners can observe but cannot execute. Server routes enforce these permissions on every request. The supervisor uses the booth owner's library; guest-library loading continues through the existing ownership-checked manual path.

MongoDB stores immutable live_dj_events (with the existing tenant prefix for private workspaces): session start and pool, ranked recommendations, skips, observed human choices, requested/acknowledged controls, loads, transitions, interruptions and completion. These are future evaluation/training examples; there is no automatic preference learning in this version. UI history is bounded to recent events; persisted events remain available for subsequent evaluation.

Runtime configuration is server-owned:

  • BOOTH_LIVE_MIXER_URL: internal shared mixer endpoint.
  • BOOTH_LIVE_PLAYER_URLS: four internal player endpoints, in channel order.
  • BOOTH_LIVE_MEDIA_PREFIX: media path prefix relative to player media roots.

The authenticated API is GET/POST /api/v1/live-dj. The UI uses the scoped /api/live-clubs/{club}/autopilot route. Arbitrary engine URLs, media paths and cross-user library IDs are not accepted by Start. The Kubernetes API runs one supervisor replica per workspace; scaling it requires an explicit distributed execution lease. New private-runtime templates include the configuration; existing private pods require an intentional rollout to adopt a changed template. The Festival booth is the first live acceptance deployment.

Acceptance and remaining milestones​

Automated tests cover sample-clock fades and cancellation, ranking/history/skip behavior, ten simulated handoffs with no overlapping audible channel, rejection of changed prepared IDs, takeover history, and owner/DJ/listener authority. These establish software behavior, not musical quality or a 30-minute listening acceptance test. Deployment-specific live results are recorded in GitOps.

The next milestone is a reviewed two-track smooth blend: current approved grid identities, mapped regions, phrase/vocal checks, deterministic scheduling and an auditioned render. Only after that should a beatmatched recipe join autopilot. Then validate an uninterrupted 30-minute set, add another recipe, independent DJ personalities and explicit human feedback. FX, samples, calibrated quality scores, adaptive learning and two-track lookahead remain later work. A simulated handoff test must not be reported as a clean professional DJ set.

First live acceptance (2026-09-13)​

The Festival booth completed an accelerated four-track run using Levels, Titanium, One Kiss and This Is What You Came For, across decks 1 → 3 → 2 → 4. Monitoring found no simultaneous audible channels. The stereo master stream contained non-zero PCM and peaked at approximately 0.39 full scale. MongoDB contained matching requested/acknowledged controls, all four loads, recommendations and completion. A separate test verified a manual fader was not overwritten, a manually loaded alternative became the recommendation, co-pilot completed exactly one transition, and takeover retained history. Test sessions were stopped afterward.

The test uses 20-second track segments. It validates the live control and audio path, not a full-length DJ set or the subjective musical quality of a blend. The initial empty-deck transport rejection was fixed and the run repeated successfully. Detailed results are stored in GitOps validation.