Loom Sigmas In

SIGMAS is the wire that defines the actual schedule of a sampling pass - the per-step noise levels - and it's another one you end up duplicating per branch. Loom Sigmas In bundles a SIGMAS value into a LOOM stream so one scheduler decision drives every sampler in the graph.

Why you'd reach for it

If you're using SamplerCustomAdvanced-style nodes, the SIGMAS wire is non-negotiable: a BasicScheduler (or similar) produces it and every sampler consumes it. In a graph with a main pass and an upscale/refine pass, that's two or three SIGMAS connections that must all agree. Bundle the schedule into the loom once and every stage pulls the same one - change steps or the scheduler and the whole pipeline follows.

It also makes the difference between "the branch uses the same schedule" and "the branch uses its own" explicit. Want a shared schedule for the main and refinement passes? One unlabeled SIGMAS in the loom. Want a separate short schedule for the upscale pass? Label it upscale and give the upscale stage its own Loom Sigmas Out.

How it works

The standard typed loom insert:

key = f"SIGMAS_{label}" if label else "SIGMAS"
new_loom[key] = sigmas
return (new_loom,)

Empty label → SIGMAS; a label like upscale → SIGMAS_upscale. The matching Loom Sigmas Out uses the same label. Drag a sigmas slot onto a collapsed Loom Split hub and the frontend auto-creates the node with the label set.

The inputs that matter

• sigmas (SIGMAS): from BasicScheduler, ExponentialScheduler, or any other scheduler node.
• label (string): the key. Empty for the shared schedule, named for stage-specific ones.
• loom (LOOM, optional): the bundle to extend.

Output is a single LOOM, feeding Loom Split or Loom Join, with sigmas pulled back out via Loom Sigmas Out at each sampler.

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

Sigmas are shape-sensitive: a schedule built for N steps won't fit a sampler configured for M, and the loom can't know. Keep the schedule and the sampler's step count in sync, or you'll get a runtime error that looks like the loom broke but is really a schedule mismatch. And the usual stream rule - sigmas only reach stages downstream of the Loom In. The Nodes 2.0 arrow-drag collapse quirk applies pack-wide, with the built-in workaround.