FunPack Sampler

If you've read the source of a big custom pack's sampler you know the pattern: it starts as a KSampler with a couple of extras, and three years later it's thousands of lines with seventy optional inputs, half of which are silently inert depending on which model you loaded. FunPack's rewrite is a reaction to exactly that - the file's own docstring describes the old Chain Sampler as "8183 lines, roughly seventy optional inputs." So this one picks an algorithm, picks a schedule, and runs.

How it works

sampler_name and scheduler are read from ComfyUI's own registries at node-definition time: comfy.samplers.SAMPLER_NAMES and SCHEDULER_NAMES. Nothing is hardcoded, so a sampler ComfyUI gains tomorrow shows up in the dropdown without an edit here. Seeding goes through ComfyUI's random-noise source, and the node marks the start of a generation each time it executes - which is what all the reporting and taste-learning downstream hangs off.

It also hosts sampler-side modifiers, but through exactly one call site: the step travels in a context object, so the signature can't grow. It declares what it can host and the core only hands it things that fit. It genuinely never learns the name of a modifier - that's the anti-hub design in one sentence.

The inputs you set

model, positive, negative, latent and seed are the usual. Then:

steps - 20 by default. cfg - 7 by default, with a tooltip that says the quiet part: 1.0 turns guidance off, which some models want. Believe it. Guidance-distilled and flow-matching models run a single forward pass and bake guidance into the weights; CFG 7 on one of those isn't more prompt adherence, it's the same correction applied twice at double the cost, and it burns the output. H3-class video models are not SD 1.5, and the old reflexes are actively wrong here.

denoise - below 1 starts partway through the schedule. That's your img2img/video-to-video strength knob.

Optional: settings, the FUNPACK_SETTINGS payload from FunPackModifierSettings, and sigmas. The sigmas input is the one that catches people: when it's wired, steps, scheduler and denoise are not used. A schedule runs exactly as written. And for a second pass, the tooltip gives you the two numbers worth memorising - a first value of 0.4 polishes, 0.8 reworks the shot.

Two outputs: latent (into FunPack Decode, or any decoder) and status.

The scheduler question

The advice you inherited - DPM++ 2M Karras, or whatever won the sampler wars on SDXL - does not transfer. On a straight flow-matching trajectory, a schedule that concentrates denoising effort in the middle steps is a distortion rather than a correction, and the community evidence on newer architectures is consistent about it: aggressive redistributions of denoising effort fall apart, and conservative low-step samplers on plain schedules win. Practically: start with something boring, don't reach for Karras out of habit, and if the model shipped a recommendation, use it.

If you want to tune properly, the honest way is sigmas from a schedule node plus a fixed seed and a side-by-side - not flipping the scheduler dropdown and guessing at what changed.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/olivv-cs/ComfyUI-FunPack
pip install -r ComfyUI-FunPack/requirements.txt

Then restart. ComfyUI Manager works (search ComfyUI-FunPack) but installs the Registry copy, which can lag - check Settings ▸ About FunPack. One dependency worth flagging from requirements.txt: comfy-kitchen>=0.2.32. That's the compiled sol_attn kernel one of the attention modes needs. It's compiled against torch, so the pack reports a low version rather than upgrading it behind your back. Read what pip proposes before accepting an upgrade of anything ComfyUI compiles against.

Troubleshooting

"I changed steps and nothing happened." sigmas is wired. It wins, by design.

Video looks baked or the colours are scorched. CFG is probably too high for a distilled model. Try 1.0 and see what the model actually does unattended.

Modifiers don't show up in the status. They report from FunPackLoadModifiers on the model side; this node only hosts the ones that need the step itself.

Everything is slow. Some modules switch off the model compiler for the run - the changelog flags this as a real speed cost, so trim the mod stack before blaming the sampler.