Sigmas HarmonicDecay

The harmonic series - 1, 1/2, 1/3, 1/4, and so on - decays in a very specific, well-known way: fast at first, then slower and slower, famously slow enough that the series diverges if you sum it forever. Sigmas HarmonicDecay generates a noise schedule shaped like that curve, sweeping from start_value down to end_value over steps, rather than transforming an existing schedule like most of this pack's other sigma-math nodes. No sigmas input here - you're building a curve, not reshaping one.

Why this shape might be interesting

Every scheduler is really just a choice about where along the noise-removal process you spend your steps. A linear schedule spends them evenly. Karras and beta57 concentrate them toward the middle or the low-noise end. A harmonic curve is its own distinct shape: heavy movement early, then a long, slowly-flattening tail - conceptually the inverse emphasis of a curve like Karras's, which is usually described as concentrating effort in the middle. Whether that's actually good for image quality on any particular model isn't something anyone's published a comparison for, but it's at least a coherent, well-defined mathematical shape rather than an arbitrary one.

How it works

Generates steps values following harmonic-series decay from start_value toward end_value, with harmonic_offset shifting which term of the series you start counting from and decay_rate controlling how aggressively it falls off. pad_end, when on, presumably ensures the final step actually lands at (or very near) end_value rather than asymptotically approaching it and stopping short - harmonic decay is famously slow to actually reach a target, so without padding you might not get all the way down to your intended floor.

The inputs and outputs that matter

• steps (default 30, range 1–1000) - how many schedule steps to generate.
• start_value (default 10, range 0–100) - the schedule's peak.
• end_value (default 0.01, range 0–100) - the target floor.
• harmonic_offset (default 0, range 0–10) - shifts the starting term of the series.
• decay_rate (default 1, range 0.1–10) - how fast the curve falls.
• pad_end (default true) - ensures the schedule actually reaches end_value at the last step.

Output is a single SIGMAS list.

Should you use this?

No README coverage and no community reports of anyone using it in practice, same as the rest of RES4LYF's generator-style sigma-math nodes. It's a well-defined, deterministic curve shape if you want to experiment with something other than the pack's tested schedulers - but there's no evidence it beats beta57 or a standard Karras/beta schedule on real output, so treat it as raw material rather than a technique with a proven payoff.

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: use the embedded pip.exe). Restart.

Common issues & troubleshooting

Without pad_end, the schedule may fall short of end_value. Harmonic decay slows dramatically as it goes, so at low steps counts especially, don't be surprised if the tail sits noticeably above your intended floor unless padding is on.

High decay_rate front-loads almost all the change into the first few steps, leaving a long, nearly flat tail - that can look like the schedule "stalls" late in the run. If your renders look under-refined at the end, try lowering decay_rate or reducing steps so the flat tail doesn't eat into your step budget.

start_value should be set to something in the neighborhood of your model's actual peak sigma, not left at the default without checking - a schedule that starts too low or too high relative to what your sampler expects will misbehave regardless of the decay shape.