IAMCCS Shotboard Video Editor V1

The Shotboard multigen workflow generates a bunch of takes - several clips per timeline slot, with audio - and eventually someone has to turn that pile into an actual sequence. IAMCCS_ShotboardVideoEditorV1 is the collection stage: it gathers rendered takes (videos and audio, or a take package already serialized as JSON), appends them in order, and builds an editor_manifest_json describing the assembly. Its sibling ShotboardVideoEditorRenderV1 later turns that manifest back into a video.

It's the "editor" in the sense of an edit-decision list, not a pixel editor. It doesn't render frames itself - it records what goes where, in what order, with which audio, so the render stage has a complete description.

How it works

It takes a cine_linx (the plan from the planner) plus the generated material: up to five VIDEO inputs (video_1–video_5), up to five AUDIO inputs (audio_1–audio_5), an optional master_audio for the final mix, and take_package_json for when takes arrive already serialized. collect_policy / append_mode (both default append_sequence) control whether new takes append to the session or replace it, and session_key scopes the session so you can run multiple editor instances in one graph without them colliding. The output is an updated cine_linx, the editor_manifest_json (which can be handed straight to the render node), and a report.

Note the fps, collect_policy, and append_mode fields are strings that the custom frontend hides - they're kept as text for backward-compatibility so old workflow JSONs don't fail validation, and the node normalizes them internally.

Inputs and outputs

• cine_linx (required) - the plan carrying timeline identity.
• take_package_json, session_key, collect_policy, append_mode, fps - session control.
• Optional: cine_editor_linx, video_1–5, audio_1–5, master_audio, editor_manifest_json (pre-seed an existing manifest to keep appending to it).
• Outputs: cine_linx, editor_manifest_json, report.

The node is an output node (OUTPUT_NODE = True), so it runs last in the graph and displays its result - the manifest is the deliverable here.

Installing

ComfyUI Manager → search "IAMCCS", or

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

Restart. No new dependencies for collecting takes - the pack's SuperNode requirements (native LTXV nodes, VideoHelperSuite, MTB) apply to the generation and combine paths you're feeding it from.

Gotchas

The append-vs-replace confusion is the most common stumble: with append_sequence, every run of the graph adds to the session, so re-running after fixing a take silently grows the manifest with duplicates. Set it to replace mode (or clear the session) when you're iterating. Also, because fps is a string widget, a stale value like "24" from an old workflow is normalized at runtime - but if the manifest and the videos disagree on fps, the render stage's fps_mode = from_manifest will trust the manifest. Make them agree.