IAMCCS_MiniMaxH3UniversalDeliverySourceR49

Multi-shot sequences and continuous keyframe sequences produce media in genuinely different shapes. Multi-shot gives you a selection - one take picked out of several, per interval. Continuous keyframe gives you a flow - a running sequence where each interval extends the last. Downstream you want one delivery path, not two parallel universes of decode/upscale/export nodes.

IAMCCS_MiniMaxH3UniversalDeliverySourceR49 is the adapter between those two worlds. It has fourteen optional inputs arranged in two mirrored sets of seven, and it emits one set. If that sounds like a mux, that's exactly what it is.

What it is

Required: cine_linx. Optional, all lazy, all forceInput (you can't type values in - they must be wired):

• selected_latent, selected_frames, selected_audio, selected_index, selected_total, selected_head_trim, selected_conditioning
• continuous_latent, continuous_frames, continuous_audio, continuous_index, continuous_total, continuous_head_trim, continuous_conditioning

Outputs are the same seven, un-prefixed: latent, frames, audio, index, total, head_trim, conditioning.

So the contract is simple in the end: wire both branches in permanently, wire the seven outputs to your delivery chain, and let the plan decide which branch feeds it.

How it works

The routing rule is one line of logic: if the shotplan's task mode is the continuous long-video keyframe mode, take the continuous_* set; otherwise take selected_*.

The lazy part is what makes it more than a switch statement. check_lazy_status reports only the missing inputs from the active branch. ComfyUI therefore never evaluates the other seven, which means the branch you're not using doesn't decode frames, doesn't materialise audio, doesn't run its samplers. In a graph where either branch is a multi-minute H3 render, that's the difference between one generation per queue pass and two.

The forceInput detail matters too: it tells ComfyUI these are link-only, so there are no widget boxes to accidentally fill with a typed 0 that then looks like real data. That's a small piece of API hygiene that saves a specific kind of confusion.

Worth naming why the fields exist at all. index and total carry position in the sequence (so your export names and report text know shot 3 of 12); head_trim carries how many frames at the head are context rather than content, which is the thing that silently eats your first half-second if nobody passes it along; and conditioning travels with the media because some downstream stages need to know what the shot was conditioned on, not just what came out.

What you configure

Nothing on this node. The branch is implied by the task mode you picked in the H3 Settings PRO surface - LONG MULTI-SHOT · HARD CUT versus LONG KEYFRAME CONTINUOUS in the public mode names, with the continuous one using the FL2VA continuous AV branch and the phase_aligned_extended full-AV latent handover.

The one habit to build: when you add a new generation mode, check whether this router knows about it. It routes on a specific mode string; anything unrecognised lands on the selected branch by default. That's a reasonable fallback and it will occasionally surprise you.

Install

Part of IAMCCS-nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart, hard-refresh the browser. Or ComfyUI Manager → search IAMCCS Nodes and install from there. One copy only in custom_nodes - the README flags duplicates as a source of stale definitions and frontend route mismatches.

No requirements.txt in the repo, so no pip step for the pack. You need ComfyUI 3.0.0+ and your own H3 weights, VAEs and text encoders. The router itself is pure plumbing and needs no model at all, which is why it's cheap to keep in every workflow.

Common issues

Wrong branch feeding delivery. Check the shotplan task mode first, then check that the branch you expected is actually wired. This node routes on the plan and has no idea whether you plugged anything into continuous_latent; an unwired active branch surfaces as a validation error upstream, not a friendly message here.

Validation errors mentioning inputs you never filled. Because they're forceInput, missing ones show up as unconnected sockets on the active branch rather than as null widgets. Read the error as "the active branch isn't complete."

Looks like both branches render. If something else in the graph consumes the inactive branch's outputs - a preview, a SaveImage, a second exporter - it's reachable and it will run. Lazy inputs only prune what this node asks for; they can't protect a branch that's independently connected to a terminal node.

Index/total come out as 0 or 1 for long sequences. Your generation branch isn't publishing them. The router faithfully passes through whatever the branch provides.

Where it fits

It sits between the two delivery-shaped ends of the H3 pipeline: the multishot selection output on one side, the True Long continuous output on the other, and one shared tail of upscale, decode and export after it. If you're maintaining two separate workflows because the modes produce different shapes, this node is the reason you can merge them - and merging them is usually worth it, because the delivery half is where the fiddly accumulated fixes live.