Technical note: a small pipeline for AI song exploration vs surgical edits

Most “AI music” demos collapse into one button: prompt → full track. Production work splits earlier. You either need a fan-out of comparable takes, or a narrow transform on a keeper. Treating those as the same API call is how queues fill with near-duplicates.

This is a short technical note for a workspace that keeps both modes under Doremi. It is about sequencing and labels, not model bake-offs.

Mental model: exploration graph vs edit ops

Think of exploration as a small DAG:

prompt + constraints
        │
        ├─ model A take 1..n
        ├─ model B take 1..n
        └─ style variants
                │
                └─ pick 1–3 keepers (discard rest)

Surgical work is a set of ops on a single node: extend, replace-section, remix, mashup, stem-split, lyrics-recognize. Google Research’s MusicLM framing (text → hierarchical music generation) is a useful reminder that “another full sequence” is a different problem class from “edit this stem / section.” Magenta’s long-running creative ML tools line makes the same split between generative exploration and interactive control.

Fan-out: Canvas templates as batch jobs

For exploration I treat the AI Music Canvas like a job board:

• Multi-model batch / compare-models / compare-styles → same lyrics, different generators or coats.
• Batch with one model → volume for cherry-picking.
• Same-style EP / one-line song → constrained sets when the brief asks for a mini pack.

Practical conventions that save pain later:

1. Name the run with brief + date (cover-brief-X-2026-11-01).
2. Listen in fixed windows (first 15s + chorus) before full plays.
3. Tag keepers with why they won (cleaner vocal, better drop).
4. Archive losers the same day so Library does not become a landfill.

Ops: Tools hub after a keeper exists

Once a take is marked keeper, I switch to the AI music tools page and refuse to open a new blank project for local problems:

Suggested pipeline (copy into a ticket)

1. Write acceptance: "options" vs "fix section N"
2. If options → Canvas template; cap keepers at 3
3. Export / bookmark keeper IDs
4. If fix → Tools op only; log op + reason
5. Re-listen acceptance criteria; stop or one more op
6. Do not re-fan-out unless acceptance failed globally

Failure modes I still hit

• Regenerating the whole track because the last eight bars felt soft (should have been Replace Section).
• Running compare-models without fixing lyrics first (variance from text noise, not model).
• Stem-splitting before deciding the keeper (wasted storage and attention).

If your team already treats fan-out and edit-ops as separate CI stages for audio, I would love a cleaner checklist than the six lines above.