BlehSetSigmas

If you've built a custom sampling graph with SamplerCustomAdvanced, you already know sigmas are just a list of noise levels a scheduler node (Karras, Normal, exponential, whatever) hands to your sampler, one per step. BlehSetSigmas is a surgical tool for editing that list directly - replacing entries, inserting new ones, or running arithmetic against a second sigma list, all before it reaches the sampler.

The pack is upfront about where this sits on the maturity scale: "Experimental, not well tested." This isn't a node you reach for casually - it's for people who already have a specific reason to want a non-standard sigma schedule and know roughly what they're trying to build (something like a Restart-sampling-style reinsertion of extra sigmas, or hand-tuning specific steps a scheduler node doesn't give you direct control over).

What it actually does

You pick a start_index into the sigma list (zero-based; negative values count from the end, so -1 is the last entry), a mode for how new values interact with what's already there, and supply either a second SIGMAS input or a typed-out comma-separated list. The node then applies your operation starting at that index.

• mode - replace, insert, multiply, add, subtract, or divide. replace/insert just swap in or splice new values; the arithmetic modes combine your new values against whatever's already at that position.
• order - AB or BA, and it only matters for the arithmetic modes. Since subtraction and division aren't commutative, this picks which operand comes first - flip it if a subtract/divide is landing backwards from what you expected.

The README's worked example for replace mode is the clearest way to see it: start with sigmas 4, 3, 2, 1, set start_index=2 and replace with 0.3, 0.2, 0.1 - the result is 4, 3, 0.3, 0.2, 0.1. Non-insert modes pad the input sigmas with zeros if your replacement runs past the end of the original list.

Inputs and outputs

• start_index - integer, default 0. Negative values index from the end.
• mode - one of replace / insert / multiply / add / subtract / divide, default replace.
• order - AB or BA, default AB. Only affects the four arithmetic modes.
• commasep_sigmas_b - a string field for typing sigma values directly (4,3,2,1-style). Exclusive with sigmas_b - populate one or the other, not both.
• sigmas_a (optional) - the base SIGMAS list to operate on. If you leave it unconnected but commasep_sigmas_b isn't empty, the node generates a zero-filled list of the right size to operate against instead.
• sigmas_b (optional) - a second SIGMAS input, as an alternative to typing values manually into commasep_sigmas_b.
• Output: a single SIGMAS list, ready to feed into a sampler node that accepts sigmas directly (SamplerCustomAdvanced and similar).

Installing it

• ComfyUI Manager - search "ComfyUI-bleh", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/blepping/ComfyUI-bleh, restart ComfyUI.

No extra dependencies for this node.

Common issues

Sampler errors or produces garbage after editing sigmas. Sigma schedules generally need to be monotonically decreasing for most samplers to behave - if your edit introduces a sigma that jumps back up partway through, don't be surprised if the sampler chokes on it. This node will happily let you build a schedule that doesn't make mathematical sense; it doesn't validate the result for you.

You set both sigmas_b and commasep_sigmas_b and got unexpected behavior. They're documented as mutually exclusive - pick one path (a real SIGMAS input, or a typed comma-separated list) and leave the other empty.

Arithmetic mode gives you the inverse of what you wanted. That's almost always the order setting - subtract and divide are order-sensitive, and AB vs BA flips which value is treated as the left-hand side.

It errored after updating the pack. The README calls this node experimental and not well tested, which in practice means its behavior is more likely to shift between versions than the pack's more mature nodes. If a working rule set breaks after an update, check the changelog before assuming your sigma math is wrong.