ComfyUI Node

LC Pipe Out

Unpack a whole workflow's worth of sockets from one wire

By lonecatone23·Created 2 months ago·Updated 3 days ago· 18
LC Pipe Out
  • pipe
  • pipe
  • Model 1
  • Clip 1
  • VAE 1
  • Model 2
  • Clip 2
  • VAE 2
  • Image
  • Mask
  • Width
  • Height
  • Latent
  • Batch
  • Positive prompt
  • Positive conditioning
  • Negative prompt
  • Negative conditioning
  • Seed
  • total_steps
  • cfg_1
  • denoise
  • step_swap
  • cfg_2
  • sampler_name
  • scheduler
  • detailer_steps

Pipes are great until you need an actual value. You've threaded an LC_PIPE across the whole graph, and now the sampler needs a model, a conditioning, a seed, a denoise - real sockets, not a bundle. LC Pipe Out is the other end of the pattern: it takes one LC_PIPE in and fans it out to every individual socket it can carry, top to bottom, in the exact order the pack's pipe builders define. It's the decoder for the bus.

How it works

One required input, pipe (from LC Pipe Edit, a sampler-configure pipe, or a KJ Get). The outputs are the full slot list, in order: pipe (passed through, so you can chain another Get/Set or Pipe Out after it), then Model 1, Clip 1, VAE 1, Model 2, Clip 2, VAE 2, Image, Mask, Width, Height, Latent, Batch, Positive prompt, Positive conditioning, Negative prompt, Negative conditioning, Seed, total_steps, cfg_1, denoise, step_swap, cfg_2, sampler_name, scheduler, and detailer_steps. The pipe passthrough is the detail that makes chaining possible - you can unpack, grab one value, and keep the bundle flowing.

Any slot that wasn't packed comes out empty (None) rather than erroring, so a pipe with only models and a prompt still unpacks cleanly; you just wire what you need.

Why the order matters

The outputs are fixed top-to-bottom to match the builders - LC Pipe Edit and the sampler-configure pipes all pack in the same slot order, and LC Pipe Out unpacks in that same order. That consistency is the whole contract. It also means the socket labels match what the pipe's tooltips promised, so a pipe packed as "positive conditioning" at slot 14 unpacks at the same spot. No surprises, as long as you use the pack's pipe family end to end.

What you'll actually use it for

  • Feeding the sampler - unpack at the end of the pipe chain and wire Model 1, positive/negative, seed, and sampler settings straight into a KSampler or the pack's LC Sampler Configure.
  • Interop with KJ Get/Set - the pack positions these pipes as Get/Set friendly, so you can grab one slot (say, seed) with a KJ Get node mid-pipeline and edit it with a KJ Set without unpacking everything.
  • Editing one value - unpack → change → re-pack through LC Pipe Edit is the explicit edit path if you prefer sockets to pipe surgery.

Install

Part of ComfyUI LC123 Nodes (MIT, 89 nodes). ComfyUI Manager → search "ComfyUI LC123 Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC123_nodes

Restart. No extra dependencies. On hosted platforms like RunningHub, request the pack and they install it for you.

The honest caveat

The type system treats LC_PIPE as a single opaque type, so nothing checks that the pipe you're unpacking actually contains a model - you'll find out at the sampler. And like every pipe family, this one doesn't interoperate with rgthree Context or another suite's pipe; commit to LC_PIPE and use it consistently, or you'll be unpacking a bundle that isn't there.

CategoryLC123/pipe

Inputs (1)

NameTypeDefaultDescription
pipeLC_PIPELC_PIPE from Pipe In, Pipe Edit, or KJ Get.

Outputs (26)

NameTypeDescription
pipeLC_PIPE
Model 1MODEL
Clip 1CLIP
VAE 1VAE
Model 2MODEL
Clip 2CLIP
VAE 2VAE
ImageIMAGE
MaskMASK
WidthINT
HeightINT
LatentLATENT
BatchINT
Positive promptSTRING
Positive conditioningCONDITIONING
Negative promptSTRING
Negative conditioningCONDITIONING
SeedINT
total_stepsINT
cfg_1FLOAT
denoiseFLOAT
step_swapINT
cfg_2FLOAT
sampler_nameeuler,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
schedulersimple,sgm_uniform,karras,exponential,ddim_uniform,beta,normal,linear_quadratic,kl_optimal
detailer_stepsINT