F34.us
Menu

Product philosophy and design direction · 8 MIN READ

How We Want MixMan Sessions to Develop

Our philosophy for evolving MixMan sessions, the recommendation and planning mechanisms already in place, and the tuning and feedback work needed to bring them into alignment.

A session should have somewhere to go

The experience I want from MixMan is easy to describe. Start some music, let it find a groove, and give it a little guidance when the room changes. It should be able to carry on when nobody is touching the controls. When somebody does intervene, that intervention should matter.

Getting there means asking more of a recommendation system than whether two tracks have similar tempos or sound alike. A song can fit the previous song perfectly and still be the wrong choice for the evening. Another can sound quite different and carry exactly the feeling the room needs.

Our recent Session Behavior Design Intent discussion puts that experience at the center of the policy revamp. MixMan already has substantial machinery for recommendations and session planning. The work now is to align and tune that machinery around a clearer musical purpose, make focused corrections, and improve how we judge the results.

What excites me is the possibility of useful autonomy with understandable direction: music that develops over time, with people able to shape where it goes.

Policies give a session its chapters

I think of a session as a book. Songs are the paragraphs; policies govern the chapters. A chapter might hold a relaxed groove, build energy, explore unfamiliar territory, or make its way toward a request. Policies can change as the audience and the situation change. The chapters can emerge while the music plays.

Imagine a party starting with chill house while people arrive. It settles there for a while, then moves toward deeper, more energetic music. Later someone requests a bass-house track and the room spends time in that neighborhood. Eventually people want a different feeling, and the DJ guides the session toward rock, softer material, or R&B classics. When everyone stops intervening, the music still has a useful way to continue.

That is an illustration of the experience we want. It leaves room for long passages and transitions of different lengths. Another evening might linger almost entirely in one region. An exploration session might travel much further. The right behavior depends on the purpose of the session.

There should also be variation between runs. A session that repeats the same pattern of dwelling and traveling would become predictable even with different songs. But variation needs a musical reason. We want the freedom to discover something interesting while preserving a believable thread through the evening.

The machinery for choosing a direction already exists

MixMan has several ways to find candidate tracks, including audio vectors, metadata, color and semantic representations, consensus between strategies, and Queen Mary audio features. These offer different views of how tracks relate. Acoustic resemblance, shared mood, and a practical transition each contribute something useful.

The policy layer adds context about the session. It models pressures such as repetition, exploration, requests, and recovery after an intervention. It can choose a kind of move—holding a groove, building, cooling down, bridging, or pivoting—and use that choice to influence candidate generation and ranking.

Multi-step planning extends the decision beyond the next song. The planner explores possible sequences, keeping a limited set of promising paths rather than examining every combination. That gives MixMan a mechanism for approaching a destination through intermediate tracks. The authoritative session planner resolves steering and participant pressure and maintains the session's queue, candidates, and path.

The direction we want to strengthen is a modular one: context and intent shape the ranking, and selection chooses the best available ranked candidate. That makes it easier to improve one part of the system and explain its contribution. It also keeps expectations grounded in the library: even the best available choice can fit poorly if the collection lacks suitable music.

These foundations give us places to work on the experience. They do not yet guarantee that every recommendation surface interprets intent in the same way, or that today's settings produce the chapters we want. The initial policy presets were provisional guesses. Their values are starting points for evaluation and tuning.

Different moves, shared musical evidence

The same library can support different journeys. A policy favoring continuity can hold the groove; one favoring change can build, bridge, or pivot. Both directions depend on the available musical evidence. Ranking and multi-step planning bring those inputs together to find suitable tracks and promising paths. This diagram connects the existing mechanisms around our design intent; making that interpretation consistent across recommendation surfaces is still part of the work.

flowchart TD
    Intent[Policy and session intent] -->|Continuity| Hold[Hold the groove]
    Intent -->|Change| Travel[Build, bridge or pivot]
    Hold --> Options[Rank candidates and plan paths]
    Travel --> Options
    Library[Library evidence] --> Options

A request usually changes the destination

Most of the time, MixMan has to infer what people want. A deliberate request is unusually clear evidence. After a long relaxed passage, a request for something more energetic often means that the desired direction has changed.

Our intended behavior is usually to treat that request as a new destination, travel toward it, and let the session develop there. Travel can take several songs when the musical distance calls for it. Explicitly temporary requests remain a separate case.

A new chapter or a temporary visit

These branches illustrate the distinction we want to preserve. A request for a new direction gives the session somewhere else to develop. An explicitly temporary request is a visit rather than a new chapter. The pace of travel, the return from a temporary visit, and the balance between participants still need design work; the diagram describes the intended experience rather than a finished switching procedure.

flowchart TD
    Request[A listener request] -->|New direction| Travel[Approach a new region]
    Request -->|Temporary| Visit[Make a brief visit]
    Travel --> Develop[Develop there]
    Visit --> Return[Resume prior direction]

Sector Jump makes this idea approachable through a navigation metaphor. A ship can stay in a musical region, explore nearby, or head somewhere else. Its actions feed the shared session's steering and pressure mechanisms. The metaphor should help people understand and influence the movement they hear.

Shared control also needs balance. One person's repeated requests should not automatically take over the whole room. MixMan already has request limitations; the exact rules for influence, competing requests, and the pace of travel still need design work. The goal is useful participation without requiring the DJ to arbitrate every interaction.

Good selection should make the DJ's job easier

For DJ Assist, the immediate question is whether this is a good song to play next, given the audience, recent music, and current direction. Transition difficulty matters because the DJ has limited time to prepare. Recommendations should reduce browsing and decision pressure while keeping the music interesting.

A good choice may sometimes call for a quick cut or a more demanding transition. The human DJ, Auto DJ, or another playback client handles its execution. We need to judge the quality of the song choice separately from how well that particular mix was performed.

This also explains why different policies deserve different behavior. A policy emphasizing smooth continuity can favor easier transitions. An exploratory policy can accept more adventurous choices. DJ Assist's balance can change with the session and the operator.

Useful defaults and controls people can understand

On an ordinary weekday, I want to start the player and hear music. Detailed controls should be available for setup and occasional adjustment, with defaults that make everyday listening work immediately.

The Policy Console already exposes decision diagnostics and steering controls. Its natural role is detailed session administration: understand the active direction, inspect what is influencing decisions, and adjust it when necessary. Sector Kiosk offers approachable visibility; Sector Jump offers playful participation. These interfaces should help people guide the same session.

The design discussion identifies useful possibilities beyond today's point targets: allowed ranges, movement rate, exploration, time spent in a region, and clearer visibility into transitions between policies. We still need to decide which controls belong in the product and how they interact. We have not selected a final parameter set or an automatic policy-switching procedure.

A control is valuable when someone can understand its effect. If changing a policy changes weights, which then change the policy again, the resulting behavior becomes difficult for everyone to explain. Better handles should make the session easier to direct.

Learning starts with asking better questions

MixMan records recommendation events, candidate diagnostics, playback observations, and feedback. That gives us a foundation for evaluation. The feedback work needs to preserve several distinct judgments: do I like this track, is it a suitable next song, and does it serve the current session? The quality of an executed mix is another question.

We also need to distinguish a proposed track from one somebody actually heard. A planned sequence can be abandoned. A returned shortlist can go unselected. Useful learning depends on capturing what was offered, what happened, the intent at the time, and what the listener was judging.

Some improvements are straightforward engineering work. Audio similarity evidence needs to survive retrieval into ranking. Mood and genre descriptions need to retain their meaning when compressed into simpler representations. Changes to those mechanisms should be compared on the same decisions before we choose a more elaborate learning approach.

My library and ratings already express my taste, and the initial human evaluation will reflect it too. That is useful evidence, provided we are clear about what it means. Mathematical tests can tell us whether an algorithm follows its rules. Listening tells us whether those rules produce an enjoyable, appropriate experience.

That is how I want to move MixMan toward this target state: keep the useful foundations, make the session's direction clearer, improve the evidence, and tune against actual listening. The experience I am aiming for is a session with a musical thread, room for surprise, and a meaningful response when people ask it to go somewhere new.

PROJECT

More from MixMan Server

F34.us Background Image