IAMCCS Shotboard V4 Retake Prompt Encode R2
Let the timeline own the retake prompt — this node just encodes it
- clip
- cine_linx
- positive
- negative
- effective_prompt
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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| cine_linx | IAMCCS_SUPERNODE_LINX | — | |
| negative_promptopt | STRING | pc game, console game, video game, cartoon, childish, ugly | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| effective_prompt | STRING | — |