Index Output Switch
Routing the other direction
- input
- value1
- value2
- value3
- value4
- value5
- value6
- value7
- value8
- value9
- value10
- value11
- value12
- value13
- value14
- value15
- value16
Every switch so far takes many inputs and picks one. Nifty Index Output Switch flips it: one input in, up to 16 outputs, and only the output at the chosen index is active - the other fifteen are blocked, meaning anything downstream of them doesn't execute.
Think of it as a single-value dispatcher. You've got one image, one latent, or one string, and depending on an index you want it to land in one of several different places: a save node, a preview, an upscale path, an encode branch. Rather than duplicate the value across every branch with an Input Switch per destination, you route it through this and only the destination you pick actually runs.
The inputs that matter
- input - the value to route (any type).
- index - which output gets it, 1–16. The rest are blocked.
Outputs: value1 through value16. Only the one matching index is live; the others never fire.
Why blocking matters
The "blocked" behavior is the point, and it's the same lazy philosophy as the rest of the pack. A Save Image hanging off an unselected output won't write a file; an expensive upscaler downstream won't run. If you want the value delivered to every destination regardless, this isn't the node - but for "send this to exactly one place, decided at runtime," it's exactly right.
Pair it with the input-side routers and you can build a little crossbar switch: a shared value routed in on one side, dispatched out on the other. Drive index from a slider, a Nifty Math expression, or the index output of a Index Combo Switch upstream - that's a readable, named-control front-end feeding a numeric router, and it works cleanly.
The one thing to remember is that unlike the input routers there's no lazy/eager pairing here - the outputs are always either live or blocked, so there's no variant to pick. If you ever need the unselected outputs to still do work, that's a job for parallel wiring, not this node.
Install
Nifty Nodes, standard: ComfyUI Manager → search "Nifty Nodes", or
cd ComfyUI/custom_nodes
git clone https://github.com/Stibo/comfyui-nifty-nodes
Restart ComfyUI, keep ComfyUI current (v3 API). No extra dependencies. It's the less glamorous cousin of the input routers, but the first time you need to send one result to whichever of several destinations is selected, it's the node that exists for exactly that.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| index | INT | 11–16 | Which output to route the input to (1–16). All other outputs are blocked. |
| inputopt | COMFY_MATCHTYPE_V3 | Value to route to one of the indexed outputs. |
Outputs (16)
| Name | Type | Description |
|---|---|---|
| value1 | COMFY_MATCHTYPE_V3 | — |
| value2 | COMFY_MATCHTYPE_V3 | — |
| value3 | COMFY_MATCHTYPE_V3 | — |
| value4 | COMFY_MATCHTYPE_V3 | — |
| value5 | COMFY_MATCHTYPE_V3 | — |
| value6 | COMFY_MATCHTYPE_V3 | — |
| value7 | COMFY_MATCHTYPE_V3 | — |
| value8 | COMFY_MATCHTYPE_V3 | — |
| value9 | COMFY_MATCHTYPE_V3 | — |
| value10 | COMFY_MATCHTYPE_V3 | — |
| value11 | COMFY_MATCHTYPE_V3 | — |
| value12 | COMFY_MATCHTYPE_V3 | — |
| value13 | COMFY_MATCHTYPE_V3 | — |
| value14 | COMFY_MATCHTYPE_V3 | — |
| value15 | COMFY_MATCHTYPE_V3 | — |
| value16 | COMFY_MATCHTYPE_V3 | — |