2. Philosophy

← Introduction · Guide contents · Next: Thinking in semantic roles →

Treat the workflow as part of the composition

When I work on a track in Suno, the prompt is never the whole composition. The source audio matters. So does the order of operations, the controls at each stage, and the listening decision that sends me towards another Cover, a Mashup or a fresh generation.

I think of that workflow as part of the composition. In Flowstate In Yellow, the melodic Anchor and Kinetic Engine were separate songs because I wanted each one to do its job clearly before they met. Mashup then became an assembly step and Cover became a cohesion step. Those choices shaped the final track as much as any individual descriptor.

Preserve ideas, not labels

When I make a Cover, I am rarely trying to preserve an entire genre. I am listening for the thing that made me want to work with the song in the first place: a bass line, a vocal cadence, a melodic contour, a harmonic movement or a particular kind of rhythmic drive.

That changes the opening question.

Instead of:

How do I turn this into Liquid Drum and Bass?

I ask:

What musical idea must survive when this becomes Liquid Drum and Bass?

The destination genre still matters, but now it has something specific to work around. In Foggy Hearts, the new Liquid Drum and Bass identity could change the groove and production without losing the emotion and phrasing carried by the original vocal.

Give every instruction a responsibility

I do not judge a prompt by how dense it looks. A short prompt can be precise. A long prompt can still be a pile of suggestions that never decide what should lead.

The useful question is whether every instruction has a reason to be there.

Successful prompt ≠ more words
Successful prompt = clearer responsibilities

If the rhythm drifts, I change the rhythmic behaviour. If the vocal sounds synthetic, I describe the delivery I wanted to hear. If the arrangement stalls, I look at motion or structure. Adding three more textures might make the next generation different, but it does not explain the problem I was trying to solve.

Listen before refining

The first result usually tells me more than the first prompt. I may know the destination, but I do not yet know which behaviours the model will lose on the way there. Once I can hear the problem—halftime drift, a static arrangement, an over-processed vocal or a melody disappearing under the new style—the next change becomes much easier to justify.

That is why I build prompts through listening. The first pass establishes enough of the idea for me to hear what the second pass needs to protect.

---

← Introduction · Guide contents · Next: Thinking in semantic roles →