Keyframed Condition

Prompt scheduling - the thing this pack is really about - is just "attach this prompt to this moment, and make the transition between moments feel right." KfKeyframedCondition is the node that does the attaching. It takes a conditioning (the output of a CLIP Text Encode), a time, and an interpolation method, and returns a keyframed condition: a single prompt pinned to a point on your animation timeline. Feed several of these into a schedule and you've got a prompt that morphs from one description to the next as the animation plays.

This is the low-level building block. Most people will prefer the Schedule Prompt node, which bundles CLIP encoding, keyframing, and schedule-adding into one step - but if you want to understand how scheduling works, or you want to keyframe a conditioning you've already built (LoRA-applied, SDXL dual-encoded, whatever), this is the node you're holding.

Why you'd reach for it

You're assembling a prompt schedule by hand: encode each prompt with CLIP Text Encode, pin each one with KfKeyframedCondition at its time, then pass the conditions through Set Keyframe to build the schedule and KfGetScheduleConditionAtTime/Slice to read it back. Or you're doing something the convenience node can't - keyframing an existing conditioning object rather than raw text. Either way, the interpolation dropdown is where the feel of your transition lives.

The inputs that matter

• conditioning - a CONDITIONING, straight from a CLIP text encode.
• time - a FLOAT, default 0, stepped by 1. Your frame index (or fractional time, since it's a float). The README's rule of thumb: the first keyframe in any schedule should live at time=0.
• interpolation_method - the transition style used after this keyframe when interpolating toward the next one. The dropdown offers null, previous, next, linear, sin, and sin^2:
  • null - defaults to previous: hold this keyframe's value until the next keyframe, then jump. A hard cut.
  • previous - hold until the next keyframe.
  • next - take the next keyframe's value immediately.
  • linear - straight lerp, matching Deforum and FizzNodes behavior. The safest default.
  • sin - sine easing; slow at both ends, fastest mid-transition.
  • sin^2 - eased lerp; starts and ends slower, with a faster middle.

Output is a single KEYFRAMED_CONDITION, which feeds Set Keyframe to enter the schedule.

How it works

A conditioning in ComfyUI is really two tensors: the cross-attention tensor and the pooled output (the pooled_output used by SDXL-class encoders). This node splits them apart and wraps each in its own keyframed.Keyframe, carrying the rest of the conditioning dict alongside. That split is why schedule interpolation works - the library lerps the actual token tensors, not some approximation. The interpolation method stored on the previous keyframe is what governs the tween to the next one.

Installing it

Part of ComfyUI-Keyframed (dmarx's pack wrapping his keyframed library). ComfyUI Manager: search "Keyframed". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/dmarx/ComfyUI-Keyframed

Restart ComfyUI. The pack auto-installs keyframed and toolz on first load; no model downloads.

Troubleshooting

The most common setup mistake is a schedule with no keyframe at time=0 - the README calls it out explicitly, and evaluating a schedule before its first keyframe gives you undefined behavior. Also: null/previous interpolation produces hard cuts, which reads as a prompt that abruptly changes; if you wanted a smooth morph you meant linear or sin. And keep in mind the pool here is genuinely additive per keyframe - a bad interpolation choice at one keyframe affects the tween into the next, so pick the method on the keyframe that starts each transition, not the one that ends it.