PVL Switch x10
The ten-way switch, again — they ship both, and that's fine
- input_default
- input_1
- input_2
- input_3
- input_4
- input_5
- input_6
- input_7
- input_8
- input_9
- input_10
- output
Let's be honest about this one up front: PVL Switch x10 does exactly what PVL Switch Huge does - same ten cases, same ten wildcard inputs, same lazy evaluation, same switch_condition equality routing. The pack ships both, and they're functionally twins. This is the article for the twin.
The one thing worth knowing about either node: it's a ten-way router that only evaluates the branch that matches. You feed it a switch_condition string, ten case_ labels, and up to ten inputs; it returns the input whose case equals the condition, or input_default if nothing matches. Unchosen branches don't run, which is what makes a ten-slot switch viable instead of a ten-times-costly mistake.
Both live in pvlprk/comfyui-pvl-api-nodes ("ComfyUI Assistant Node"). If you've read the Switch Huge article, you've basically read this one - so let's focus on the differences and the pick.
How it works
switch_condition- the value to test.case_1…case_10- equality targets.input_default- required fallback for no-match.input_1…input_10- optional wildcard inputs.- Output
output- the matched input, orinput_default.
Routing is exact string equality, laziness comes from check_lazy_status (only the matching input's upstream is scheduled), and the output type follows whichever input wins. Compared to Switch Huge, the implementation is a bit cleaner - the case inputs are generated in a loop rather than hand-written - but you will not feel that difference from the node surface.
Which one should you use?
Honestly: pick one and stay consistent. If you found Switch Huge first and it works, there is no compelling reason to swap. The x10 variant is the same behavior with a tidier code path, so if you're choosing cold, x10 is the marginally better maintained choice. What you shouldn't do is mix them in one workflow and then wonder why two "identical" nodes look different on the canvas - they're duplicates, not complementary. If you only need two or three cases, both are overkill; the pack's two-way PVL Switch is the right tool for a boolean fork.
Installing
cd ComfyUI/custom_nodes
git clone https://github.com/pvlprk/comfyui-pvl-api-nodes
restart, or install via ComfyUI Manager (search "ComfyUI Assistant Node"). No models, no dependencies.
The gotchas (same as its twin)
- Exact string matching.
"High"≠"high"; a mismatch silently drops you toinput_default. input_defaultmust be wired or no-match cases emitNone.- Keep case types consistent - the output adopts the matched branch's type.
- Laziness skips unchosen branches only if nothing else in the graph needs them.
Inputs (22)
| Name | Type | Default | Description |
|---|---|---|---|
| switch_condition | STRING | — | |
| case_1 | STRING | — | |
| case_2 | STRING | — | |
| case_3 | STRING | — | |
| case_4 | STRING | — | |
| case_5 | STRING | — | |
| case_6 | STRING | — | |
| case_7 | STRING | — | |
| case_8 | STRING | — | |
| case_9 | STRING | — | |
| case_10 | STRING | — | |
| input_default | * | — | |
| input_1opt | * | — | |
| input_2opt | * | — | |
| input_3opt | * | — | |
| input_4opt | * | — | |
| input_5opt | * | — | |
| input_6opt | * | — | |
| input_7opt | * | — | |
| input_8opt | * | — | |
| input_9opt | * | — | |
| input_10opt | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output | * | — |