VRGDG Remake Clip Queue

If you've ever built an AI music video the manual way, you know the pain: load the song, mark where each lyric lands, write a scene prompt, render that one clip, then repeat twenty times. VRGDG Remake Clip Queue is the loop that automates that repetition. It sits in the VRGameDevGirl video pipeline, reads your editor session and your original SRT, and hands the sampler exactly one scene's worth of data at a time - prompt, timestamps, frame count, audio, even the captured reference frame - so each queue run renders one clip and then advances to the next.

It's the workhorse behind the pack's "Remake Mode" and the queue-driven music video workflows the author publishes. Think of it as the queue-management brain of the Video Editor: the UI decides what a good clip looks like, this node decides what to render right now.

How it works

The node loads the editor session JSON (saved to vrgdg_temp/editor_session.json by the VRGDG Video Editor UI) and the original SRT file that was used to slice the video into clips. From those two it reconstructs the full clip list, then exposes one clip per execution based on an internal queue position.

Turn on enable_auto_queue and the position advances after every run; leave it off and queue_index (1..N) lets you jump straight to a specific remake item, which is exactly what you want when scene 14 looks bad and you don't want to regenerate 13 good ones. reset_queue wipes the counter back to the start before this run.

The trigger input is a wildcard pass-through that doubles as a "go" signal - wire a prim value, a button, or the output of a previous loop iteration into it so the node knows when to fire. signal_out mirrors it on the other side for chaining.

The inputs that matter

• session_path - path to vrgdg_temp/editor_session.json saved by the editor. This is your scene plan.
• srt_file - the original SRT used to make the clips; it supplies the lyric timing.
• enable_auto_queue / queue_index / reset_queue - the three knobs that control which clip runs now.
• tail_loss_frames (default 5) - how many frames to shave off the clip tail so LTX's frame-count math stays legal. LTX clips must be divisible by 8 plus 1, and this node does that arithmetic for you.

What comes out

The outputs are the shopping list for one scene: t2i_prompt and i2v_prompt (feed the sampler's conditioning), start_time / end_time, frames_for_ltx (the LTX-legal frame count), captured_frame_path (the reference frame for image-to-video), clip_path, and the sliced audio. is_valid tells you whether this clip is worth rendering - wire it into a switch or Impact Pack's queue logic so dead scenes get skipped instead of burned. total_selected, total_sets, and clip_number keep you oriented as the loop runs.

Installation

Same story as every node in this pack: ComfyUI Manager → search vrgamedev → install, then restart and hard-refresh the browser (these UI nodes ship JS that won't load on a stale page). Or clone into custom_nodes:

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

This node also needs the pack's requirements.txt (llama-cpp-python needs build tools on Windows - Python 3.12 is the safer bet), plus FFmpeg on your PATH for audio slicing and the Impact Pack custom node if you're using its auto-queue, which the author's music-video workflows do.

Where people get burned

The classic failure is a stale session: you edited scenes in the UI, then forgot to save the session before queueing. If the node emits nothing or the prompts look old, re-save from the editor. The other gotcha is frame-count drift - if LTX errors about dimensions, check frames_for_ltx is being used downstream rather than a hardcoded value, and leave tail_loss_frames at its default until you know why you're changing it. Start with a short project or a few scenes before committing to a long render; the author says it themselves in the README.