The current BeatMind web workspace passes 381 tests across 39 test files.
39 passing test filesVerified 2026-08-28Case 01 / Music systems
BeatMind
BeatMind turns a generated or uploaded track into musical material a person can inspect, rearrange, mix, and render without lying about work still happening in the background.
- Role
- AI/ML Intern
- Built at
- Stick and Dot
- Contribution
- Design and engineering, end to end
- Status
- Live
Measured, with the denominator attached
Proof before polish.On the documented 120-second benchmark input, BeatMind's L4 separation run took 56.5 seconds versus 97.2 seconds on T4.
one 120-second benchmark track on each GPU profileVerified 2026-08-28What it is
01 / What it is
More control than a prompt box. Less friction than starting in a DAW.
BeatMind is a browser-based music workspace for separating a track into stems, reading its musical structure, arranging sections, mixing the result, and rendering a new version.
The visible editor is only half the product. Under it is a long-running pipeline built to keep its state honest when remote workers fail or return late.
Built for
Electronic music makers who want more control than a prompt box without beginning every idea inside a full digital audio workstation.
I designed and built BeatMind end to end. Founder and early-user feedback shaped later product refinements; no one else contributed to the implementation.
Contribution record
02 / Product proof
See the actual product before reading the argument.
10.7-second product capture
01
Start from a prompt or bring an existing track. Both paths become durable project work rather than a browser request that must stay open.
02
Separation produces practical vocals, backing, drums, bass, and other lanes, then analysis maps sections, chords, tempo, key, and energy.
03
The arrangement turns musical structure into an editable section-by-stem grid before the result is mixed and rendered.
03 / Problem and responsibility
The browser can stop waiting. The work cannot pretend it stopped.
Audio generation jobs do not finish inside a normal request. Separation, analysis, arrangement, and rendering each have different runtimes and failure modes, so a single loading screen quickly becomes a lie.
The hard problem was deciding which system owns each stage, how retries remain idempotent, and what the person sees after a refresh or interrupted worker.
- Product
- Workflow, interaction model, feedback-led refinements, and rights boundary.
- Frontend
- Creation, library, editor, arrangement, mixing, rendering, and truthful state.
- Systems
- Generation, separation, analysis, storage transport, durable jobs, retries, and recovery.
04 / Research that changed the build
Research only matters here when it changed a decision.
- 01
BandLab, Splice, Suno, and Udio
Generation tools made starting fast, while production tools exposed more control after the first result.
BeatMind was framed around the handoff from whole track to editable musical parts instead of another prompt-only generator. - 02
ElevenLabs Music and Moises
People need clear identity, progressive disclosure, and visible structure while expensive audio work continues.
The interface reveals completed layers and keeps project state durable across refreshes instead of showing cosmetic progress. - 03
ACE-Step and source-separation model trials
One model did not cover generation, reference conditioning, separation, repainting, and instrument-level work equally well.
The system split generation, separation, analysis, and rendering into independently deployable services with explicit boundaries. - 04
Founder and early-user feedback
The product needed clearer progress, safer upload language, and a path from an initial track into meaningful editing.
Later refinements restored the rights gate, clarified long-running state, and tightened the path into the arrangement.
05 / Architecture
Treat every expensive stage as durable work with its own state, attempt identity, and recovery path.
The web application owns projects and user-facing state. Independently deployed Python services own generation, separation, analysis, and rendering.
Attempt tokens fence late callbacks, operation locks stop duplicate expensive work, and the UI reveals completed layers instead of inventing cosmetic progress.
- 01BrowserUploads directly and reads committed project state
- 02Web applicationCreates the operation and exposes honest progress
- 03Audio serviceGenerates, separates, analyses, or renders
- 04Fenced commitAccepts the current attempt and refuses late work
06 / Decisions and trade-offs
What I chose, what I rejected, and what the choice costs.
DecisionRejectedTrade-off
Make every expensive stage a durable operation with attempt identity and recovery.
Hold one browser request open until generation or separation finishes.
The state machine is more work to build, but refreshes and late workers can no longer silently rewrite the current project state.
Send audio directly between the browser and object storage.
Route large audio files through the application host.
Direct transfer needs careful signed URLs and CORS rules, but it avoids using the web server as an expensive byte pipe.
Use polling for the current small-pilot operating target.
Add sockets and a queue before the product needed them.
Updates are not instant to the millisecond, but the recovery model stays simpler and inspectable while the product is still learning.
07 / Evidence
Two measurements I can defend. No adoption theatre.
The current BeatMind web workspace passes 381 tests across 39 test files.
39 passing test filesVerified 2026-08-28On the documented 120-second benchmark input, BeatMind's L4 separation run took 56.5 seconds versus 97.2 seconds on T4.
one 120-second benchmark track on each GPU profileVerified 2026-08-28I am not publishing a user count here. The account record and the definition of user need to agree before that number belongs in a case study.
08 / What failed
The failures are part of the architecture record.
01 Regenerate finished, but playback did not change
- What I saw
- The interface reported a completed regeneration while the player still used the original audio and showed a mismatched duration.
- Why
- Overlapping playback and result-selection defects hid each other, so fixing one symptom did not repair the visible experience.
- What changed
- I traced the complete result path, corrected which asset became current, and made duration follow the selected audio rather than stale state.
- Still true
- Every new render path still needs an end-to-end playback check, not only a worker success response.
02 The website survived while the pipeline died
- What I saw
- The application stayed available, but a completed worker could not commit its result and the project never became usable.
- Why
- A callback followed an unexpected POST redirect while object-storage CORS separately blocked the browser transfer path.
- What changed
- I corrected the callback target and storage policy, then treated application health and pipeline health as separate release checks.
- Still true
- An HTTP-success smoke test cannot prove that remote audio work completes, commits, and reloads correctly.
03 Musical bars cut through sung phrases
- What I saw
- Technically aligned section cuts landed inside vocal phrases and sounded broken when rearranged.
- Why
- Bar boundaries were treated as sufficient even when the vocal energy around the boundary said otherwise.
- What changed
- Section edges moved toward quieter vocal points and gained short fades so musical edits did not sound like raw array slices.
- Still true
- Automatic boundaries remain an assistive first pass; difficult material still needs a person to listen.
04 I removed the upload consent gate
- What I saw
- The upload flow became cleaner while the product stopped asking the person to confirm their right to use the audio.
- Why
- I treated a trust and rights requirement as removable interface friction.
- What changed
- I restored explicit consent and made rights lineage part of the product boundary rather than optional copy.
- Still true
- A consent checkbox cannot establish ownership by itself, so export rules still have to follow the track's origin.
09 / Limits and future
What the product cannot do yet, beside what may come next.
Current limitations
- Separation is most dependable as vocals, backing, drums, bass, and other; lead instruments and pads can still collapse into the other lane.
- The backing-vocal path can retain lead-vocal bleed, especially when the source already has dense effects or stacked voices.
- Energy is currently understood at project level rather than as a separately editable curve for every stem.
- Groove and sound-palette controls stay out of the product until their timing and timbre data can be verified and wired honestly.
- This is still a small pilot, not evidence of broad multi-user adoption, and some touch targets still need a dedicated device pass.
Deliberate boundaries
- Call a timed-out browser request a failed remote job.
- Publish account counts without the Clerk record and a counting definition.
Whole-track lane generation
Generate a missing musical lane across the complete arrangement while preserving section boundaries and project lineage.
A broader pilot
Test the complete create, separate, arrange, render, retry, and reload path with more people before making adoption claims.
Groove editing
Expose timing feel only after microtiming measurements survive real material and do not reduce groove to a decorative control.
Sound-palette matching
This remains blocked until useful timbre embeddings can support a result that is explainable and repeatable.
10 / Stack and sources
The systems underneath it, and where this account comes from.
- Next.js
- TypeScript
- Python
- PostgreSQL
- Modal
- Cloudflare R2
Audited internallyBeatMind product repository and release records
Audited internallyBeatMind architecture, product, and research documents
PublicPortfolio claim records