🎛️ Audio Batch Selector

The batch loop pattern has a second rhythm problem that people forget about until they hit it: it's not just frames you're walking through, sometimes it's files. Say you've got a folder of voice tracks and you want the loop to process one track per cycle, in order, and know when it's done the whole batch. That's exactly what AudioBatchSelector does - it's the audio counterpart to the frame calculators, dispatching one item from a loaded list on each cycle.

It pairs with the pack's BatchAudioFolderLoader (which loads a whole folder of audio into a list) and sits upstream of whatever generates or processes a single track. One file per cycle, batch_index tells you where you are, and the loop trigger knows to stop or advance to the next file when the batch runs out.

How it works

It takes the audio list and the parallel list of file names, then reads the pack's global batch counter to pick the current file - deliberately not the loop index. That separation matters: current_loop_index walks the timeline/scenes, while the batch index walks the file list. They advance on different schedules, and this node is the one that stays in sync with the files.

It reports total_batches so you always know the size of the list, and it updates the pack's global_has_more_batches flag - that's what lets the SequentialLoopTrigger decide whether to stop at the end of a batch or roll on to the next file. Neat trick: when the last file finishes, the trigger resets the loop index back to 0 and starts the next file fresh.

Inputs and outputs that matter

• audio_list (AUDIO_LIST) - the batch, straight from BatchAudioFolderLoader.
• file_names (STRING_LIST) - matching names, same order.
• current_loop_index (INT) - from SequentialLoopStart, so the node knows which cycle it's in.

Outputs: current_audio (AUDIO) and current_file_name (STRING) go downstream into the processing chain; batch_index (INT) and total_batches (INT) are your "where am I" readouts; log (STRING) gives a one-line status per cycle.

When you'd use it

The README's example is a TTS/voiceover pipeline: a folder of narration files, each one becomes a video scene in a loop. But the same shape works for any "many files, one GPU" workflow - a batch of reference clips, a pile of music stems. If you only ever process one audio file per run, this node is dead weight; if you're looping over a folder, it's the thing that makes the loop actually terminate correctly instead of re-processing the first file forever.

Install

ComfyUI Manager → "comfyui-sequential-batcher", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Meisoftcoltd/comfyui-sequential-batcher

Restart ComfyUI. No model downloads. You'll want BatchAudioFolderLoader (same pack) on the front of it, and remember the house rule: run without --highvram so the loop's memory management can actually clear VRAM between cycles.