estimated visitors
Technical explainer · 2 MIN READ
Beyond Similarity: Teaching a Jukebox to Choose Its Next Move
A musical policy engine chooses the kind of transition before it chooses the track.
A good next track needs a reason
Play the most similar song every time and a session can get stuck in a very small neighborhood. A useful jukebox needs other moves: hold the groove, build energy, cool down, explore, approach a request, or recover from a poor transition. MixMan chooses among those intentions before choosing the track.
Choose the kind of transition first
MixMan models those competing needs as pressures. Recent repetition can raise novelty or fatigue pressure; an explicit target can raise request pressure; skips and manual overrides can raise recovery pressure; large musical jumps can raise transition-risk pressure. The policy layer converts that state into possible move types such as anchor, step, drift, build, cooldown, bridge, pivot, surprise, or recover.
Choose the move before the song
Session pressures shape the move; the move shapes how candidate tracks are evaluated.
flowchart TD
Context[History, requests and feedback] --> Pressure[Session pressures]
Pressure --> Move[Hold, build, bridge or recover]
Move --> Rank[Retrieve and score candidates]
Rank --> Choice[Next track or planned path]
Choice --> Outcome[Record the outcome]
Make the recommendation inspectable
After choosing the kind of move, the system asks lower-level recommenders for candidates. Vector, hybrid, color, semantic, consensus, and Queen Mary feature signals can contribute different evidence. Candidate scoring then considers the selected move, target progress, recent history, transition safety, and available feature quality. Multi-step path planning can represent a requested song as a destination to approach coherently rather than a command to jump there immediately.
The policy console makes this reasoning inspectable. It exposes the current intent, strongest pressures, candidate scores, transition risk, target movement, and reason codes, while outcomes such as queue, play, rejection, skip, or override can be recorded for later evaluation. The interesting product is therefore not an opaque “AI DJ,” but a musical decision system whose choices can be observed, challenged, and improved.
PROJECT