Nodes/IAMCCS-nodes/IAMCCS Shotboard V4 Retake Prompt Encode R2
ComfyUI Node

IAMCCS Shotboard V4 Retake Prompt Encode R2

Let the timeline own the retake prompt — this node just encodes it

By IAMCCS·Created 11 months ago·Updated 4 days ago· 113
IAMCCS Shotboard V4 Retake Prompt Encode R2
  • clip
  • cine_linx
  • positive
  • negative
  • effective_prompt
negative_promptpc game, console game, video game, cartoon, childish, ugly

A retake in the IAMCCS Shotboard means "regenerate this clip, differently." But how differently is a decision that lives in the timeline metadata, not in a prompt box you keep in sync by hand. This tiny node is the mechanism that keeps them together: it reads the retake prompt out of your cine_linx bus, encodes it into real CONDITIONING tensors, and hands you the positive/negative pair your sampler actually wants.

The class is in the "Experimental R2" branch of the pack, which is worth knowing before you build your whole pipeline around it - this is where IAMCCS iterates on the V4 retake path, so it can move faster than the stable planner nodes. It's also genuinely small: two required inputs (clip and cine_linx), one optional (negative_prompt), three outputs (positive, negative, and effective_prompt).

How it behaves: it digs the retake prompt out of the shotboard timeline inside cine_linx - a per-retake override if one is set, otherwise the global prompt. If there's no prompt at all, it raises a clear error telling you to write one before queueing. The negative comes from your optional negative_prompt widget (the default is the pack's house style: "pc game, console game, video game, cartoon, childish, ugly" - fine for cinematic work, swap it for anything model-specific). Under the hood it just calls ComfyUI's standard CLIPTextEncode on both. Nothing exotic, which is the point: the value isn't in the encoding, it's in where the prompt comes from.

The docstring's phrase "leaving LTX frame-rate conditioning explicit" is the design note that matters. This node deliberately does not inject frame-rate or duration language into the conditioning - in this ecosystem, that information belongs to the frame-rate conditioning inputs of the LTX graph, and the retake encode is supposed to stay out of its way. If you've fought with a retake that came out with the right content but wrong pacing, this is the fix: keep pacing on the LTX side, keep intent here.

The three outputs wire up as you'd expect: positive and negative into your sampler's conditioning sockets, and effective_prompt into a text node (or the report pipeline) so you can see exactly what got encoded - which is your debugging tool when a retake comes back identical to the original, because the answer is usually "the timeline override was empty and it fell back to global."

Installation is pack-standard: search IAMCCS in ComfyUI Manager, or clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes and restart. No models, no pip deps - it rides entirely on ComfyUI's built-in text encoder, so the only real prerequisite is that your clip comes from a text encoder appropriate to the model you're sampling (Gemma/Qwen-family for the LTX side, the H3 encoder for the H3 side).

The failure mode you'll actually meet: queueing this node without an active retake and getting the "write a Retake prompt override" error. That's not a bug - the node is deliberately refusing to silently encode a stale prompt. The other one is forgetting which side owns pacing; if your retake drifts in duration, the fix is on the LTX frame-rate conditioning, not here.

CategoryIAMCCS/Cine/Shotboard V4/Experimental R2

Inputs (3)

NameTypeDefaultDescription
clipCLIP
cine_linxIAMCCS_SUPERNODE_LINX
negative_promptoptSTRINGpc game, console game, video game, cartoon, childish, ugly

Outputs (3)

NameTypeDescription
positiveCONDITIONING
negativeCONDITIONING
effective_promptSTRING