FixedQueue

ComfyWarp is a loop: extract a frame, diffuse it, save it, move to the next. Something has to hold "which frame am I on" and drive every step of that loop, and that's FixedQueue. On the surface it's three INTs in, three INTs out - start, end, and current_number become current, start, and end. But the real work happens in the pack's JavaScript: the node grows Queue from start, Queue from current frame, and Interrupt buttons, and every time a prompt finishes it auto-increments current_number. When the counter passes end, it stops the auto-queue. That's the entire loop, driven from the node.

This is a ComfyUI-native answer to what the author had to hand-roll in the original WarpFusion notebooks: a fixed iteration range that re-queues the same graph with a changing frame number. The inspiration is credited to Fannovel16's ComfyUI-Loopchain, and the practical effect is you click "Queue from start" and the whole video renders without touching the queue again. Wire current into everything that needs the frame number - the frame loaders, the schedulers, SaveFrame, and RenderVideo's current_frame - and the graph stays in sync by construction.

The inputs that matter

• start (default 0) and end (default 1) - the loop range. start is where the counter begins, end is where it stops.
• current_number (default 0) - the live position. The JavaScript increments it after each queued prompt, and it's what the rest of the graph reads via the current output.

The gotchas

First, the buttons and the auto-increment come from the pack's js/main.js, so if you installed only the Python half or the JS failed to load (look at the browser console), the node will work as a plain counter but never advance on its own. The tell is missing buttons. Second, this is a frontend-driven loop - it relies on ComfyUI's auto-queue being enabled, which the buttons toggle. If you bypass the buttons and just hit the main Queue button, nothing advances, because nothing triggers the increment.

Also note the field name: the schema calls the counter current_number and current is the output name - the README says current_frame, but the node speaks current_number. If you're porting a workflow, follow the node's port labels, not the docs. For a long render, wire end (or the dataset's total) into RenderVideo's render_at_frame so the video export fires exactly when the loop finishes - the sample workflows (warp_0.5.0_queuemany.json) show this end-to-end. That's the whole game: one node, three buttons, and a loop that closes itself.