While Loop Open | Deforum
Loop your whole subgraph until a condition flips
- initial_value0
- initial_value1
- initial_value2
- initial_value3
- initial_value4
- FLOW_CONTROL
- value0
- value1
- value2
- value3
- value4
ComfyUI is a graph, not a program - it has no native loops. While Loop Open | Deforum is half of the pair that fakes one, and it's the foundation of how this pack generates animations frame by frame. It's the loop header: it emits a FLOW_CONTROL token, seeds the loop's working values, and defines the region the loop body lives in. Its partner, While Loop Close | Deforum, is where the actual looping happens.
You put an open node, then the nodes that do one frame's work, then a close node. The open node's condition is a BOOLEAN (default true) that decides whether the loop runs at all on entry, and its optional initial_value0 through initial_value4 (five wildcard sockets) establish the values the loop carries. On the way out it gives you the FLOW_CONTROL output plus those five value0–value4 outputs. Whatever you wire into the initial values - a latent, a seed, a frame counter - becomes the "loop variables" that the body reads and the close node updates.
The mechanism is genuinely clever and worth understanding, because it's why this isn't just a Python while smuggled into a node. When the close node decides the loop should continue, it uses ComfyUI's graph-expansion machinery (the GraphBuilder / execution-inversion system) to build a copy of every node between the open and close nodes, rewire their links, and execute that copy as the next iteration - naming the recursive copy "Recurse" to keep node names from growing exponentially. So each iteration is a real, separate graph execution, with values flowing from the previous iteration's close into the next iteration's open. That's how a graph without loops gets loops: the engine re-expands the same region until the condition says stop.
Where you'll actually meet this node: the pack's own example workflow, deforum_flux_complex, drives frame generation through exactly this loop structure - each pass samples a frame, the loop variables carry the accumulated latent forward, and iteration continues until the frame count is hit. The essential companion detail: the condition on the close node is forced to a socket, so the "should I keep going?" decision has to be computed inside the loop body (a frame counter compared against a max, for example). If you wire nothing, the open's default-true condition will happily start the loop, and then it's the close side's job to end it.
Two gotchas to keep in mind. First, this pack's loop nodes require a reasonably modern ComfyUI because they lean on execution inversion - if your install is ancient, the loop machinery won't be there to back it. Second, remember the values are loop-carried: if you want state to survive iterations, route it through the valueN sockets, not through node parameters that reset each pass.
Installation is the pack: ComfyUI Manager → search "ComfyUI-Deforum" or deforum-comfy-nodes → install and restart, or git clone https://github.com/deforum-art/deforum-comfy-nodes into ComfyUI/custom_nodes and restart. No models, no extra dependencies. The repo moved from XmYx/deforum-comfy-nodes to the deforum-art org, so old workflow files may point at the earlier URL. Loops are the hardest concept in this pack, but they're also the reason it can do what it does - worth the hour of head-scratching.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| condition | BOOLEAN | true | — |
| initial_value0opt | * | — | |
| initial_value1opt | * | — | |
| initial_value2opt | * | — | |
| initial_value3opt | * | — | |
| initial_value4opt | * | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| FLOW_CONTROL | FLOW_CONTROL | — |
| value0 | * | — |
| value1 | * | — |
| value2 | * | — |
| value3 | * | — |
| value4 | * | — |