🪄 My Sampler+scheduler (CONFIG)

This is the boring half of the pair, and that's the compliment it deserves. Where the selector node ("🪄 My Sampler+scheduler") is the thing you click during a session, the CONFIG node is the thing you set up once and then forget. It's a small, named table of sampler/scheduler/steps combos, and its entire job is to pack those combos into the single presets output that the selector consumes. That's it - no inference, no model, no magic.

What it actually is

The README is upfront about the design: configure several sampler/scheduler/steps combinations once, then pick one quickly in a separate node. This node is the "configure" half. You get up to 8 rows, each with an editable label plus a sampler, a scheduler, and a step count. The frontend hides the raw backend widgets and gives you two buttons - + Add Combo and - Remove Combo - that add or drop rows for you. Add a row, fill in the dropdowns, name it something you'll recognize, and move on.

If this feels like a dumb data container, that's the point. Splitting config from selection means one person maintains the preset list and everyone else just clicks toggles on the selector. In a single-user setup, the config node is arguably optional busywork unless you genuinely juggle a few combos - draft / keeper / distilled-LoRA pass, say. But when you do, having them named and in one place beats re-typing them.

How it works

Under the hood it's refreshingly simple. The backend builds a plain Python dict - {"pair_count": N, "pairs": [{label, sampler, scheduler, steps}, ...]} - and hands it out on a custom connection type called SAMPLER_SCHED_PRESETS. That type name is nominal: the data is just a dict flowing along the wire, so it plugs into the matching selector node's presets input and nowhere else.

The sampler and scheduler dropdowns are read straight from ComfyUI itself (comfy.samplers.KSampler.SAMPLERS and .SCHEDULERS), so this node always matches what your KSampler accepts. On a current build that's 44 samplers and 9 schedulers - everything from euler and dpmpp_2m to the newer res_multistep, seeds_2, and gradient_estimation entries, plus simple, karras, sgm_uniform, beta, and friends. Because it draws on the live list, upgrading ComfyUI silently adds whatever new samplers show up.

The inputs that matter

Three per preset, plus the counter:

• sampler_N - dropdown from ComfyUI's full sampler list.
• scheduler_N - one of the 9 stock schedulers. This is the half of the choice that trips people up: Karras is the SD 1.5/SDXL default, but it's a known failure on flow-matching models like Flux, which want simple or beta. The node won't stop you; it just holds whatever you put in.
• steps_N - 1–200, default 10.
• pair_count - how many rows are active (1–8), or just use the +/- buttons.

The one output is presets, and it wires straight into the selector's presets input.

Install

Same as its sibling, and there's nothing heavy about it:

cd ComfyUI/custom_nodes
git clone https://github.com/Gattopeloso/My_sample-scheduler_GATTO.git

or search "My Sampler" in ComfyUI Manager. Restart ComfyUI after installing so the frontend extension registers - that's what renders the Add/Remove buttons and hides the raw per-row widgets. No requirements.txt, no model downloads, nothing to pip.

Gotchas

Hard cap of 8 presets, steps capped at 200 - both enforced by the backend, so the UI won't let you exceed them. Presets are workflow data, not global settings, so they only persist if you save the workflow. And don't be surprised when changes here show up live on the selector: it re-reads this node's values every ~400ms, so editing a sampler in the config updates the selector without a re-wire. In the unlikely event the frontend extension doesn't load, the backend still works - you'd just see the raw, un-pretty widgets instead of the buttons.