Nodes/ComfyUI-988/Pipe OUT 988
ComfyUI Node

Pipe OUT 988

Unpack the pipe back into real sockets (and chain it onward)

By kajan988·Created 3 months ago·Updated about a month ago· 1
Pipe OUT 988
  • pipe
  • pipe
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY
  • ANY

Everything Pipe IN 988 bundles, Pipe OUT 988 unbundles. This is the receiving end of the pair: feed it a PIPE988, and it hands back up to ten individual signals plus a pass-through pipe for chaining. Where Pipe IN tidies a graph by collapsing wires, this one re-arms them at the destination.

The design choice that matters: all ten signal sockets are always shown, with stable indices 0–9 across saves. No autogrowing here - the slots are a fixed contract, so a workflow saved last month still unpacks the same way this month. That stability is the whole reason you can trust a pipe-based graph across edits.

How it works

It reads the pipe's stored values and types (written by Pipe IN) and returns them in order: signal 0 from input slot 0, signal 1 from slot 1, and so on. Empty slots come back as None rather than an error, so a partially-filled pipe still unpacks gracefully.

Two things make it friendlier than a plain "10 outputs" node:

  • Self-labelling sockets. Each output socket gets labelled with the original signal name and colored by type, traced back through the Pipe IN node - and through any intermediate pass-through nodes, not just a direct Pipe IN/OUT pair. You see STRING, IMAGE, INT on the sockets instead of ten anonymous "ANY" pins.
  • A refresh button (↻) and a context-menu item that force a manual re-sync when the labels get stale - useful after editing the upstream pipe.

Inputs and outputs

  • pipe (required) - the PIPE988 to unpack.
  • Outputs: pipe (the pass-through, so you can chain into the next Pipe IN without losing the bundle - the standard way to carry context through a long graph), then ANY sockets for signals 0 through 9, each typed to what Pipe IN actually stored.

When to reach for it

Right after a Pipe IN, or at the end of a pipe run where you finally consume the values. The chaining pattern - Pipe OUT's pipe output straight into the next Pipe IN's pipe input - is how you build a "context bus" that runs the length of a workflow, which is exactly the legibility trick the KB's plumbing essay describes as the point of the whole layer.

Gotchas

  • Labels not updating: the traceback is a best-effort convenience. If you see stale socket names, hit the ↻ refresh or re-run; if a socket shows the wrong type, check the corresponding Pipe IN slot.
  • Slot index drift: because Pipe IN shows connected + 1 slots, it's easy to think you connected signal 4 but actually connected slot 3. Pipe OUT always shows all ten, so verify against the labels, not the count.
  • Unpacking a pipe that never ran returns None slots - don't wire it expecting data before the upstream Pipe IN has executed.

Install

Part of ComfyUI-988: Manager (search "ComfyUI-988") or:

cd ComfyUI/custom_nodes
git clone https://github.com/kajan988/ComfyUI-988
cd ComfyUI-988
pip install -r requirements.txt

Then restart. The socket-labelling frontend lives in the pack's js/pipe/ extension; if labels don't appear, a hard refresh after install sorts it.

Category🦇988/Utility

Inputs (1)

NameTypeDefaultDescription
pipePIPE988

Outputs (11)

NameTypeDescription
pipePIPE988Pipe pass-through.
ANY*Signal 0 — type detected from Pipe IN input
ANY*Signal 1 — type detected from Pipe IN input
ANY*Signal 2 — type detected from Pipe IN input
ANY*Signal 3 — type detected from Pipe IN input
ANY*Signal 4 — type detected from Pipe IN input
ANY*Signal 5 — type detected from Pipe IN input
ANY*Signal 6 — type detected from Pipe IN input
ANY*Signal 7 — type detected from Pipe IN input
ANY*Signal 8 — type detected from Pipe IN input
ANY*Signal 9 — type detected from Pipe IN input