Nodes/ComfyUI-FunPack/FunPack Load Modifiers
ComfyUI Node

FunPack Load Modifiers

Stack the taste mods on the model, not inside the sampler

By digital-garbage·Created about a year ago·Updated about 14 hours ago· 20
FunPack Load Modifiers
  • model
  • settings
  • model
  • status

Every ComfyUI pack eventually grows a Frankenstein sampler. FunPack 4's Chain Sampler ended up around 8,000 lines with roughly seventy optional inputs, and the source of the 5.0 rewrite says so out loud in a comment - every technique that needed the sampling loop was bolted onto it until it accumulated all of them. FunPack 5's answer is this node: the techniques become independent modules, and they get installed on the model, not baked into a sampler.

What it changes under the hood

You wire a model in. The node clones it, strips any FunPack install an earlier clone might have carried forward, then asks the module registry who can contribute a modifier. Each candidate is checked against what the model is - traits read off the model object, not a hardcoded list of names. ALG, for instance, only requires a latent with a time axis; it isn't "for H3" or "for LTX", and any model with a time axis gets it. Compatible ones are then filtered by your project's settings, ordered by their declared before/after relations (conflicting or cyclic combinations get rejected and reported rather than silently applied in whatever order), and installed on the patched model.

Because it's a model patch rather than a loop rewrite, any sampler works - FunPack's own, ComfyUI's stock KSampler, anything that takes a MODEL. That's the whole trick, and it's why this design doesn't decay into a hub again.

Inputs and outputs

model is required. settings is optional and takes the FUNPACK_SETTINGS payload that FunPackModifierSettings produces - that's where each modifier's on/off and its own sliders come from. Leave it unwired and every modifier stays at its default, which for essentially all of them means off; the node is a pass-through until you tell it otherwise.

Outputs are model - into your sampler - and status, which is where this node earns its keep. It reports what was installed, what was skipped and why: not compatible with this model, turned off for this project, quarantined after a failure on a previous run. A modifier that has nothing to do on your architecture says so instead of half-running and producing a subtly different image you'd then try to debug by eye.

One deliberate quirk: this node does not count as the start of a run - the sampler does. ComfyUI caches nodes whose inputs haven't changed, and between most generations only the seed differs, so a node that claimed the run would spend the rest of the session reporting under the first one. Practical upshot: don't be surprised if changing nothing but the seed doesn't change this node's report.

What's actually in the pile

The 5.0 changelog splits the feature list into proven and experimental, which is rare enough to be worth quoting. Proven includes modifiers, sampler, second pass, DynaShift, ALG (anchor de-staticking), randomizer, first-step seed search and the taste modules. Experimental includes block influence, block repeat, phrase probe, temporal style, massive-activation steering and video-to-audio coupling.

The one to know first is ALG. Image-to-video models get shown a sharp first frame and can satisfy the objective by barely moving - the clip matches the reference and does nothing. ALG low-passes that anchor for the early high-noise steps, then swaps the sharp one back so later steps resolve detail. Its settings are strength and until_sigma ("sharp again at noise"), and the honest framing is that you're trading motion against fidelity to the first frame.

Install

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

Restart, then check Settings ▸ About FunPack - Manager installs the Registry copy, which can lag the repo. Modules switch on and off individually in Settings ▸ Modules; a module that fails mid-run is dropped, the log says why, and the run continues.

Troubleshooting

"settings must be an object keyed by module id." You wired a raw string or the wrong thing in. Wire FunPackModifierSettings into it.

Nothing changes. Check the status output first - it probably says every candidate was off or incompatible. A modifier that needs a time axis will sit out on an SDXL graph, correctly.

The run got slower after you enabled things. Some modules switch the model compiler off for the run; the changelog flags this as a real cost. Fewer mods, faster sampling.

CategoryFunPack/Sampling

Inputs (2)

NameTypeDefaultDescription
modelMODEL—
settingsoptFUNPACK_SETTINGS—

Outputs (2)

NameTypeDescription
modelMODEL—
statusSTRING—