Kontinuum for producers — six screens, one project file

First run — every edit needs a place to land

First run: three ways to start a project — capture the session that is playing, pick a scene from the Atlas, or create a blank project — with recent projects listed below.

A project is the file Producer writes: the composition, its diff log, the stage and the arrangement. First run offers three ways to start one — capture the session that is playing right now, seed a project from an Atlas scene, or go blank — and the player keeps running underneath while the project opens.

the project is the editable document · there is no other state to keep in sync

Session — the grid, the mixer, the prompt

Session view: a clip grid of sections by tracks, per-track mixer strips with level meters, the device chain under the selected clip, and the composer prompt beside its diff log.

The session grid: sections × tracks of clips, mixer strips below with per-track meters, the device chain under the selected clip, the composer prompt at the right next to the diff log of everything it changed. Ask in plain words; the change arrives as a diff you can read before it lands.

every edit is a validated diff · the meters read engine telemetry, they are not animation

Arrangement — trim and move, on the grid

Arrangement timeline: section ruler and track lanes with clips, a selected clip with trim handles, per-lane volume and pan, and the pending edit shown as the diff that will apply at the section boundary.

The timeline of sections and clips. Drag a clip to move it, grab its edge to trim; the edit waits as the diff it will become, validates, then lands with the section boundary — with automation lanes drawn where the knobs are being driven.

edits are future-anchored · they only ever touch music that has not played yet

Stage — the session in a room

Spatial stage: a top-down circular stage with the listener at the centre and each voice placed by azimuth, elevation and distance, one source on an orbit, with the edit shown as a set_position diff.

A top-down stage where each voice sits at an azimuth, elevation and distance; motion — an orbit, a drift — is an automation lane like any other. The placement you see folds down to the stereo pan you hear.

stereo renders today · binaural and multichannel follow the output device later

Code — the document, as text

Code view: the project as text with line numbers, sections folded behind disclosure arrows, an inline diagnostic under a value that failed validation, and the diff log showing one edit refused.

The project in its own language: sections fold, the playing region highlights, a diagnostic lands under the line that failed validation with the fix one keystroke away, and saving writes the same document the engine performs.

an edit that does not validate never reaches the engine · the log says REFUSED

Device chain — instrument, inserts, sends

Device chain: the kick instrument at the chain head followed by a drive insert, main FX sends and a drum glue compressor, connected by arrows, with a dashed slot for adding the next insert.

The chain under a track: the instrument at the head, inserts, sends, glue. Knobs write the same parameter paths automation writes — the dot on a knob means a lane is moving it right now — and reordering the chain lands as one diff.

every knob is a set_param at the next boundary · the chain lands as one set_inserts

designed screens of the build in progress, rendered from the design — not photographs of the shipped app.

The rules under every screen

One write path. No exceptions.

Everything above runs on the same three rules. Your gesture, a DJ move, a Shortcuts automation and the composer's proposal all become the same validated edit, in the same history, with the same undo — there is no privileged path and no hidden state. What you touch locks; the composer works around it until you release it.

VALIDATED DIFFS

Nothing lands unproven

Every edit — by hand, by move, by model — is a diff that passes the validator before the engine ever sees it. Bounds, schema, CPU budget; a failed edit is refused with a reason, not applied on best effort.

BAR BOUNDARIES

The grid decides when

Diffs land at bar boundaries, on music that has not played yet. Steering never clicks, the stream never starves, and the playhead never interrupts.

ONE DOCUMENT

Projection vs. source

The stage and the code view are read-only projections of the project; the grid, the arrangement and the chain edit it. Different screens, different rights — the same document all the way down.

Six screens.
One project file.

A new way of producing. Music as code, in 48 seconds.