XB-BOX - Dynamic Bus
A 20-lane wire bundle for when your graph looks like spilled spaghetti
- in_1
- in_2
- in_3
- in_4
- in_5
- in_6
- in_7
- in_8
- in_9
- in_10
- in_11
- in_12
- in_13
- in_14
- in_15
- in_16
- in_17
- in_18
- in_19
- in_20
- out_1
- out_2
- out_3
- out_4
- out_5
- out_6
- out_7
- out_8
- out_9
- out_10
- out_11
- out_12
- out_13
- out_14
- out_15
- out_16
- out_17
- out_18
- out_19
- out_20
Dynamic Bus is the simplest node in this pack and one of the most useful once your workflows cross a certain size. It's a straight N-in / N-out relay: up to 20 lanes, each AnyType, where whatever goes in in_5 comes out out_5 untouched. That's the entire mechanic - which is the point.
Its job is visual, not computational. When a KSampler needs a model, a clip, a conditioning, a latent, and a seed from five different corners of the graph, you can either run five long wires across everything or bundle them through the bus so they travel together in a neat lane. The wires become legible again, and nodes you swap in and out don't drag a tangle of connections behind them.
How it works
The Python side is as honest as it gets: it accepts up to 20 optional AnyType inputs (in_1 through in_20) and returns the same count of outputs, passing each value straight through. Because the types are wildcards, one bus can carry a MODEL on lane 1, a CONDITIONING on lane 2, and a plain INT on lane 3 - no type restrictions.
The real features are in the UI. The JS gives each lane a custom type label so you can see at a glance what's supposed to be on it, and you can add or remove channels with one click instead of dealing with a fixed 20-port blob. It's an ergonomics node: think of it as a reroute that moves many wires at once.
One honest note on the family resemblance: this is not a context bus. A context bus (rgthree's Context, or the pipe pattern) bundles everything into one object that travels down one wire, and nodes unpack what they need from it. Dynamic Bus keeps every value on its own explicit lane - which means you never get the "stale context" bug where you silently run on an old model because the bundle you unpacked was assembled too early. The tradeoff is you still have 20 lanes of wiring to look at. For a genuinely huge workflow where even 20 lanes is too many, you'd reach for a context node instead; for most real graphs, this is the safer of the two.
Install
Same pack, same routine: ComfyUI Manager → XB_ToolBox, or:
cd ComfyUI/custom_nodes && git clone https://github.com/wjluoxiao/XB_ToolBox.git
restart ComfyUI, done. No dependencies, no model files - this is the "plug and play" corner of the pack where the README's no-dependencies claim is actually true.
Two small gotchas. First, if an out_* has nothing on its in_*, you get None - most downstream nodes handle that, but a few don't, so keep empty lanes disconnected. Second, because the inputs are optional wildcards, ComfyUI sometimes can't tell you at a glance whether you've actually connected the right lane to the right thing - the type labels help, but double-check the first time you build a bus graph.
Inputs (20)
| Name | Type | Default | Description |
|---|---|---|---|
| in_1opt | * | — | |
| in_2opt | * | — | |
| in_3opt | * | — | |
| in_4opt | * | — | |
| in_5opt | * | — | |
| in_6opt | * | — | |
| in_7opt | * | — | |
| in_8opt | * | — | |
| in_9opt | * | — | |
| in_10opt | * | — | |
| in_11opt | * | — | |
| in_12opt | * | — | |
| in_13opt | * | — | |
| in_14opt | * | — | |
| in_15opt | * | — | |
| in_16opt | * | — | |
| in_17opt | * | — | |
| in_18opt | * | — | |
| in_19opt | * | — | |
| in_20opt | * | — |
Outputs (20)
| Name | Type | Description |
|---|---|---|
| out_1 | * | — |
| out_2 | * | — |
| out_3 | * | — |
| out_4 | * | — |
| out_5 | * | — |
| out_6 | * | — |
| out_7 | * | — |
| out_8 | * | — |
| out_9 | * | — |
| out_10 | * | — |
| out_11 | * | — |
| out_12 | * | — |
| out_13 | * | — |
| out_14 | * | — |
| out_15 | * | — |
| out_16 | * | — |
| out_17 | * | — |
| out_18 | * | — |
| out_19 | * | — |
| out_20 | * | — |