CD · Batch Director

This is the node that turns a plan into work. You've locked your project, characters, scenes, and shots into a manifest - now you hand CDBatchDirector a storyboard and it expands every shot into a chain of takes, each with its own deterministic seed. It's the "directing" part of Continuity Director, the step between "here's what the production should be" and "here's the actual batch of generations to run."

What you feed it

• manifest - a CD_MANIFEST wire from CDManifestBuilder. Required, and it should feel wrong to run without one: the whole point is that takes inherit the locked project state.
• storyboard_json - the big one. A JSON array of shot objects, or a list under a shots key. Each shot can carry id, prompt, negative_prompt, duration_seconds, camera, character_ids, references, and depends_on. The default shows the shape: [{"id":"shot-001","prompt":"Opening shot"}]. The pack ships a real starter_storyboard.json in examples/ worth copying.
• takes_per_shot - 1 to 16, default 3. How many takes each shot expands into.
• base_seed - the anchor. Takes get seeds derived from it, so the whole batch is reproducible from one number.

How the seeds work

The seed math is the part people actually care about, so here it is: each take's seed is base_seed + shot_index * 1000 + take_index. Shot three, take two on base 1000 gets 3021, every single time. Same manifest, same storyboard, same base seed → same take list, byte for byte. That determinism is what lets you re-run just one take later instead of the whole batch.

Outputs: shot_chain (a CD_SHOT_CHAIN wire for CDExecutionPlan), shot_chain_json (the expanded chain as text - inspect it to see every take, its seed, prompt, and dependencies), and take_count (a plain integer, handy for progress math).

The workflow shape it implies

Shots can declare depends_on - the example storyboard has shot two depending on shot one's first take, which is how you express "this take should be generated with the previous one's last frame as reference." CDExecutionPlan reads those dependencies and schedules waves of parallel work around them. And because every take carries the manifest's locked character and scene state, the reference-driven consistency work downstream starts from a stable spec instead of a hope.

Installing it

No models, no keys, zero Python dependencies - requirements.txt is literally a comment saying "No mandatory third-party Python dependencies." The whole pack is standard library. Search "Continuity Director" in ComfyUI Manager and restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/xinjian0101/continuity-director.git ComfyUI-ContinuityDirector

Restart ComfyUI; nodes appear as CD · ... and there's a Continuity Director sidebar with an "Add starter chain" button that wires up this exact pipeline for you. Update with git pull.

Where people get burned

The two usual suspects: malformed storyboard JSON (the error message names the line and column - read it), and duplicate shot ids (rejected loudly). Also resist the urge to cram everything into one storyboard blob; the references and depends_on fields are the mechanism for cross-shot continuity, and using them beats hoping the model remembers. One honest caveat: this pack is young (v0.8.42, active preview), so the JSON it emits is your ground truth - keep exported packages and don't assume the node widget state tells the whole story.