llmbience · Python + PyTorch · one GPU · a browser dashboard

LLMbience

LLMbience is a local studio for continuously generated music. Give it a prompt and a model, and it generates clip after clip on the GPU while a sample-clock renderer plays them back without gaps, to the room's speakers and to any browser listening. A dashboard steers it: prompts, presets and rotations, a mixer for live inputs, rhythmic guides, a melody lane, and command tracks that turn a shell pipeline into sound.

The LLMbience dashboard in its paper theme, on the Mixer tab: a preset library on the left (Felt and filament, Night transit, Wide open, Loose brass), a melody step sequencer with piano keys in the middle, audio adherence and captured-original sliders, the Now and Next clip panels on the right, and a transport bar with Play, Stop, 48 kHz stereo, Listen here and the master level.
The dashboard's Mixer tab, idle: the preset library, the melody lane's step sequencer, the Now and Next panels and the transport. The dashboard has paper and ink themes.

Architecture

Everything that decides anything is in one engine: settings, presets, the generation queue, rotations and a lease on the GPU. Dashboards in any number of browsers, and the CLI, are clients of it; none holds state of its own. Model inference runs in a guarded worker process, so a crash, a stall or a thermal cutoff ends a job, not the studio, and playback is a single sample-clock renderer whose output goes both to the sound server and to browsers, so there is never a second player to drift.

The studio LLMbience's architecture. Browser dashboards and the CLI talk to one engine over the studio's HTTP API. The engine is the only settings and scheduling authority: it owns the session store, the generation queue and a lease on the GPU, so inference is serialised. A guarded resident worker process loads MusicGen small, ACE-Step Turbo or ACE-Step Base on one AMD GPU through ROCm, keeping at most two compatible models warm, and returns whole clips of native 48 kHz stereo. A single sample-clock renderer mixes the clips with optional captured inputs, rhythmic guides, a melody lane and owner-authorised command tracks, and feeds both the sound server and a browser MP3 stream. Thermal limits and a watchdog guard the GPU. dashboardsany browser+ the CLI studio APIHTTP · relative URLs enginesettings · queueGPU lease · rotations resident workerMusicGen · ACE TurboACE Base · ≤ 2 warm one GPUROCm · no CPU fallbackthermal limits · watchdog sample-clock renderer48 kHz stereo inputsPulse · browser mic/tabguides · melody command tracksowner-authorised PCM sound servertrue output browsersListen here · MP3 one clipper request clips Now · Next
Authority in one place. The worker only loads models and returns clips; the renderer only plays; the engine decides.

Generation and playback

Playback and generation are separate controls. Play plays ready audio and never starts inference; Automatic keeps a bounded queue of ready clips filled; Compose asks for one. The studio can start fully idle, with no audio and no model loaded, and a paused transport freezes the playhead without pretending the gain is zero.

Generation runs ahead of playback Measured on the live studio: eight 120-second clips, each ready a median 17.69 seconds after its job started (17.94 at most), at least 6.69 times faster than playback. The playback lane plays the ready clip Now while Automatic keeps one clip queued Next; generation jobs sit idle most of the time. Edits to the prompt cancel only uncommitted future audio. The figure is drawn to scale for two clips. 0:00 0:30 1:00 1:30 2:00 2:30 3:00 3:30 4:00 playback generation GPU lease clip 1 · Now clip 2 · Next → Now clip 2 ready in 17.7 s clip 3 ready in 17.7 s measured: ≥ 6.69× playback
Measured, not assumed. On the live studio, eight two-minute clips came back in a median 17.7 seconds each, through one worker and one model load.

Earlier, with 30-second clips, the first call took 13.1 seconds including the model load and the next two 2.7 and 1.7 seconds. These are measurements of a small window, not tail-latency guarantees, and the project says so.

Clips and continuation

Automatic composes independent whole clips with short edge fades, and if a new one is late it loops the last good clip rather than going silent. The experimental Continue action instead extends what is playing: the model hears the end of Now as an audio prefix and only the new audio is published. Keep extending makes that the automatic mode.

Continuing from audio How continuation works in the MusicGen probe. The first chunk is eight seconds generated from the prompt. Each later chunk is conditioned on the final three seconds of the previous raw output as an audio prefix, and the model's output starts with that context again; it is removed exactly once, so only the eight new seconds are appended. ACE's Continue action works the same way with a bounded native-stereo prefix and publishes only new audio. chunk 1 · 8 s new 3 s prefix chunk 2 · 8 s new 3 s prefix chunk 3 · 8 s new 0s 4s 8s 12s 16s 20s 24s
The context is removed exactly once. Each chunk re-hears the last three seconds, and only the eight new ones are kept.

Dashboard and mixer

Live inputs

Pulse sources on any server, or a browser's microphone, loopback or tab audio over HTTPS, feed a captured reference. It can condition generation (ACE Base verifiably follows future guide audio), be mixed in as the original at its own level, or add an RMS-gated suffix to the prompt when the room is loud. Capture is always opt-in; one browser owns the stream and other tabs observe without asking for a device.

Rhythm and melody

A rhythm workbench lays guide voices on an editable grid: sixteenths by default, triplets and dotted notes, swing, eleven voices with their own envelope, delay and reverb. A melody lane plays a piano phrase on the same clock. Guides can be monitored without being heard by the model, or heard by it without being monitored.

Command tracks

An owner-authenticated Bash command can generate raw PCM on an interval and feed the same mixer, so a script becomes an instrument. Ordinary music permission never grants shell authority: the command-track API needs a separate owner capability, while the music controls are open to anyone who can reach the studio, by design.

Two buses

True output and Monitor output have their own faders, and the monitor can be muted while keeping its level, without changing what the model is conditioned on. A final safety ceiling keeps the mix from clipping when guides, melody and commands pile on.

Acceptance gates

The first probe wrote down its acceptance before it ran, and the studio has kept the habit: every feature has an acceptance file and a validation note. The original gates were these:

GateEvidence required
AG-01Exactly one visible GPU, the expected architecture and PCI identity, and correct FP16 matrix multiplication
AG-02Finite, non-silent generated PCM and a playable WAV
AG-03At least one generation from the previous raw audio tail, with the context removed exactly once
AG-04Real time: each chunk adds more new audio than its generation took
AG-05A human listens for character, continuity and response to the prompt

AG-04 is a measured gate: a run can produce audio and still fail it. AG-05 stays unverified until someone listens, because waveform statistics are not a perceptual evaluation. Long-term musical continuity, stem control and a quality ranking between the models are explicitly not claimed.