Loom Conditioning Out

The whole point of bundling conditioning into a loom is so the sampler subgraph can read it back cleanly, and Loom Conditioning Out is that read node. Give it the same label the Loom Conditioning In used, and the sampler gets the conditioning - no prompt wires dragged across the graph.

Why you'd reach for it

Prompt subgraphs only pay off if the sampler subgraph can consume them without drama. Loom Conditioning Out is the clean handoff: the prompt subgraph builds positive and negative conditioning, pushes both into the loom, and each sampler subgraph starts with a pair of Loom Conditioning Out nodes labeled positive and negative. Change the prompt logic in one place and every sampler picks it up.

It's also how a prompt replacer works mid-stream. Pull the conditioning out, re-encode with a modified prompt, push it back in under the same label - the next Loom Conditioning Out downstream reads the new version. That's the stream model doing the thing a global store can't: downstream automatically sees the update.

How it works

Standard loom lookup:

key = f"CONDITIONING_{label}" if label else "CONDITIONING"
if key not in loom:
    return (loom, None, False)
return (loom, loom[key], loom[key] != None)

Reading doesn't remove, so positive and negative can both be read by several samplers, and a replacer can overwrite one while the other still flows.

The outputs that matter

• CONDITIONING: the conditioning under that label, or None if absent.
• exists (BOOLEAN): True when the key exists. A False on the negative read means the prompt subgraph never pushed it - easy to miss when the positive one works.
• LOOM: the loom, passed through unchanged.

Inputs are loom (LOOM, required) and label (string), matching the Loom Conditioning In.

Installing

Part of c4f-wire-loom. ComfyUI Manager → search "c4f-wire-loom" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Codes4Fun/c4f-wire-loom

No extra deps, no downloads.

Where it bites

The usual label mismatch is compounded here because you have two conditioning objects (positive and negative) floating in the same loom - label both, or one silently overwrites the other. And remember conditioning is built from a CLIP: if the model subgraph that pushed CLIP into the loom runs after the prompt subgraph that reads it, the encode gets None and your prompt silently does nothing. Order the stream so load → prompt → sampler, and check exists when a prompt stops having an effect. Nodes 2.0's arrow-drag collapse quirk applies pack-wide, with the workaround shipped.