DiffusionGemma H3 Shot Seed Fanout

Multi-lane H3 rendering needs per-lane seeds, and the naive approach - seed, seed+1, seed+2 - is a trap. Adjacent seeds produce correlated noise, which makes lane boundaries visibly inconsistent, and nothing ties a lane's seed to this project, so the same lane layout on a different song produces different randomness than you expect. DiffusionGemma H3 Shot Seed Fanout fixes both by deriving deterministic per-lane video seeds from the separate H3 root seed and the project id, using a SHA-256 domain-separation scheme.

It's a small, focused node with a clear contract, and the code makes the mechanism impossible to misread. For each lane index it hashes a namespaced string - diffusiongemma.h3-shot-seed@1, the root seed, the project id, and the lane number - and takes the first 8 bytes as the lane seed. Same root seed + same project id → same four lane seeds, on any machine, forever. Change the project or the root and every lane changes.

Inputs and outputs

• root_seed - default 42, scoped to the full 64-bit unsigned range. This is the video root seed, deliberately independent of the song seed that drives audio audition elsewhere in the pack.
• project_manifest_json - connect the Project Master Contract's manifest. This isn't optional decoration: the node requires a valid project master contract with a project_id and raises if it's missing, because the whole point is that lane seeds are bound to the project identity, not floating free.

Outputs are shot_1_seed through shot_4_seed (plain INTs you wire into each lane's sampler) plus seed_report_json documenting root, project id, and the derived seeds. The shot_1..4 socket names are legacy - they predate the planner's "generation lane" vocabulary and are kept so saved workflows keep loading.

Why this beats the obvious approach

Three reasons, all of which show up in the README's planning stack. First, determinism with a purpose: reproducibility on a music-video pipeline requires that re-running the same queue with the same root gives you the same video noise on every lane - that's what makes the whole "test A2V influence with the same locked song and video seed" ritual possible. Second, independence: audio and video seeds are separate axes, so you can vary the song audition without disturbing the video plan (and vice versa). Third, project binding: a lane seed is meaningless outside its project; tying it to project_id means two projects that happen to share a root seed still diverge, and re-seeding one project doesn't scramble another.

Installing it

Part of exportAnything/ComfyUI-DiffusionGemmaPromptBuilder, under prompt/diffusiongemma/production-planning:

cd ComfyUI/custom_nodes
git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder

or search DiffusionGemma Prompt Builder in ComfyUI Manager and restart. Pure hashing - zero model, zero VRAM, zero surprises.

Common issues

• "project_manifest_json is not a valid project master contract." You connected the wrong thing, or the manifest is empty. Feed the project_manifest_json output from the Project Master Contract node.
• Lanes don't change when you expect. If you bumped a song seed expecting video to change, remember the separation - this node only responds to root_seed and the project id. Change root_seed (mind control_after_generate) for new video variation.
• Seeds not reproducible across machines. If you're hand-entering root seeds and getting different results, check that you're not letting a randomize control overwrite the root between queues - the fanout itself is deterministic by construction.