DP Prompt Travel Prompt

"Prompt travel" is the technique of changing your prompt at specific points across an animation instead of keeping it fixed for every frame - one description at the start, a different one by the middle, so the generation morphs rather than staying static. It grew out of the AnimateDiff era and it's still how a lot of prompt-driven motion and morphing gets built today. This node is the building block for that: one node holds one prompt "entry" - positive and negative - and you chain several of them together to build up the full schedule.

How it works

Each instance takes a positive_prompt and negative_prompt, and optionally chains in from an upstream entry via positive_in/negative_in. That optional chain-in pattern is the tell: this node is built to be daisy-chained, with each instance in the chain contributing one keyframe's worth of prompt text and passing the accumulated result forward to the next. String several together and you build a multi-point prompt schedule without hand-writing the timing syntax yourself.

The single prompt output means the node collapses whatever it's holding - this entry plus anything chained in before it - into one string, ready to feed into whatever downstream node in your workflow actually consumes prompt-travel-formatted text (an AnimateDiff-style batch prompt scheduler, or your own conditioning setup).

Inputs and outputs

Required:

• positive_prompt (multiline text) - what this keyframe's positive prompt says.
• negative_prompt (multiline text) - what this keyframe's negative prompt says.

Optional, for chaining:

• positive_in / negative_in (multiline text) - feed in the output of an earlier node in the chain here to build a multi-keyframe schedule instead of a single entry.

One output: prompt (STRING) - the accumulated schedule text.

Installing it

ComfyUI Manager: search ComfyUI-Desert-Pixel-Nodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/DesertPixelAi/ComfyUI-Desert-Pixel-Nodes

Restart ComfyUI - no models, pure text assembly.

Where people get tripped up

The chain-in inputs are optional, which means it's easy to leave them disconnected by accident when you meant to build a multi-entry schedule - if your "schedule" is coming out as just the last node's text and none of the earlier keyframes you set up, check that positive_in/negative_in are actually wired from the previous node in the chain rather than left empty.

The bigger thing to get right before you reach for this node at all: prompt travel only does anything if whatever consumes its output actually knows how to interpret a scheduled/keyframed prompt across a batch of frames. Wiring this node's prompt output straight into a plain single-shot CLIP Text Encode won't animate anything - it'll just encode whatever text ends up in the string. This node builds the schedule text; something else in your graph (an AnimateDiff-Evolved-style batch prompt node, or your own conditioning scheduler) has to be the piece that actually reads and applies it frame by frame. If nothing changes across your animation, that's usually where to look first, not at this node.