DA_Enhanced_KSampler
WAS_KSampler's spirit, with shift and preview control folded in
- model
- positive
- negative
- latent_image
- LATENT
This is a full KSampler - model, conditioning, and latent in, denoised latent out - with two extras stock ComfyUI makes you handle as separate nodes: a built-in timestep shift, and a knob for how often it bothers rendering a live preview. The pack's own credits trace its lineage to WAS_KSampler from was-node-suite-comfyui, a foundational early ComfyUI utility pack that's since been archived and isn't actively maintained. DemonAlone rebuilt the idea rather than depending on an abandoned pack.
What the extra knobs actually do
shift (default 3, range 0–100) folds in what ComfyUI usually handles with a separate patch node - ModelSamplingSD3, ModelSamplingAuraFlow, or similar - ahead of the sampler. Shift changes how sampling effort is distributed between early, composition-deciding steps and later, detail-deciding ones. It matters most on flow-matching architectures (Flux, Z-Image, SD3-family, Anima), where it's become roughly what scheduler tuning used to be on older models - Z-Image Turbo, for instance, is commonly run at shift 7 rather than ComfyUI's own default of 3. On classic DDPM-style checkpoints (SD 1.5, SDXL, and every SDXL finetune including Pony and Illustrious), shift matters far less; you can mostly leave it at default and not think about it. Baking this into the sampler node itself is a genuine convenience - one fewer node in the graph than the stock two-node setup.
preview_freq (default 1, range 1–100, tooltip: "How often to update the preview (e.g., 2 for every other step)") controls how often a live preview gets rendered during sampling. Every-step previews aren't free - each one is a partial decode - so on a long run this is a real lever between "smooth live feedback" and "faster sampling with choppier preview updates." Set it to 1 while you're dialing in a new prompt and want to watch every step; bump it up once you trust the setup and just want speed.
The rest of the inputs
model, positive/negative (CONDITIONING), and latent_image are the standard sampler plumbing. seed, steps (default 28), and denoise (default 1, meaning full denoise from pure noise - drop it for img2img-style partial denoising) behave exactly like stock KSampler. sampler_name and scheduler expose ComfyUI's full sampler and scheduler lists.
One default worth knowing rather than trusting blindly: cfg defaults to 7, which is the right neighborhood for SD 1.5 and SDXL-family checkpoints but wrong for anything guidance-distilled or flow-matching - Turbo, Lightning, and most 2026-era distilled releases want cfg close to 1, and running them at 7 oversaturates and burns the image. Match cfg to your checkpoint's own documentation, not this node's default.
Similarly, sampler_name/scheduler defaults are worth checking against your architecture rather than assuming one pair works everywhere: DPM++ 2M Karras is the safe SD 1.5/SDXL default, but Karras and exponential schedules are near-universal failures on flow-matching models, which want Euler-family samplers on beta, simple, or sgm_uniform instead.
Output is a single LATENT, same as stock KSampler.
How to install it
ComfyUI Manager: search DemonAlone-nodes-ComfyUI, install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/DemonAlone/DemonAlone-nodes-ComfyUI
then restart. No extra models - it samples with whatever model, VAE, and conditioning you already have loaded elsewhere in the graph.
Common issues & troubleshooting
Output looks blown out or oversaturated. Almost always cfg too high for the checkpoint. Check whether you're on a distilled or flow-matching model expecting cfg near 1 before assuming a sampler or shift problem.
Changing shift seems to do nothing. Some schedulers apply their own internal sigma shift and ignore the node's shift value - if you're not seeing an effect, try a different scheduler before concluding the control is broken. Shift's impact is also genuinely smaller on DDPM-style checkpoints, so a non-effect there can just be architecture, not a bug.
Live preview is choppy or missing steps. That's preview_freq doing exactly what it's set to - set it back to 1 if you want a preview on every step, at the cost of some sampling speed.
Output looks fine but generation is slower than the stock KSampler. Preview rendering and shift patching both add a small amount of overhead versus the bare stock node. If speed matters more than the extra controls for a given run, preview_freq at a higher value recovers most of that gap.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| seed | INT | 00–18446744073709550000 | — |
| shift | FLOAT | 3.000–100 | — |
| steps | INT | 281–10000 | — |
| cfg | FLOAT | 7.000–100 | — |
| sampler_name | COMBO | 44 options: euler, euler_cfg_pp, euler_ancestral, euler_ancestral_cfg_pp, heun, heunpp2, +38 | |
| scheduler | COMBO | 9 options: simple, sgm_uniform, karras, exponential, ddim_uniform, beta, +3 | |
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| latent_image | LATENT | — | |
| denoise | FLOAT | 1.000–1 | — |
| preview_freq | INT | 11–100 | How often to update the preview (e.g., 2 for every other step). |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LATENT | LATENT | — |