Sigmas Append
Pad extra values onto the end of a schedule
- sigmas
- additional_sigmas
- SIGMAS
Compared to most of RES4LYF's sigma toolbox, Sigmas Append is refreshingly simple: it takes an existing schedule and tacks extra values onto the end of it. No trigonometry, no chaos theory, just padding.
What it's for
Two real reasons to reach for this. First: a lot of the pack's other sigma-math nodes (the arc-trig reshaping tools, the chaos and attractor generators, Sigmas2 Add/Mult) don't guarantee their output cleanly terminates near zero the way a normal schedule should - if you've built a custom curve and it stops short, appending a short run of low values forces a clean finish instead of leaving the sampler to guess. Second: it can glue a whole second schedule onto the first via its optional input, which is a rougher version of what the pack's dedicated Sigmas Concat node does more directly - useful if you also want a fixed-value pad between the two.
How it works
Appends count copies of value to the end of sigmas. If additional_sigmas is connected, that full list gets appended after the padding. Straightforward concatenation - nothing is sorted, smoothed, or validated for continuity.
The inputs and outputs that matter
sigmas(SIGMAS, required) - the schedule to extend.value(default0, range −10000 to 10000) - the value to repeat.count(default1, up to100) - how many copies ofvalueto add.additional_sigmas(SIGMAS, optional) - a second full schedule to append after the padding.
Output is a single SIGMAS list, longer than the input by count (plus the length of additional_sigmas if you used it).
How to install it
- ComfyUI Manager - search "RES4LYF", install, restart.
- Manual - activate your venv,
cd ComfyUI/custom_nodes && git clone https://github.com/ClownsharkBatwing/RES4LYF,cd RES4LYF,pip install -r requirements.txt(portable builds: point at the embeddedpip.exe). Restart.
Common issues & troubleshooting
Direction matters. Nothing enforces that the schedule keeps decreasing after the padding - if your last real sigma is, say, 0.05 and you append value = 0 repeatedly, that's fine and expected. But if you set value above what the schedule was already at, you've told the sampler noise level goes back up partway through, which most samplers won't handle gracefully unless that's genuinely what you're going for (some multi-stage or re-noising techniques do this on purpose - this just isn't the node that validates you meant it).
It changes your step count. Every appended value is an extra step the sampler will run. If you're chaining this into a sampler with a fixed expected step count elsewhere in the workflow, double check the total after appending - Sigmas Count is the quick way to confirm.
Not covered in the README. Like the rest of the sigma toolbox, this is inferred from the exposed parameters rather than documented behavior. It's simple enough that there's not much to get wrong, but there's also no community write-up to lean on if the result looks off - check the actual output values, not just the wiring.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| sigmas | SIGMAS | — | |
| value | FLOAT | 0.00-10000–10000 | — |
| count | INT | 11–100 | — |
| additional_sigmasopt | SIGMAS | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SIGMAS | SIGMAS | — |