A concept for Suno, from an author who writes songs in it every day. VOLO:NIGHT, October 2026.
Where this comes from
Suno was born as an answer to one question: can a model generate music from a prompt? The interface still carries that birth. You type a style and a lyric, you get two clips. The clip is the unit of everything: the library, the search, the playlist, the share link.
Songwriting does not work in clips. A song is written over days or weeks. You try four styles. You keep one and rewrite the second verse. You change one word in the hook and generate again, because that word changes how the line is sung. Every one of those steps is a new clip, and the library shows them as a flat feed of near-identical rows.
My own library, snapshot of 17 September 2026:
| distinct song titles | 2,473 |
| clips behind them | 10,231 |
| titles with a single try | 787 |
| titles with 20 or more versions | 70 |
| most versions of one song | 104 (“Angie”, 20 days) |
| titles worked on for more than 90 days | 33 |
| titles with at least one public version | 163 |
So 163 songs reached the public, and about 10,000 clips sit in the feed to make that happen. Today I cannot ask the product “which songs did I write in April”, “which versions of this song did I like”, or “where is this song now: draft, candidate, released”. I run all of that outside Suno, in folders and scripts. This document describes what it would look like inside.
The principle
The unit is the song. The clip is a version of it.
Everything below follows from that one change. A song has a title, a language, a persona, a stage, and a tree of versions. A version has a parent, a generation card, and a note on what changed. The feed becomes a view, not the storage.
Nine pieces
1. The song page
One page per song. At the top: title, stage, language, persona, how many versions, first and last generation date. Below: the version tree, newest branch on top. A version shows its parent and a one-line diff: “lyrics: verse 2 rewritten”, “style: +saxophone, −trap drums”, “model: v4.5 → v5”. Two buttons on any version: continue from here and compare with.
Why: the tree answers “how did I get here” and “which branch did I abandon”. The flat feed cannot.
2. The generation card
Every clip already carries a prompt, a lyric, a model and a persona. Make the card a first-class record: show it, diff it between any two versions, copy it to a new generation with one change. Add the fields that serious users keep by hand today: seed, weirdness and style-influence sliders, the exact lyric text with section tags.
Why: when a line finally sings right, I need to know which of five changes did it. Without the card I guess.
3. Stages
Five stages, set by the author, visible everywhere: idea → draft → candidate → canon → released. The library filters by stage. The released stage stores where the song went: the YouTube or Spotify id, the release date, the cover.
Why: a library of 2,500 titles is unusable without a “where is this now”. Stages also tell Suno what matters to the author: a candidate deserves better search ranking than a dead draft.
4. Search and archive
Search by month, by stage, by language, by persona, by text inside the lyric, by style tag. An archive action that moves dead branches out of the feed without deleting them. Saved views: “April 2026, candidates, English”.
Why: the feed grows by a hundred clips a week for an active author. The only tool today is scrolling.
5. Two shelves per song: candidates and canon
Inside a song, two pinned lists. Candidates is what I am still choosing between. Canon is the version that represents the song. Play either shelf as an A/B: same section, two versions, one click to switch, a note field per pair.
Why: choosing between takes is most of the work. I do it today with two playlists and a notebook.
6. The lyric studio
Suno has a lyric assistant. It is a chat bolted onto a text box, and the text box itself is slow on a long lyric. I would rebuild it as a studio with four tools, none of them a chat window.
Intake by voice. An author often has the song in their mouth before they have it on paper. Record, transcribe, and let the model pull the living lines out of a messy transcript into a finds list: phrases, rhyme families, images. The finds list is attached to the song and grows every time the author talks.
A task, not a prompt. Lyric generation takes a structured task: what the song is about, who speaks, what to keep word for word, what not to use, which finds to work in. The “keep” list comes first, because a model asked to improve the rhymes will cheerfully delete the two best scenes. The task is saved with the version, so the author can see what was asked and what came back.
Checks on save. Every saved lyric runs through the same set of checks, in any language, in under a second:
- false rhymes: endings match, stress does not, so the model bends the word when it sings it;
- lost lines: a diff against the previous version that lists what disappeared, not only what changed;
- section shape: syllables per line, where the hook lands, which sections carry too many words to let the melody move;
- stamp lint: the clichés generators reach for in every language, flagged inline;
- language check: grammar and naturalness per language, with a one-line verdict (“sounds translated”, “native”, “mixed register”).
Ask on a selection. Select a verse and ask for one thing: more rhymes for this word, the stress pattern of this line, three alternative endings that keep the meaning. The answer comes back as options beside the text, not as a conversation.
Why the language check matters: I write in English, Ukrainian, Polish, German, Spanish and French. The generator sings whatever it is given, including grammar a native speaker would never sing. A songwriter’s tool must know when a line is wrong before the credit is spent.
7. Production checks and the remaster chain
Suno has a remaster button. It is one button with no meter. A production step needs measurement before and after, and a chain the author can see:
- crackle meter: generator artifacts above 10 kHz in percussion and voice, reported as a share of the track;
- de-crackle by stems: separate, clean the stems that carry the crackle, leave the bass alone, recombine;
- loudness and true peak against a chosen target (streaming, YouTube, club), with the numbers shown;
- dynamic range and low-end check, because an overloaded style prompt shows up here first;
- stems and lyric alignment for video, karaoke and remix work.
Each check is a plugin in the chain with a before/after reading. A remaster that cannot show what it changed is a coin toss.
8. The release gate
A song moves to released through a gate, not a button. The gate records the master version, the loudness target it was checked against, the cover, the public link, and who approved it. After the gate the song has one public identity across versions: a listener who shares one clip lands on the song.
Why: albums on Suno are being dropped by the thousand this month. Without a gate an album is a playlist of clips. With a gate it is a record of decisions.
9. Where is my song
One board across the whole library: every song in work, its stage, its last version date, and whose move it is: the author’s (choose, approve, write) or the machine’s (generate, master, publish). Derived from the data, never typed by hand.
Why: the question I ask most often is not “what did the model make” but “what am I waiting for”.
What this looks like
┌──────────────────────────────────────────────────────────────────────┐
│ Neon Static stage: candidate · EN · persona: V │
│ 80 versions · 19 Jun → 27 Aug 2026 · released: — │
├──────────────────────────────────────────────────────────────────────┤
│ canon v71 ★ "bridge back in, hook word fixed" ▶ compare │
│ candidates v66, v74, v79 ▶ A/B │
├──────────────────────────────────────────────────────────────────────┤
│ tree │
│ v1 ─ v2 ─ v5 ─┬─ v9 … v38 (style: synth-pop) archived │
│ └─ v39 … v71 ★ (style: dark wave 118 bpm) │
│ └─ v72 … v80 (lyrics: hook word) archived │
├──────────────────────────────────────────────────────────────────────┤
│ lyric v71 vs v66: 2 lines changed · 0 lost · 1 false rhyme · native │
│ card v71: model v5 · style "…" · weirdness 35 · seed 1829… │
│ master v71: crackle 2.1 % → 0.4 % · −14.0 LUFS · −1.0 dBTP · DR 8 │
└──────────────────────────────────────────────────────────────────────┘Evidence that it works
I have been running this workbench outside Suno since September 2026, for one author, by hand and by script:
- a folder per song with a task file (what the song is), a finds file (lines caught from voice notes), numbered lyric versions, the style block and the packed lyric for the generator;
- a generation card written for every generation: persona, model, sliders, style, text;
- two Suno playlists per song in progress, candidates and canon;
- scripts for false rhymes, lyric diffs with a lost-lines list, syllable shape, cliché lint, beat-grid tempo, loudness, crackle, de-crackle by stems;
- a release gate that refuses to publish without a master passport and a human signature, and a ledger of what went where;
- a “where is my song” board regenerated every 30 minutes for 121 releases: stage derived from what exists on disk and what is live on the channel.
It took one person about six weeks to assemble. It is the reason 163 songs reached the public instead of staying in a feed of ten thousand clips. Every piece of it belongs inside the product, because every serious author rebuilds it alone.
What Suno gets
Authors who stay. The casual user generates twenty clips and leaves; the author generates ten thousand and needs a place to keep the song. Albums that mean something, because they are built from canon versions with a release record, not from a playlist of takes. And a library that stops being the reason people export to a folder on their desk.
Contact: VOLO:NIGHT (Suno handle volo_night). The working system behind this document runs on the author’s own server and can be shown.