sch_text

sch_text is sch_Prompt with the last step removed. Same keyframe-list format, same 23 easing curves, same frame-driven interpolation - but instead of encoding straight to CONDITIONING, it hands you back the raw ingredients: the current keyframe's text, the upcoming keyframe's text, and a weight number telling you how far between the two you currently are. You do the CLIP encoding and blending yourself.

That sounds like more work, and it is, but it buys you flexibility sch_Prompt doesn't have. Need to route the text through something other than a single CLIP (SDXL's dual encoders, Flux's two clips)? Want to eyeball the actual prompt string in a debug node before it hits the sampler? Want to feed it into a translation or prompt-expansion node mid-pipeline instead of straight to conditioning? sch_text gives you the hook point sch_Prompt doesn't.

Inputs

• keyframe_list - multiline string of frame_number@text pairs. Default placeholder: frame_number@text.
• current_frame - the frame you're currently rendering.
• easing_type - one of 23 choices (Linear, Sine_In/Out/InOut, Sin_Squared, Quart, Cubic, Circ, and more the node menu truncates past a dozen). This is the same Penner-style easing suite used across web and game animation, repurposed here to shape how fast one prompt's influence hands off to the next rather than snapping instantly.

There's no optional block - all three are required.

Outputs

• current_prompt (STRING) - the text of the keyframe at or before current_frame.
• next_prompt (STRING) - the text of the upcoming keyframe.
• weight (FLOAT) - the eased position between the two, roughly 0 to 1, telling you how much of next_prompt should be blending in.

The typical wiring: current_prompt into one CLIPTextEncode, next_prompt into a second, then blend the two resulting CONDITIONING outputs by weight using ConditioningAverage or a similar node. If that sounds like exactly what sch_Prompt does internally - it is. Use sch_text when you need the pieces separately; use sch_Prompt when you just want the finished CONDITIONING and don't care how it got there.

Setting it up

Write your prompts as frame@text lines - one per keyframe, @ is the fixed separator - and pick an easing curve. Linear is the safe default if you're not sure what the others do; the In/Out/InOut variants accelerate or decelerate the transition instead of blending at a constant rate.

Install

ComfyUI Manager: search "ComfyUI-Apt_Preset," install, restart. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git, then restart. The included install.bat is a Windows dependency installer - on Linux or a cloud box, open it to see what it pip-installs and run that yourself, or let ComfyUI Manager's "install missing nodes" prompt handle it.

Troubleshooting

Get the separator wrong (using : instead of @, a habit if you've used Deforum/FizzNodes-style scheduling before) and the parse either errors or silently collapses to a single keyframe - double-check your keyframe_list if next_prompt never seems to change.

This pack has documented import failures in the wild: a comfyui subreddit thread shows a user's console logging (IMPORT FAILED): ...ComfyUI-Apt_Preset after loading a workflow that used it. The fix that worked for them was using ComfyUI Manager's "install missing custom nodes," or manually deleting and re-cloning the ComfyUI-Apt_Preset folder and restarting - check your own console output for the specific missing dependency before assuming the node code itself is at fault.

If you're wiring this into ControlNet timing schedules elsewhere in the same pack, the README calls out that its controlnet schedule feature needs ComfyUI-Advanced-ControlNet installed first.