Reactor Sequence Join
Glue two renders into one without redoing the first
- sequences
- REACTOR_SEQUENCE
Chaining segment nodes in a straight line is fine until you want to reuse part of a sequence, or build a long one out of pieces you keep re-rendering. Reactor Sequence Join is the node for that: it takes several finished sequences and plays them one after another as a single sequence.
What it's for
Say you've built a five-segment Helios scene and want to follow it with a different ending depending on which way the story goes. Or you have a reusable intro sequence you keep dropping into projects. Or your timeline is 1400 frames long and the node graph has turned into a horizontal stripe. Join lets you build sequences in manageable chunks, keep them side by side on the canvas, and concatenate on the way into Reactor Render.
This is the same move as the context-object and switch layer the KB calls plumbing - small nodes whose only job is to make the graph legible. Nothing about the models changes; it's graph hygiene with an actual runtime effect, because the joined result is what gets compiled.
How it actually works
The node takes a growable list of sequences, each one being the last segment of a chain (or another Join), and concatenates their segments in order into one timeline. The first sequence's first segment sets the settings, exactly as it would if you'd chained everything by hand - so the model used, the aspect, the reference image, the persona and the like all come from whatever you plugged into socket one. Every later sequence's own start-of-chain settings are ignored, because a sequence is a sequence.
Each sequence enters by its own rule: if its first segment is a cut, the joined result cuts there; if it's a shot, it blends. Nothing is re-timed or re-scheduled beyond the model's normal chunk snapping, so a join can change where a boundary lands on the grid - worth a glance in the visualizer before a long render.
Inputs and outputs
- sequences - the autogrowing input. Sockets appear as you connect; the minimum is two and the maximum is 32. Connect each sequence's final segment (or a nested Join).
- REACTOR_SEQUENCE (output) - the combined sequence. Feed it to Reactor Render to render it, and to Reactor Sequence Visualizer if you want to see it first.
Install
ComfyUI Manager, search comfyui-reactor-api ("Reactor API: Realtime Video"), or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/reactor-team/comfyui-reactor-api
pip install -r comfyui-reactor-api/requirements.txt
One dependency (reactor-sdk>=1.6), no model downloads, and you need an API key before anything renders - REACTOR_API_KEY in ComfyUI's environment, or config.ini under [API]. Restart afterwards; the nodes appear under Reactor.
Where people get burned
Mixing models. A joined sequence is compiled against one model, so the pack checks and refuses: "Sequence 2 is for Helios and sequence 1 for Visko Orbis Stable; join sequences made for the same model." That's not a bug you can work around - a Visko Orbis segment node simply won't accept a LingBot World 2 chain, and vice versa. If you want two models in one output, render twice and cut them together outside ComfyUI.
Settings expectations. People plug a carefully configured second sequence into socket two and expect its settings to apply. They don't. Whatever the first chain opens with is the whole joined sequence's setup; set it there.
Join isn't a mux. It concatenates Reactor clips for the same model, not arbitrary videos. Two unrelated MP4s you already have on disk are a different problem - that's a video-merge node, not this.
Order is socket order. The sockets are named by position, so keep sequence_1, sequence_2 visually stacked top to bottom in your graph or you'll be debugging a story that plays out of order.
Is it worth the extra node?
For two short sequences, honestly, just keep chaining segments. Join earns its place when you're reusing a sub-sequence across graphs, when a long timeline is getting unwieldy, or when you want to A/B one act against two different endings without rebuilding the front of the story. That last one is the reason I'd keep it around.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| sequences | COMFY_AUTOGROW_V3 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| REACTOR_SEQUENCE | REACTOR_SEQUENCE | — |