KSampler Sequence (v2)

This is the second generation of the sequence sampler, and the difference is the schedule. The original counts loops; this one counts frames and changes prompt when the frame number lands on a keyframe - which means it pairs with CLIP Text Encode Sequence (v2), a node that computes the whole keyframe schedule for you from a prompt list and a total frame count.

If you're starting fresh in 2026, start here. The v2 pair is easier to reason about, and this node carries the three features the old one didn't have: noise injection, a denoise that swings over the length of the run, and a seed that follows a repeating pattern instead of just stepping.

Feeding it

model is your diffusion model and positive_seq / negative_seq are the prompts. They accept either the list that the v2 encoder produces - stepped through on the same keyframes as each other - or a single plain conditioning, which is then used for every frame.

frame_count and cond_keyframes are the schedule. Wire them from the encoder's matching outputs and don't type them by hand. The default of 0 for each is a deliberate trap-defuser: at frame_count 0, or with no keyframes connected, the run becomes one frame per prompt instead of a sequence.

latent_image, steps, cfg, sampler_name and scheduler are what you'd expect. steps is per frame and the whole run costs that times the frame count, so a 100-frame run at 20 steps is 2,000 sampler steps - that's the number to sanity-check before you queue. On the sampler choice: euler is the steadiest across a sequence, and the ancestral and SDE variants add both detail and frame-to-frame flicker, which is a real trade and not a moral failing.

The knobs that exist because long runs stall

A sequence sampled this way has a failure mode: each frame starts from the last, so it settles. It stops moving. Three features here push back.

inject_noise with noise_strength stirs fresh noise into each frame before sampling - 0.1 keeps the picture and adds movement, above about 0.3 the composition starts breaking up frame to frame. That's the cheapest anti-stall lever.

denoise_sine with denoise_seq and denoise_max makes the denoise swing between two bounds across the run "on a sine wave", in the node's own words, so the sequence breathes - settling for a stretch, opening up again. denoise_seq is the low end (0.2 barely moves, 0.5 changes noticeably), denoise_max the high end (0.9 lets the picture change a great deal at the top of the wave).

seed_keying with seed_keying_mode and seed_divisor ties the seed to the frame number. sine swings it smoothly around the base seed once every seed_divisor frames; modulo holds it and jumps on every divisor-th frame, skipping the unsample pass on those frames. The point, per the tooltip, is that a repeating pattern brings back seeds the run has already used - so the sequence comes back round to a look instead of drifting away from it for good. 4 gives a fast flutter, 24 a slow swing across a second of video.

unsample_latents is the expensive one and worth knowing about: each frame first runs the sampler backwards over the previous one, pushing it back up the noise schedule before resampling, so the new prompt has something to re-resolve rather than a finished image to leave alone. Roughly double the time per frame.

The gotchas, in order of how often they bite

use_conditioning_slerp does not work the way it does on the older node. On v2 it rebuilds each frame's conditioning from its embedding and pooled output alone - so anything else the prompt carried, an area, a mask, a control hint, is dropped. Its tooltip says to leave it off unless the prompts are plain text encodes, and that's advice, not a suggestion. And cond_slerp_strength genuinely does nothing here: the two ends of the interpolation are the same prompt. It's the one widget in the node that exists for symmetry.

use_latent_interpolation with latent_interp_strength is the real jumpiness control - 1.0 keeps the new frame whole, 0.5 is an even blend with the one before, and low values nearly freeze the sequence. Slerp holds contrast better than Blend.

And the scale problem: this is the last node in the pack you want to point at 500 frames. Everything multiplies - steps, time, and accumulated drift.

Installing it

It's in WAS Node Suite v3 - MIT, WASasquatch, 468 nodes - so install the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

ComfyUI Manager's WAS Node Suite v3 entry is the recommended route. ComfyUI 0.14.0+, Python 3.10+, no pip packages installed, nothing downloaded. First start after install (or after a pull) is a beat slower while it writes config.yaml under <ComfyUI user dir>/was-node-suite/ and compiles the pack. The sequence samplers sit in the extras feature group, which is enabled out of the box - if they're missing, that switch is the first place to look.

Worth saying plainly: no sequence sampler in this pack generates motion the way a video model does. There's no temporal attention, no time axis, no idea that frame 12 follows frame 11. The samplers chain latent resampling and let the prompt schedule steer, which makes convincing morphs, prompt travel and short loops - and unconvincing everything else. If you want a moving shot, that's a Wan or LTX-shaped problem now.