Satyr Read (Plan → Map) 🐐

YuE2 composes before it performs. It writes an ABC score - vocal melody, instrumental melody, chords, section labels - and then renders that score into audio, and the score arrives as a plain string you can read. Satyr Read is the node that reads it for you.

This is the boring node in the Satyr suite and, in practice, the one you'll open first every time you change something upstream. It changes nothing: whatever you wire in comes out untouched, and a report drops out the side.

What the map tells you

Feed it a plan from YuE2 Generate ABC, or from Satyr Import, or pasted in by hand, and you get:

• the meter, tempo, bar length and total duration in seconds;
• whether the plan holds one voice or two, and where the two registers sit;
• every phrase, with its timing, bar count, syllable budget and the voice that takes it.

That last column is the one that answers the question people actually have. Asked in style for two singers, YuE2 writes both into the one monophonic Vocal line as two pitch bands, and which band a phrase sits in does track which singer took it - in every song measured. So this report is the thing that tells you whether a plan has two separated registers at all. A plan with one band has no female part to move, however the style string was written, and knowing that saves you an hour of fiddling with plans that never had a chance.

One distinction the node draws carefully, and it's worth internalising: a band's notes overlap. A phrase belonging to the man as a whole still reaches up into the woman's notes for a syllable or two. What separates cleanly is the phrase median, because a phrase goes to one singer whole - so that's what classifies it, and what any move would aim at. Don't read a stray high note as a second voice.

Inputs and outputs

Two inputs, mercifully:

• abc - the plan, from YuE2 Generate ABC or anywhere else.
• verbose - on by default, which prints the map to the console. The same text is always on the report output either way, so if you'd rather have a quiet console, turn it off and wire report into a Show Text (Markdown) node or save it to a file.

Two outputs: report (STRING) and seconds (FLOAT).

seconds is the plan's own duration, and it's the honest number to size your latent with - the model performs it a few per cent faster than stated, so the audio comes in slightly shorter than the plan. Wire it into Empty YuE2 Latent Audio rather than typing a duration. A plan and a latent that disagree gives you a song truncated at the end or trailing silence, and it's the most common mistake in this corner of the hobby.

Reading it as a diff

The report is also the cheap way to see what an edit did. Run Satyr Score or Satyr Trim, read the map before and after, and you know exactly which bars moved. Satyr Score is built for that - lines it doesn't decide to change come back byte for byte - but the map is how you see the difference, since a plan that got shorter or busier looks like soup in the widget.

Installing it

Part of Kinburg-Nodes. ComfyUI Manager → search Kinburg-Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Kinburg/Kinburg-Nodes

Restart ComfyUI afterwards. Satyr Read is pure Python over a string - no model files, no extra packages, nothing the pack's install.py needs to do for it.

Where people get burned

Treating the register as a control. It's a correlate worth reading and a control worth not promising. A plan with two clearly separated bands does not guarantee two singers in the render; that was the hope behind the whole suite and it never reproduced as a lever. Use the map to understand, not to promise.

Feeding it something that isn't an ABC score. It reads rather than validates, so a half-copied plan or a lyrics file gives you a confident, nonsense map. If the duration looks absurd, the input is the problem.

Ignoring seconds. It's the one output of this node that changes your render rather than your understanding.