String Schedule | Deforum

String Schedule | Deforum is Prompt Schedule | Deforum with the encoding step taken out. Same keyframe syntax, same interpolation, same --neg splitting, same backtick math expressions - but instead of handing you finished CLIP conditioning, it hands you the actual resolved prompt strings for the current frame. That makes it the debug tool and the flexible backbone of the pack's schedule family.

You feed it text (the "frame" : "prompt" schedule), max_frames, current_frame, and optional pre_text/app_text plus pw_a–pw_d. The two outputs are POS and NEG, both plain STRING. Each contains the interpolated prompt text for current_frame - the positive, and the negative (everything after --neg, with any pre/app text applied). What you do with them is up to you: run them through a regular CLIP Text Encode, inspect them to see exactly what the schedule resolves to at frame 47, or pipe them into any node that wants text.

Why would you want the strings instead of the conditioning? Three reasons. First, debugging. With Prompt Schedule, if a transition looks wrong you're guessing at what the blend is doing - here you can read the literal text at any frame and confirm your keyframes and math expressions are producing what you think. Second, encoder flexibility: if your workflow uses a different encoder, a per-token system, or you want to post-process the prompt (append weights, swap terms) before encoding, having the raw string is the only way in. Third, the string output feeds text-driven routing - run it into String to Combo | Deforum or a string comparison to make the schedule drive logic, not just conditioning.

One thing to be clear-eyed about: the string is the interpolated prompt at that frame, but the smoothness of a Deforum transition lives partly in conditioning space - Prompt Schedule blends the encoded vectors, while here you just get the text at the current frame's weight position. For most morphing purposes you'll want the conditioning version. Treat this node as the view-source and the routing layer.

The inputs carry the same gotchas as its sibling: current_frame is a socket you wire from your loop counter, max_frames must match your actual animation length or the frame wraps modulo and you'll watch the same two prompts loop, and the default template is a 0-to-119 empty schedule you're expected to overwrite. Math in backticks works identically, with t, max_f, and pw_a–pw_d available.

Installation is the pack - ComfyUI Manager → search "ComfyUI-Deforum" or deforum-comfy-nodes → install and restart, or git clone https://github.com/deforum-art/deforum-comfy-nodes into ComfyUI/custom_nodes and restart. No models, no extra dependencies. If you've ever stared at a schedule node's console output wondering what it actually generated, this is the node that answers that question on the canvas instead of in the log.