While Loop Close | Deforum
The half of the loop that decides whether to go again
- flow_control
- initial_value0
- initial_value1
- initial_value2
- initial_value3
- initial_value4
- value0
- value1
- value2
- value3
- value4
Every While Loop Open | Deforum needs a While Loop Close | Deforum, and this is the half that does the heavy lifting. The open node starts the loop and passes in the initial values; this node receives the FLOW_CONTROL token, checks a condition, and makes the call: either the loop is done and it hands back the final carried values, or it recursively re-executes everything between it and the open node for another pass. If the open node is the loop's while, this is the : check condition, then branch.
The inputs: flow_control (the FLOW_CONTROL token from the open node), condition (a BOOLEAN, forced to a socket - it has to be computed inside the loop body, not typed), and five optional initial_value0 through initial_value4 wildcard inputs that receive the updated values from the body. The five outputs, value0 through value4, are the loop's final carried values - the ones you use downstream after the loop exits. The convention: when condition is false, the loop stops and the outputs are the current values. When true, the loop continues.
The mechanism is where this gets interesting, because it's not a for loop hidden in Python. When the condition says continue, the close node builds a copy of the entire subgraph between open and close using ComfyUI's graph-expansion system: it walks the dependency graph to collect every node in the loop body, clones them into a new graph (naming the clone of itself "Recurse" to keep node names from growing exponentially), rewires the links, and executes that copy as the next iteration. The values you pass into initial_valueN become the seed values for the next pass's open node. That's how a static graph becomes an actual loop - the engine keeps re-expanding the same region until the condition flips.
The canonical pattern in this pack: a frame counter carried through value0, a condition wired to something like counter < max_frames computed inside the body, and the body sampling a frame each pass. The pack's deforum_flux_complex example workflow is built exactly this way. When the counter finally exceeds the max, condition goes false, the loop unwinds, and value0–value4 carry out the final state - the accumulated latent, the last seed, whatever the loop was building.
The two things that bite people: an infinite loop, and forgetting the condition is a socket. If nothing in the body ever flips your condition to false, the loop re-expands forever - that's a warm GPU and an angry console, so make sure the condition is a real comparison wired from the body, not a constant true. And because the values are loop-carried through these sockets, any state that needs to survive iterations has to flow through them rather than sitting in a node widget that resets 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 model downloads, no extra Python dependencies; the repo relocated from XmYx/deforum-comfy-nodes to the deforum-art org. Loops need a recent ComfyUI (the graph-expansion machinery is modern), so if the close node errors oddly, update ComfyUI before debugging your workflow.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| flow_control | FLOW_CONTROL | — | |
| condition | BOOLEAN | — | |
| initial_value0opt | * | — | |
| initial_value1opt | * | — | |
| initial_value2opt | * | — | |
| initial_value3opt | * | — | |
| initial_value4opt | * | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| value0 | * | — |
| value1 | * | — |
| value2 | * | — |
| value3 | * | — |
| value4 | * | — |