Skip to main content

Reusable live recipes and Kimi guidance

Experimental learning recipes in live autopilot​

Live clubs now offers Learning recipes · experimental overlap (default for a new session) and Sequential fades · no overlap. The former reads the existing practice recipe/attempt/review store in the same workspace. It ranks supported 8/16/32/64-beat scripts. Since the 2026-09-14 structural-planning update the ranking starts from the mix point itself — where the outgoing recording is left, where the incoming is entered and which technique fits that section pair — and recorded evidence only adjusts that score: shrunk technical means, human ratings, same-recording-pair evidence first, bucketed transfer as fallback and a recent-technique repetition penalty. A prior cannot turn a poor musical exit into a good one. A latest human avoid/low rating for the same recording pair vetoes that recipe. Unknown and unsupported effects are never generated as commands.

The selected plan exposes reference attempt, sample count, technical mean, transfer basis and uncertainty. Practice scores remain offline-engine priors: they do not become live musical-quality scores or timing approvals. The actual live script and completion events are journaled in MongoDB. More collected practice renders can change future selection; no LLM call is required to replay a recipe.

The mixer executes fader curves (linear or square-root equal power), complementary low-EQ handoff and optional high-pass sweep on its audio sample clock. Incoming playback begins before outgoing fade completion. Once the outgoing channel reaches zero, its player stops; the incoming player continues without restarting. Reusable idle decks are prepared for later turns. Continuous looping of all players is unnecessary. Loops remain manual tools for extending a suitable passage.

Live tempo adjustment is limited to ±4% and changes pitch because key lock is unavailable. Incoming cue/phase uses native estimates; distributed player starts are not sample-accurate synchronization. No reviewed phrase or vocal-safety approval is asserted. This is an experimental audition policy, distinct from the strict verified-grid execution path. Invalid recipes, incompatible tempo or unavailable usable evidence can leave the sequential fallback selected. Current live effects cover bass/EQ handoff and high-pass sweeps; echo, reverb, stem swaps and scratch effects remain unavailable.

Manual mixer input cancels the active script. The supervisor rejects cancelled/replaced scripts, changed deck identities and changed tempo. The canvas shows observed BPM, tempo adjustment, position/duration, fader/EQ/filter settings and overlap progress. Beat pulses follow estimated transport; no fake waveform or audio-level meter is drawn. Stale telemetry stops transport animation.

Reusable live recipes and Kimi guidance

The live engine executes stored recipe parameters deterministically. An LLM is not called for each fader movement or for each execution of a recipe. Music selection, instructional advice and execution authority are separate concerns.

Implemented in this iteration​

  • MongoDB live_transition_recipes stores immutable parameterized versions.
  • Live clubs lets the owner browse saved versions, select one or save changed fade durations as a new version. Changing a recipe requires taking control.
  • The selected version remains active across guidance/co-pilot/autopilot changes and a newly started set. Restarting the process defaults to v1; stored versions remain selectable. The current selection is not a crash-resume mechanism.
  • Session-start and transition-start events retain the recipe snapshot. Recipe IDs identify a family/version; parameters determine the actual execution.
  • Kimi K3 reviews a shortlist asynchronously, outside the mixer/control loop.
  • Guidance shows preparation steps for the chosen track, candidate cue timing, estimated tempo adjustment and vocal/harmonic/timing uncertainties.

The only supported live family is currently sequential_fade: fade out, confirm silence, pause the outgoing deck, start the next deck at original tempo, then fade in. Durations are independently configurable from 1–12 seconds. The original default is 4 seconds out / 4 seconds in. This remains a non-overlapping fallback, not a phrase-aligned blend. Unsupported families and parameters are rejected rather than silently approximated.

The offline B2B lab has a separate beat-based recipe schema, EQ/bass-swap rendering and human-rated attempts. Those recipes are not yet executed by the distributed live players. New live versions are not automatically better; they need audition and comparison. Live rating and automated parameter optimization remain work.

Moderate model policy​

Kimi receives one automatic strategy request per established current track, including an initial shortlist consultation. A different human-selected next track triggers replanning; changing modes requests a fresh assessment. Repeated searches and playhead updates do not create new strategy identities. Requests deferred by the cooldown are reconsidered while the context remains eligible. The owner may also explicitly press Ask DJ adviser. Hard limits are 12 requests per session, at least 30 seconds between requests, one in-flight request, five candidates, a 24 KB context limit and a 45-second deadline. Failed/cancelled requests still consume the request budget. Starting another session resets the per-session counter; there is not yet a cluster-wide monetary budget.

Search, analysis, state polling, envelope scheduling and repeated execution make zero model calls. Kimi receives metadata and bounded musical evidence, not audio or a whole-library embedding dump. Existing Rig K3 output-token limits apply; request counts are not a monetary cost estimate.

An explicit human-selected next track cannot be replaced by the model. Responses must select a supplied track and one of that track's offered recipe IDs, with bounded text. A superseded choice, takeover, recipe change, active fade or late result cannot replace the current plan. Cancelled work is aborted; failure preserves local ranking. Provider error bodies and credentials are not shown in the journal.

Model explanations remain unverified advice. They cannot authorize overlap, modify recipe parameters, invent reviewed cue points or send commands. A model-selected alternative gets its own analysis evidence; the old track's evidence is not reused for the new one.

API and deployment​

  • GET /api/v1/live-dj: state, selected recipe, guidance, and adviser budget/status.
  • GET /api/v1/live-dj/recipes: saved versions (bounded to 100).
  • POST /api/v1/live-dj with action: recipe and the complete validated recipe: persist/select a version while automation is inactive.
  • POST /api/v1/live-dj with action: refresh_advice: explicitly request advice, subject to the budget/cooldown. UI routes enforce booth ownership.

Example recipe:

{
  "id": "sequential_fade",
  "version": 2,
  "name": "Long exit, shorter entrance",
  "family": "sequential_fade",
  "fade_out_seconds": 6.0,
  "fade_in_seconds": 2.5
}

GitOps configures AI_BACKEND=moonshot, AI_MODEL=kimi-k3 and the server-owned provider endpoint. AI_API_KEY references Kubernetes Secret aidj-live-model; no credential is committed. tools/configure-live-model.py CREDENTIAL_FILE provisions it from a local assignment file. The new-private-runtime template uses the same provider configuration; existing private runtime pods need a rollout. Provider settings do not go to the browser.

Still needed for the professional DJ MVP​

The distributed engine explicitly lacks phase synchronization and master-tempo key lock. It must gain a tested synchronization path before automatic phrase-aligned blends can be claimed. Numerical beat-fit residuals are not musical timing approval. Validated region/phrase/vocal evidence is still required for a chosen overlap.

Raveform metadata has now been imported into research collections, with a train-only timing baseline. It is not yet used by the live planner; see human DJ corpus. No trained DJ-quality model is deployed. Programmed templates, an LLM's general advice, synthetic ground truth and professional listener labels are different kinds of knowledge. The offline training foundation does not change that status. See training and feedback and MVP acceptance.

Strategy loop and acceptance boundary​

The strategy identity consists of the current track, explicit human next-track choice and saved recipe version. It excludes the playhead and local ranking order. A submitted request consumes that identity even if it fails: the engine continues locally instead of retrying the provider indefinitely. Takeover cancels outstanding advice; switching modes requests reassessment without resetting history or the session budget. Fast test sets may advance during the cooldown and intentionally receive fewer model calls.

The present typed response selects a shortlisted track and the already selected recipe, with an explanation and handoff note. It cannot yet choose among live smooth-blend/drop/EQ/FX templates, schedule an approved bar, or continue a partially completed two-channel human overlap. Autopilot currently requires the other channels to be silent. Those are remaining MVP capabilities, not benefits that a larger model context or strict JSON alone provides. Asynchronous REVIEW and learned critic promotion are separate future integrations.

Live validation on 2026-09-13 accepted a Kimi K3 response for the four-track benchmark pool, preserved the supplied recipe ID and retained unknown timing/ vocal evidence. Saving recipe v2 succeeded; changing its parameters without changing its version was rejected. The test ran in guidance mode with no audio commands. This validates API integration, not the musical quality of a set.

A subsequent manual-choice notification for Titanium triggered the second bounded request; Kimi preserved Titanium and the same recipe, with zero device control events. This was an API guidance test, not an audible transition or a physical DJ performance.

Pair-specific ranking and Kimi recipe selection​

Live autopilot ranks up to three executable recipes separately for each of its five candidate tracks. If a recipe has scored attempts for the exact outgoing/incoming PCM hashes (in that order), its score and human ratings use that pair's attempts only. Otherwise it uses transferred practice evidence. Eligible exact-pair recipes rank before transferred recipes; technical score, sample-count shrinkage, human ratings and recent repetition determine ordering within those groups. Human avoid/low ratings on the exact pair veto the recipe. Seed recipes remain explicitly unscored.

The existing PLAN_NEXT/REPLAN call includes those per-track shortlists, recipe parameters, evidence counts and recent techniques. Kimi chooses a track and one of that track's option IDs, with a musical explanation. It cannot invent control trajectories or choose an option supplied only for another track. Rust rechecks the selected recipe against current eligible evidence before applying it. Timeout, invalid choice or changed eligibility retains the local plan. No extra LLM call is needed per transition, search, beat or control movement.

The live status exposes recipe_shortlists; accepted choices are journaled as model_recipe_selected with the selected plan and reason. The existing adviser and recipe panel display the explanation and chosen parameters. Scores remain offline technical evidence, not live sound-quality measurements. Identical recording hashes do not guarantee identical cue points, tempo or engine behavior: live timing is adapted and remains experimental, with unverified phrase/vocal safety.