VRGDG_GeneralPromptBatcher

A full music video is hundreds of scenes, and nobody wants to hit the queue button 400 times. VRGDG_GeneralPromptBatcher exists to turn a huge prompt list into a series of manageable batches that ComfyUI runs for you - and with enable_auto_queue on, it re-queues itself until the whole job is done. This is the node that turns "render an entire song's worth of scenes" into a set-and-walk-away operation.

How it works. You paste your prompts into input_1 (with optional input_2 through input_4 for more columns, plus global_input_1 and global_input_2 for text you want appended to every prompt in every batch). Set batch_size - 10 by default - and the node carves your list into chunks of that size. It then outputs the current batch's prompts, tells you which batch you're on, how many batches remain, and whether this is the last one. When enable_auto_queue is true, it queues the next batch automatically, so the chain keeps going without you.

The trigger input is typed * - anything - and it's the ordering guarantee: wire whatever generates or finalizes the prompts into it, and this node won't fire until that's done.

The outputs that matter.

• prompts - the current batch's prompt text, ready for your sampler.
• batch_index / total_batches / is_final_batch - the progress trio; is_final_batch is how a downstream node knows to stop looping.
• output_folder / file_prefix - where the batches get written and what they're named. file_path (default general_prompt_batches) and file_prefix (default Batch) are the matching inputs you set once.

The author's music video setup pairs this with the Impact Pack's auto-queue functionality - that's the same "keep running until done" philosophy, applied at the workflow level.

Installing. It's in the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl

or install vrgamedev via ComfyUI Manager and restart. If you plan to use the auto-queue feature, make sure Impact Pack is installed too, since that's what the surrounding workflow relies on.

Where people get burned. batch_size too big is the classic OOM move - a batch of 10 at high resolution will happily exhaust your VRAM, so if runs die mid-batch, shrink batch_size rather than your resolution. And don't mistake this for a generator: it batches prompts you already have; the LLM that writes them is a separate node upstream. If total_batches is 1 when you expected 30, your input probably arrived as a single block instead of a list - check the format feeding input_1.