Scene Queue Node

Scene Queue Node is built for the storyboard workflow: write out every shot of a video or animation as JSON, drop it in once, and then each time the workflow runs it pops the next scene's text and feeds it forward. One queue, N generations, each one handling the next shot. It's a genuinely useful idea - people build entire external tools around exactly this "lay out shots, then generate them one by one" pattern - and this node is a tiny in-graph version of it.

How it works

You feed it a JSON document shaped like this:

{
  "scenes": [
    {"transcript": "Wide shot of the city at dawn.", "image_prompt": "city skyline, sunrise, wide angle"},
    {"transcript": "Close-up on the character's face.", "image_prompt": "close-up, soft light, portrait"}
  ]
}

On the first run it parses that, pulls the transcript and image_prompt values out of each scene into two in-memory queues, and returns the first scene's string. Every run after that pops the front of the queue, so the same workflow naturally walks down the shot list. It only re-parses the JSON when the scene_json input actually changes - otherwise it keeps popping from the already-loaded queue. Note the queues live in the node's memory, so a ComfyUI restart resets them and you start over from scene one.

Inputs and output

• scene_json - the multiline STRING holding your shot list. The parse uses scenes[].transcript and scenes[].image_prompt; if the JSON is malformed, the node doesn't crash - it returns a string like JSON error: <what went wrong>.
• trigger - a STRING input whose whole job is to force the next pop. ComfyUI only re-runs a node when an input changes, so this is your "advance to the next scene" handle: change its value, the node executes again, and the next scene comes out.

The single output is a plain STRING - whatever text the current scene is supposed to produce. Wire it into a CLIP Text Encode, or into an LLM/prompt-writing node if you want to expand a terse image_prompt before encoding.

The honest gotcha

I need to flag this, because the version of the pack I looked at does not run as cleanly as the design above suggests. The node's function signature expects two extra arguments (queue_name and default_queue_name) that the input schema never declares, so calling it the way ComfyUI wires it throws a TypeError - it reads like the node was refactored from a version with a "which queue?" dropdown and the inputs were never updated to match. If you load it and get a TypeError the moment it executes, that's why, and it's the author's bug, not yours. The intent above is still exactly what it's reaching for; treat the node as promising until you confirm your copy actually runs.

Installing it

Same pack as the other zygion utilities - no dependencies beyond the Python stdlib, no model files, nothing heavy to download. Easiest is ComfyUI Manager, searching i-zygion-util-nodes. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/zygion/comfyui-zygion-util-nodes

Then restart ComfyUI and look under Zygion Custom Nodes.

One more thing worth knowing: this pack has essentially zero community footprint - no reddit presence, no real Google impressions. If you're here because a downloaded workflow references it, that's the normal way people meet it. It works for what it is, but don't expect a support community behind it.