Segment Plan From Planner (per index)

IAMCCS_SegmentPlanFromPlanner is the index-into-the-plan companion to IAMCCS_SegmentPlanner. Where the full planner computes the entire segmentation of a song and then hands you the current segment's numbers, this node skips the planning entirely: you feed it the already-planned global values and it derives the per-index numbers for whatever segment_index you're on.

Why would you want that? Performance and cleanliness in loop workflows. If your graph already computed the full plan once (up front, outside the loop), every iteration inside the loop doesn't need to redo the song math - it just needs "what is segment 4's raw frame count, start, and end?" This node is that lookup, with a much smaller input surface than the full planner.

How it works

It's a pure derivation, all arithmetic and no model calls. Given total_frames, unique_segment_frames, first_segment_raw_frames, continuation_raw_frames, estimated_segments, and last_segment_unique_frames, it computes the current segment's start (unique frames × index), clamps the index to the last real segment, picks raw frames (first segment → first_segment_raw_frames, last → a recomputed rounded value, middle → continuation_raw_frames), and converts frame positions to seconds using fps. The overlap hint is derived as the difference between continuation and unique frames.

The eight inputs are exactly the outputs the main SegmentPlanner produces, so wiring it up is mechanical: take the global plan outputs from a SegmentPlanner, feed them here, and drive segment_index from your loop.

Inputs and outputs

Inputs: fps, total_frames, unique_segment_frames, first_segment_raw_frames, continuation_raw_frames, estimated_segments, last_segment_unique_frames, and segment_index.

Outputs - the current segment's plan:

• segment_index_out - the clamped index actually used
• current_segment_raw_frames - frames to actually generate (this segment)
• current_segment_unique_frames - frames of new content, no overlap
• current_segment_start_frames / current_segment_end_frames - position in the overall timeline
• current_remaining_frames_after
• current_segment_start_s / current_segment_end_s - same positions in seconds
• current_segment_report - a readable one-liner for debugging

Wire current_segment_raw_frames into your sampler length and the range-from-plan node; feed current_segment_start_s/_end_s to anything that needs the time position (like audio conditioning).

Installing

ComfyUI Manager → search "IAMCCS", or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart. No models, no pip deps - the LTX-2 model/VAEs that actually render are the workflow's problem, not this node's.

Gotchas

The classic mistake is feeding it stale plan values - if you change the song duration or fps upstream but the numbers flowing into this node are from a cached old plan, every segment will be consistently wrong in the same way. Because the plan is computed elsewhere, it never re-validates against the song. Also note the last-segment raw frames are recomputed locally (rounded up to LTX's 8n+1 pattern) rather than taken verbatim, so don't expect the last segment's raw count to equal last_segment_unique_frames + overlap when the numbers don't divide evenly.