Sampler Parameter Unpacker

ComfyUI's KSampler expects a sampler and a scheduler as separate dropdown widgets. The Flux Continuum pack found that inconvenient, so it invented a SAMPLER_PARAMS type: a single object that bundles a sampler and a scheduler together so they can travel down one wire and get version-controlled in one place. This node is the "and now un-bundle it" half of that trick. It takes one sampler_params input and hands you back the four pieces separately.

What comes out

Four outputs, and they map to the packer's inputs in a friendly order:

• sampler - the actual sampler object, the full list of ComfyUI samplers (euler, euler_ancestral, dpmpp_2m, dpmpp_sde, ddim, uni_pc, and friends). This is what a KSampler or CustomSampler wants to receive.
• sampler_name - the same sampler as a plain STRING ("euler", "dpmpp_2m", ...), for nodes that want the name instead of the object.
• scheduler - the scheduler object (any type, so it can plug into a Scheduler node).
• scheduler_name - the scheduler as a string.

Mechanically it's embarrassingly simple: the packer stores everything as a tuple (sampler, str(sampler), scheduler, str(scheduler)), and the unpacker just pulls the tuple apart. Nothing is recomputed, nothing is inferred. In the shipped workflow you'll see the outputs feeding the get/set system's Set_sampler, Set_sampler_name, Set_scheduler, and Set_scheduler_name slots, which is how the Continuum interface lets you change sampler settings in one place and have them apply across modules.

Why you'd use it

Two reasons. First, if you're using the packer side of this pair - consolidating sampler settings into a SAMPLER_PARAMS wire for a tidy graph or a tabbed "version control" of your sampling recipes - you need the unpacker at the end to hand the real values back to whatever node actually samples. Second, it's a great way to see what you're working with: a sampler bundled as an object is opaque, but sampler_name as a string you can preview, log, or branch on.

One honest caveat: if your workflow is a plain KSampler with the dropdowns sitting right there, this is extra plumbing for no benefit. It earns its place in Continuum's one-interface design; outside it, don't add it for fun.

A quick sampler reality check

While you're unpacking, remember the values you're shoving into that slot matter more than the node. Flux is a rectified-flow model: it wants a converging sampler (Euler is the community default), normal or beta scheduling, and never a Karras schedule - the aggressive noise redistribution that served SDXL actively hurts flow-matching models. The sampler list here is the same list KSampler uses, so the usual "when in doubt, euler + normal/beta for Flux" advice applies.

Install

Ships with the pack, no separate step:

cd ComfyUI/custom_nodes
git clone https://github.com/robertvoy/ComfyUI-Flux-Continuum

Restart, or use ComfyUI Manager → search "Flux Continuum". Dependency-free like the rest of the pack.

Troubleshooting

• Red "SAMPLER_PARAMS" socket - you're trying to wire a raw sampler string into the input; it needs the output of a SamplerParameterPacker (or anything else that emits the packed type).
• Unpacker outputs show nothing - it's an output-optional pass; values only appear once the packer upstream runs. If the upstream node is bypassed, everything downstream empties.
• Same sampler, worse results - that's your sampler/scheduler choice, not the node. It faithfully hands through whatever you packed.

For a pack full of "boring on purpose" nodes, this one has a genuinely useful job: it turns an opaque bundle into values you can read and route.