Unpack Parameters Pipe
Get the model and every setting back out of a pipe
- params_pipe
- MODEL
- CLIP
- VAE
- steps
- cfg
- sampler_name
- scheduler
- positive_tag
- negative_tag
- params_pipe
A PARAMS_PIPE is a sealed box. ModelParamsPipe stuffs a checkpoint and all its sampling settings into one, and the pack's KSamplerPipe reads it directly - but the moment you want to do something the pack doesn't handle, you need to open the box. That's ParamsPipeUnpack's entire job: take a pipe in, hand you every piece back out as separate outputs.
Feed it a pipe and you get MODEL, CLIP, VAE, steps, cfg, sampler_name, scheduler, positive_tag, negative_tag, plus the original params_pipe passed through untouched. Ten outputs, one input.
When you actually need this
- The pipe's CLIP is right there - grab it for a Text Encode node that isn't this pack's prompt builder.
- You want to drive a stock KSampler with the pipe's settings instead of the pack's own sampler. The unpacked
sampler_nameandschedulercome out in a form the core node's enum accepts, so you can wire them straight in. - You're debugging. Unpacking turns invisible settings into visible wires, and seeing
steps,cfg, andscheduleras named outputs makes it obvious what the pipe is actually carrying. If your sampler is doing something unexpected, check what came out here.
How it works
The unpack node does a little defensive work beyond destructuring. It verifies the pipe is a 4-element tuple and that the 4th element is a dict, and raises a clear ValueError if you've wired in garbage. That's worth knowing: if your graph fails with a message like "Expected PARAMS_PIPE tuple of length 4", it means whatever you connected isn't a real pipe from this pack - not that the node is broken. It fails loudly instead of silently decoding nonsense, which is the behavior you want from a utility like this.
The honest review
It's a boring node, and that's the point. It has no knobs, no opinions, nothing to configure - one input, ten outputs. You use it exactly when the pack's closed loop gets in your way, and you leave it out of the graph when it doesn't. If you're only ever running the ModelParamsPipe → KSamplerPipe happy path, you never touch this. It exists for the 20% of workflows that branch off.
Installing
Same story as the rest of the pack: ComfyUI Manager, search MultiModel, install; or:
cd ComfyUI/custom_nodes
git clone https://github.com/FaberVS/MultiModel
Then restart. No extra dependencies and no model downloads - it only ever processes pipes that this pack's other nodes created.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| params_pipe | PARAMS_PIPE | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| VAE | VAE | — |
| steps | INT | — |
| cfg | FLOAT | — |
| sampler_name | euler,euler_cfg_pp,euler_ancestral,euler_ancestral_cfg_pp,heun,heunpp2,exp_heun_2_x0,exp_heun_2_x0_sde,dpm_2,dpm_2_ancestral,lms,dpm_fast,dpm_adaptive,dpmpp_2s_ancestral,dpmpp_2s_ancestral_cfg_pp,dpmpp_sde,dpmpp_sde_gpu,dpmpp_2m,dpmpp_2m_cfg_pp,dpmpp_2m_sde,dpmpp_2m_sde_gpu,dpmpp_2m_sde_heun,dpmpp_2m_sde_heun_gpu,dpmpp_3m_sde,dpmpp_3m_sde_gpu,ddpm,lcm,ipndm,ipndm_v,deis,res_multistep,res_multistep_cfg_pp,res_multistep_ancestral,res_multistep_ancestral_cfg_pp,gradient_estimation,gradient_estimation_cfg_pp,er_sde,seeds_2,seeds_3,sa_solver,sa_solver_pece,ddim,uni_pc,uni_pc_bh2 | — |
| scheduler | simple,sgm_uniform,karras,exponential,ddim_uniform,beta,normal,linear_quadratic,kl_optimal | — |
| positive_tag | STRING | — |
| negative_tag | STRING | — |
| params_pipe | PARAMS_PIPE | — |