WanDancerPadKeyframesList

Wan-Dancer generates a character dancing to your music, and it does it in two stages: a global model plans sparse keyframes across the whole track, then a local model refines each ~5-second segment into real motion. The two "PadKeyframes" nodes are the plumbing between those stages - they take the global keyframes plus the audio and package them into per-segment padded sequences, masks, and sliced audio for the local model.

This is the list version of that job. WanDancerPadKeyframes does it for one segment at a time, and you copy the node per segment, bumping segment_index each time. WanDancerPadKeyframesList is literally a loop around that: the source calls the single node's logic once per index and bundles the results. One node, every segment at once, no copy-paste drift.

How it works

Everything is deterministic tensor placement and audio slicing - no model, no sampling, instant. The inputs are the same keyframe images and full audio track, but instead of segment_index you tell it num_segments, and it emits one padded sequence per segment. Each is segment_length frames (149 by default, ~5 seconds at the hardcoded 30 fps the node assumes), with keyframes placed at their computed positions across the track and zero-padding elsewhere. The mask marks valid keyframe positions, and each audio_segment is the matching window of the track - which is how the dance rhythm stays locked to the music when each segment is refined separately.

Inputs and outputs

• images - the keyframe frames spanning the full track, usually sampled from the global-stage output.
• segment_length (149) - 149 frames at 30fps, the local model's per-pass size. Leave it.
• num_segments - how many padded segments to emit, 1 to 100. This is the knob that replaces the single node's segment_index.
• audio - sliced once per emitted segment.

Outputs are lists, one entry per segment: keyframes_sequence (IMAGE list), keyframes_mask (MASK list), and audio_segment (AUDIO list). These slot into list-capable graphs; if you're on a plain linear workflow where each segment gets its own WanDancerVideo, the single WanDancerPadKeyframes with one node per segment may actually be clearer. The List version shines when you're batching and want to avoid a wall of near-identical nodes.

Getting it

It's core ComfyUI - native Wan-Dancer support landed in May 2026 in comfy_extras/nodes_wandancer.py, nothing to install. The node loads no model files itself; the surrounding workflow needs the Wan-Dancer global/local diffusion models from Comfy-Org/Wan-Dancer on HuggingFace (into models/diffusion_models/), plus the Wan 2.1 VAE, UMT5-XXL text encoder, clip_vision_h, and a lightx2v LoRA.

Common issues

• Set num_segments to what the audio actually supports. Unlike the single node, which derives segment count from the track, you pick the number here. Go past what the audio length allows and later segments come out as blank, zero-padded frames - no error, just dead weight.
• Audio under ~0.2 seconds or no images triggers the same guard as the single version: fully zeroed sequences and masks.
• It assumes 30 fps. Feed it keyframes generated at another frame rate and the pacing will be off.
• VRAM is a Wan-Dancer problem, not this node's. The local pass samples 149 frames at once and the official workflow warns it wants a serious GPU. The pad node is the cheap part of that pipeline.

Both PadKeyframes nodes are brand-new (a few months old as of this writing) and the model's community reception is still thin, so expect the odd rough edge - but the math here is simple enough that when something's wrong, the audio and the segment count are where to look first.