Nodes/SaltAI-Open-Resources/Keyframing Convert Iterative Execution List
ComfyUI Node

Keyframing Convert Iterative Execution List

Turn a schedule into a per-frame loop

By get-salt-AI·Created 2 years ago·Updated 2 years ago· 84
Keyframing Convert Iterative Execution List
  • list_input
  • float

Generating a schedule (48 frames of zoom values, say, from this pack's OPAC node) is only half the job. To actually use it, something downstream has to run once per value rather than receiving the whole schedule as one bundled object. OPACList2ExecList is that bridge - it converts a plain LIST into ComfyUI's native per-item execution mechanism, so a connected node fires once for every value in your schedule automatically.

What it does

One input, list_input (LIST), one output, float, marked as a list-type output (is_list: true in its schema) rather than a single bundled value. That distinction is the entire point of the node: ComfyUI has a built-in list-execution model where a node flagged this way causes anything wired to its output to run once per element, iterating automatically within a single queue run instead of you manually looping or re-queuing per frame.

Where it fits

This is the last link in the OPAC → animation chain: generate a schedule with OPAC, optionally convert it for mtb compatibility with OPAC2Floats if that's the pack you're actually driving, or run it through this node if you want ComfyUI's own list-iteration to handle the per-frame execution directly - feeding a per-frame transform node once for every value in your zoom, angle, or translation schedule without hand-building a loop.

Installing it

ComfyUI Manager: search SaltAI-Open-Resources. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/get-salt-AI/SaltAI

Restart ComfyUI. No extra dependencies.

Common issues

If you're driving several parallel schedules into separate per-frame loops - say, zoom through one OPACList2ExecList and angle through another - keep their source lists the same length. Mismatched list lengths across parallel schedules that are supposed to correspond frame-for-frame will desync, since each loop iterates independently based on its own list's length rather than being aware of the others. The cleanest way to avoid that is making sure every schedule feeding your animation comes from OPAC nodes sharing the same frame_count, rather than mixing schedules generated with different frame counts. And because this node hands off execution to ComfyUI's list-processing model rather than doing anything visible itself, if nothing downstream seems to be iterating, check that the node you connected the output to is actually built to consume a list-typed input rather than expecting one bundled value.

CategorySALT/Animation/Keyframing

Inputs (1)

NameTypeDefaultDescription
list_inputLIST

Outputs (1)

NameTypeDescription
floatFLOAT