IAMCCS_ShotboardVideoEditorOptionalR49

Multigeneration workflows produce a pile of clips. The moment you want to change their order, drop a take, or ride one shot three frames earlier, you're back in the graph queue - re-rendering a sequence that was already fine.

The Shotboard Video Editor exists so you don't. It collects rendered takes into a manifest - a JSON description of what's on the timeline, at what time, on which track - and that manifest becomes the thing you edit. IAMCCS_ShotboardVideoEditorOptionalR49 is the "Optional" subclass of that editor: identical behaviour, but non-terminal, so it only runs when a downstream branch asks for it.

What it is

Required inputs include one that surprises people: take_package_json, marked forceInput, so it must be wired. It's the package of rendered takes coming out of the multigen pipeline. Then session_key (default shotboard_video_editor_v1), which names the editor session so successive passes accumulate into the same timeline rather than starting a new one each queue.

collect_policy, append_mode and fps look like enums but are typed as STRING deliberately - the author's comment says it's so a stale frontend widget order can't fail Comfy validation before the node gets a chance to repair the values. There's even migration code for the case where a JSON blob ended up in the fps widget. It's unglamorous, and it's the difference between a workflow that survives a pack update and one that doesn't.

Optional: cine_editor_linx for a second bus, and five numbered video slots (video_1 … video_5) with five matching audio slots (audio_1 … audio_5), plus master_audio. Five is the ceiling per pass - for longer sequences, the session accumulates across queue passes.

Outputs: cine_linx, editor_manifest_json (the thing you actually care about), and report.

How it works

collect_policy decides what a new take does to the timeline. The valid values, straight from the source: append_sequence (the default - add it after whatever's there), append_same_lane, replace_same_take, and append_always. append_mode picks between append_sequence and timeline_origin. When you're re-running shot 4 because the hands were wrong, replace_same_take is the one that stops you ending up with two shot 4s and a timeline that's four seconds too long.

Each collected take becomes a clip entry with an id, a take index, a start time, a track, and - importantly - a linked audio clip. The node keeps video and audio as separate clips linked by linkedClipIds, which is why the editor can trim a shot's picture without detaching its sound, and why the render step has an audio policy at all. The assembly order list gets updated, the generated sequence gets enforced, hard cuts get enforced, and the manifest duration is recomputed.

And the node returns float("nan") from IS_CHANGED, which forces it to re-run on every queue pass. That's not laziness; it's a fix. The author's comment spells out why: this node persists rendered clips into a session manifest, so reusing a cached first-pass result would silently drop segment two and beyond while H3 keeps rendering and saving. If you've ever wondered why a collector "misses" takes, the answer is usually a cache, and this is the defence.

The "Optional" part

The base IAMCCS_ShotboardVideoEditorV1 is a terminal node. This subclass sets OUTPUT_NODE = False, which makes it non-terminal and therefore lazy-compatible: it only executes when something downstream requests editor_manifest_json. In the R45 Universal workflow that "something" is the final gate, and only when h3_editor_enabled is on.

Practical consequence: a workflow with this node wired but the editor disabled will not spend any time collecting. That's the point of the R45 split between an always-on direct master and an opt-in edit path.

Install

Ships in IAMCCS-nodes:

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

Restart, hard-refresh, or install via ComfyUI Manager by searching IAMCCS Nodes. One copy only - duplicates produce stale definitions, and on a node with custom frontend behaviour that's a confusing failure.

No requirements.txt in the repo, so no pip step for the pack. ComfyUI 3.0.0+ and your own models. The editor's custom UI lives in the pack's web directory and comes along with the clone; if the panel looks wrong after an update, a hard browser refresh is the first thing to try.

Common issues

Takes vanish between passes. Normally the cache defence above; if it persists, check that session_key is stable. A different key is a different session, and different session means an empty timeline.

The timeline grows on every re-run. You want replace_same_take, not the default append_sequence. This is the most common complaint about take collectors in any node pack, and it's a policy choice rather than a bug.

Nothing appears to happen at all. Non-terminal node with nothing downstream requesting the manifest. Wire it into the render step or the R45 gate.

Clip audio detached from clip picture. Something rebuilt the manifest outside the node. The link between the video clip and its audio clip is what the render step uses to keep them together; hand-edited JSON is easy to get wrong here.

Where it fits

Collect → this → IAMCCS_ShotboardVideoEditorRenderOptionalR49 (which turns the manifest into frames again) → R45 Video Editor Exporter · Lazy → R45 Final Master / Optional Editor Gate. The manifest is the interchange format for that whole chain, and it's plain JSON, which means you can inspect it, diff it, or hand it to someone else's tooling.