Batch Data
The node that tells your loop body which frames it's rendering
- batch
- index_play
- frames_count
- frames_first
- frames_last
- latent_previous
- filename
Batch Data is the inside-the-loop companion to the pack's Play (Start)/Play (Continue) mechanism. It unpacks the current batch_current into the individual numbers your sampler and save nodes actually need. You drop it in the loop body, wire Play (Start)'s batch_current into its batch input, and suddenly every iteration knows exactly what chunk of the play it's rendering and under what filename.
Why does this exist? Because in this pack a "batch" isn't a sampler batch - it's a chunk of your narrative, with its own index, its own frame range, and its own output filename, pre-computed by Play (Start) when it flattened the tree. The loop body needs those facts to configure the sampler and to save each chunk without clobbering the last one. That's this node's job, and it does nothing else.
The outputs that matter
frames_first,frames_last- the inclusive frame range of this chunk within its beat. If your sampler needs to know it's drawing frames 41–81 of a 90-frame beat, here they are. Handy for frame-number-conditioned workflows.frames_count- how many frames this batch holds (usually yourframes_count_per_batch, except the last chunk of a beat, which gets whatever's left).index_play- a global running counter across the whole play (not just within the beat), so every chunk in the entire production has a unique number.filename- the fully-built output filename for this chunk (likefot_play_#1_#1_b1_1_2), assembled fromfilename_baseplus everyfilename_partup the tree plus index. Wire this into your save node and your chunks self-organize.latent_previous- the previous chunk's ending latent, threaded through for continuity. This is the pack's answer to "how do I avoid my video strobing between chunks?" - the loop body should pass its final latent back into Play (Continue) so the next batch starts from it.
The batch input is optional (type BATCH); if you leave it unwired, the outputs come back empty and the node is a no-op - useful for a dry-run template, useless for anything real.
Installing
With the rest of the pack, via ComfyUI Manager (search "comfyui_play_traversal") or:
cd ComfyUI/custom_nodes
git clone https://github.com/wgedeon/comfyui_play_traversal
pip install -r requirements.txt
Restart ComfyUI. Standard heavy install - diffusers, accelerate, onnxruntime, opencv-python, spandrel, peft, clip_interrogator, sentencepiece, matplotlib, lark - no models downloaded.
Where people get burned
- It has to be inside the loop. Wire this from Play (Start)'s
batch_current, and note that on each expansion the new batch gets injected - if you wired it from a stale source, you'll keep seeing the same chunk. latent_previousis a passthrough, not a guarantee. The node hands you the socket; the actual latent from the last iteration has to be fed back through Play (Continue) for continuity to work. Skip it and you get chunks with no connection between them.frames_lastof one chunk isframes_first - 1of the next. The frame ranges are contiguous by design, so you can build transitions (crossfades, the "cut, fade_to_black" stuff the README mentions) on top of them.- The pack is early-stage and single-author; if the numbers look off, check the console - Play (Start) prints the whole batch table while it builds it, and it's the ground truth for what this node will report.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| batchopt | BATCH | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| index_play | INT | — |
| frames_count | INT | — |
| frames_first | INT | — |
| frames_last | INT | — |
| latent_previous | LATENT | — |
| filename | STRING | — |