Apply Arrangement

Here's the risky part of creative modes: you asked a language model to plan music, and now something has to write that plan into a real score without producing garbage. Apply Arrangement is that something. It takes the JSON plan the writer produced and writes it into YuE2's score - chords that fit the melody, the instrument line of every section (note by note, written by Plenio, not by the model), key lifts and the tempo. Every step is validated. When that fails, the node's whole personality is that it does nothing and tells you why.

It's an experimental feature in the pack's own words, and it's the dependent half of a pair: Compose Arrangement asks the writer, this one applies the answer. Local music models are strong on instrumentals and wobbly on vocals and lyrics (docs/knowledge/audio-generation.md), so this is the node that exists to keep the voice's melody sitting on top of the harmony instead of getting smeared under it.

How it works

The writer answers with section-level intent, never notes, and Plenio turns that into validated score operations. A harmony guard argues with it as it goes: each proposed chord is checked against the melody line, and its repairs come back as a plain-language summary - what share of melody notes landed on chord tones, how many accented clashes were left, how many chords stayed in the key.

Then the arranged score has to survive four checks. It must pass YuE2's own parser, read back unchanged, open in the score editor, and fit YuE2's context budget - the node compares how many seconds of music the model can actually hold against the arranged score's real length. Fail any one and the score is passed straight through, untouched, with the reason in the report. Your render still works; you just get the truth instead of a broken graph.

The re-ask round

This is the bit worth understanding before you copy the template. If the harmony guard had to repair chords, reask_prompt goes back to the writer - only the sections that needed repair - with reask_schema for the same exact-format treatment. Run a second Apply Arrangement with the first one's state feeding its first input, and it keeps whichever arrangement is better. Compose → write → apply → write → apply. That's the shape you see in the templates.

Inputs and outputs

• score - the ABC to arrange.
• brief - the creative mode and the closeness come from here.
• answer - the writer's answer to Compose Arrangement's prompt. It's lazy: with arrangement off, a cover kept at its original song flow, or no score, the writer is never asked at all.
• engine - needed for the real context-budget check; without YuE2's tokenizer there is no check.
• style, lyrics - for an exact token budget (a cover's are estimated, since its words are written later).
• seed - varies the notes Plenio writes for the instrument lines. Same seed, same notes.
• first - the first Apply Arrangement's state, which turns this node into the re-ask round.

Outputs: score (the arranged score, or the score as it was) into the Song Sheet and the render; report into Song Sheet · Score's Arrangement line; plus reask_prompt, reask_schema and state for the second round.

Installing it

Nothing node-specific. The pack installs with no Python packages at all - an empty requirements.txt is a deliberate choice here, not an oversight.

cd ComfyUI/custom_nodes
git clone https://github.com/jplenio/Plenio-Music-Production-System

Manager: search Plenio Music Production System. CLI: comfy node install comfyui-plenio-music. Restart, then open 0 · System Check and run it - it reports your ComfyUI version, GPU, which template model files are still missing, and whether a llama.cpp runtime was found. ComfyUI 0.37.0 is the floor; on anything older the native nodes behind this pack simply aren't there.

When it misbehaves

Arrangement not applied is the one you'll meet. It means the writer's answer wasn't a plan, the arranged score failed a check, or the arrangement got too long for YuE2's context. Read the reason in the sheet, then run again with another arrangement seed, or switch the writer model to a GGUF, LM Studio or Ollama model - those are held to the plan's format exactly, which is often the fix. The score as it stands can still be approved and rendered.

Arrangement ... partial is milder: chords that clashed with the melody, an instrument line that stepped on the voice, or a key lift that would push the singer out of range were kept out. Another arrangement seed gives you another plan. And if the arrangement code itself hiccups, the run doesn't die - the score is used as it was, with the traceback in the ComfyUI console for a bug report.