Selector Out (Polarity)...
SelOutPolar Routes Your Conditioning by Model
- conditioning
- OUT_1
- OUT_2
- OUT_3
- OUT_4
- OUT_5
- OUT_6
- OUT_7
- OUT_8
SelOutPolar ("Selector Out (Polarity)") is a tiny switch from the exdysa/comfyui-selector pack, and once you see what it does it's almost boringly simple: one conditioning input in, eight conditioning outputs out, and only one of those eight carries the signal at any given time. Which one? Whatever lane matches the model_type integer you feed it. That's the entire node. The whole job is routing.
Why would you care? The pack's pitch is "one workflow that adapts to whatever checkpoint you load." If you maintain separate graphs for SD1.5 and Flux because their samplers, CFG and resolutions don't agree, you know the pain. The pack's answer: detect the model family once, broadcast it as a number, and let nodes like SelOutPolar push your data down the branch that matches.
How it works
In ComfyUI, "conditioning" is the bundle of encoded prompt data a KSampler consumes - usually born in a CLIPTextEncode node. SelOutPolar takes one such bundle and, based on model_type, writes it into exactly one slot of its output tuple, leaving the other seven as None:
result = [None] * 8
if 1 <= model_type <= 8:
result[model_type - 1] = conditioning
That's the whole mechanism; there's no hidden logic. The "Polarity" in the name is the direction. This is the fan-out half of a pair: its mirror, SelInPolar, takes eight conditionings and picks one - and it's lazy, so ComfyUI only computes the lane you actually need. SelOutPolar fans one into eight.
The model_type numbers are the pack's shared vocabulary, and they're what RecourseCheckpoint emits when it inspects a loaded model:
- 1 = SD1
- 2 = SDXL (incl. Refiner / P2P)
- 3 = Flux
- 4 = AuraFlow
- 5 = HunyuanDiT
- 6 = SD3
- 7 = Stable Cascade C
- 8 = Stable Cascade B
Heads-up: 7 and 8 are declared in the code, but RecourseCheckpoint's detector maps no model class to them and falls back to 7 for unknown models. Treat the last two as aspirational.
The inputs that matter
Only two, and you'll really touch one:
- model_type (INT, default 1, min 1, max 8) - the lane selector. The default is 1, so wire this node without an input here and you get the SD1 branch, always.
- conditioning (CONDITIONING, optional) - the single prompt bundle to route.
Outputs are OUT_1 through OUT_8, all CONDITIONING. Wire the branch you care about; the seven dead lanes are None.
Installing it
No models, no dependencies, pure Python - the README is explicit that it never touches the network or your files. Install through ComfyUI Manager (search "comfyui-selector"), or:
cd ComfyUI/custom_nodes
git clone https://github.com/exdysa/comfyui-selector
Restart ComfyUI. That's it. The README also suggests just dropping the .py files into custom_nodes, which works, but the clone is cleaner.
Where people get burned
- Dead lanes are
None, not silent. Every non-matching output is literallyNone. A node that expects real conditioning on a dead lane won't skip gracefully - it can error. The pack's answer is its "Recourse" failsafe nodes, which pick the first active input, so SelOutPolar is really meant to feed into that system rather than straight into a KSampler. - It's only adaptive if model_type is. Hardcode 3 and it's a manual switch - fine for testing, but you've lost the point. Feed
model_typefrom RecourseCheckpoint's MODEL_TYPE output. - Nothing shows you which lane is live. There's no highlight on the active output; you'll be matching numbers by eye.
Honest take: this pack has basically zero community footprint - one Reddit mention of "exdysa," and it's about an unrelated EVA-CLIP upload. The code is clean and it does work, but it's a system you adopt wholesale, and conditioning routing with all the None-handling that comes with it is more machinery than most workflows need. If you're juggling SD1.5, SDXL and Flux in one graph and you're tired of maintaining three copies of everything, it earns its place. For a single-model workflow, skip it.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model_type | INT | 11–8 | — |
| conditioningopt | CONDITIONING | — |
Outputs (8)
| Name | Type | Description |
|---|---|---|
| OUT_1 | CONDITIONING | — |
| OUT_2 | CONDITIONING | — |
| OUT_3 | CONDITIONING | — |
| OUT_4 | CONDITIONING | — |
| OUT_5 | CONDITIONING | — |
| OUT_6 | CONDITIONING | — |
| OUT_7 | CONDITIONING | — |
| OUT_8 | CONDITIONING | — |