Back to corpus
architecturetechnical paper candidatescore 54

LUME Music Direction — Conclusive Architecture Decision

> Research report, 2026-05-20. Author: research-engine. > Question settled: how should the LUME bar produce music that responds to body > motion AND sounds genuinely good (venue quality)? > > **Decision: stem-based interactive playback.** Body motion controls real, > professionally produced 4-stem Demucs sets — layering, crossfading, filtering, > FX, beat-synced triggering — instead of synthesizing music from scratch.

Full HTML reader

Read the full artifact

Open in new tab

Extracted abstract or opening context

> Research report, 2026-05-20. Author: research-engine. > Question settled: how should the LUME bar produce music that responds to body > motion AND sounds genuinely good (venue quality)? > > **Decision: stem-based interactive playback.** Body motion controls real, > professionally produced 4-stem Demucs sets — layering, crossfading, filtering, > FX, beat-synced triggering — instead of synthesizing music from scratch. The live Strudel path is failing for a structural reason, not a tuning reason. **Generating good-sounding music live from scratch is the hardest possible way to solve this problem**, and two sound-design passes have already confirmed it does not get there. The offline `motion_score_composer.py` only sounds good because it is painstakingly handcrafted additive synthesis with no real-time constraints — porting that to a streaming synth (its memory file's "Path B") inherits all of that handcrafting cost and still produces synthesized, not produced, audio. The breakthrough is on HD1. Mohamed already has a **professionally produced music library that has already been stem-separated** with Demucs htdemucs into clean 4-stem sets. The source material is professional. The separation work is done. The instant any stem plays, it sounds like real music — because it *is* real music. The body's job is no longer to *invent* music (impossible to do well live) but to *perform* music that is already good (a solved, DJ-shaped problem). Mohamed is a DJ; rekordbox is on K11; this is the natural fit. The Comp-Core `audio-engine` Rust crate **already contains the runtime primitives for this**: a `DeckPlayer` buffer-playback node with seek + looping, a `hound` WAV loader, `FilterFx` / `DelayFx` / `ReverbFx` with beat-synced delay, a `MotionSynth` mod-matrix, a `VoiceManager`, and `link-clock` (Ableton Link). The `cc-dj-auto` crate has a full automatic-mixer (`mixer.rs`, `transition.rs`, `analyzer.rs`). We are not building a music engine from zero — we are wiring an existing one to the existing 128-dynamics body signal. HD1 is a 460 GB drive, **97% full (444 GB used)**. It mounts on **Mac4** only (not Mac1). SSH shells cannot read it: macOS Full Disk Access blocks `sshd` and `osascript do shell script`. The directory *listing* is readable via Finder AppleScript over SSH (Finder has FDA); file *contents* are not, until a human copies them off HD1 in Terminal.app (which has FDA). This is the same gate recorded in `san-training-data-2026-05-19.md`.

Promotion decision

What has to happen next

Promote into a technical note or architecture paper with implementation anchors.

Why this is not always a full paper yet

Corpus pages are public-safe readers for discovered workspace artifacts. They are not automatically final papers. A corpus item becomes a polished paper only after the editable source, evidence checkpoints, references, figures, render path, and release status are attached through the paper schema.