SD-CN Prompt Schedule

This node is how you tell the SD-CN Animation nodes to change what they're drawing halfway through. Instead of one prompt for the whole clip, you write a keyframe schedule - "at frame 0, a forest; at frame 30, the forest turns to ocean" - and SDCNPromptSchedule encodes those prompts and linearly interpolates the conditioning between keyframes. The result is a single conditioning output that the Txt2Vid and Vid2Vid nodes consume per frame, so the transition is a smooth drift rather than a hard cut. If you've used Deforum, the format will feel like coming home; if you haven't, it's a text box and a promise.

The scheduling trick is that the interpolation happens in conditioning space, not in pixel space - each frame's CLIP embedding is a weighted blend of the neighboring keyframe prompts. That's why the shifts feel gradual even when two prompts are totally different subjects. Frames beyond the last keyframe just hold that final prompt, and the total frame count is owned by the Txt2Vid/Vid2Vid node, not by this one.

Wiring it

Feed it the clip from your checkpoint loader and write the schedule in the text box:

"0": "a serene forest landscape"
"30": "the forest transforms into an ocean"
"60": "a vast ocean under starlight"

The format is "frame_number": "prompt", one per line (it also tolerates the relaxed 0: a cat on a beach style). The conditioning output replaces the normal CLIPTextEncode positive - and yes, it works for the negative input too. Works with both SD1.5 and SDXL, and since the output is plain batched CONDITIONING, the same node also plays nicely with any other node that understands FizzNodes-style batched conditioning. Without this node wired in, the standard CLIPTextEncode workflow behaves exactly as before.

Install

Same pack as the rest of the SD-CN nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/pxl-pshr/ComfyUI-SD-CN-Animation

or ComfyUI Manager (search "ComfyUI-SD-CN-Animation"), then restart. No model downloads, no special dependencies beyond the pack's standard three.

The honest warning

The README flags prompt scheduling as experimental, and you should read the caveat before blaming your workflow. At low processing_strength (below ~0.5), the text prompt has very limited influence per frame, so over a long sequence content drifts away from your intended subject regardless of what the schedule says. Crank processing_strength above 0.55 and the prompt steers harder - but you trade away temporal smoothness, and you may start seeing per-frame flicker as SD re-invents more of each frame. That tension is the core tradeoff of the whole optical-flow approach, and this node is where it bites hardest. The practical recipe: keep scheduled sequences short, lean on the smooth-morphing settings the README recommends, and treat "the forest transforms into an ocean" as a slow drift, not a shot change.