Bernini-R Segment Schedule

Want a video where the first forty frames are a cat on a street and the last forty are a dog in a park, with a smooth blend between? The naive way is to generate two clips and splice them, which gives you a hard, ugly cut and two different scenes that don't cohere. BerniniR_SegmentSchedule is the pack's answer: a prompt-travel schedule where you give each frame range its own prompt, and the sampler denoises the whole video in one pass, swapping the text embedding per temporal window with a linear crossfade at the boundaries.

How it works

You write a schedule in the format start-end: prompt, segments separated by ; or newlines, frames 1-based. The node encodes each segment's prompt (using the same Wan T5 encoder and disk-cache machinery as BerniniR_PromptEmbedding), then attaches per-segment latent ranges and a crossfade overlap to the conditioning. The sampler then builds its context-window wrapper from that data and swaps the positive prompt embedding per window, blending adjacent segments. Crucially, it reuses the context-window machinery - this isn't two independent denoising passes stitched together, it's one coherent generation with a changing prompt. The node's description notes it's compatible with NAG, since it outputs standard CONDITIONING.

The inputs that matter

• positive_prompt - the schedule itself. The default is a working example: 1-40: a cat walking on a sunny street; 41-81: a dog running in the park. This is the whole game.
• total_frames - total pixel frames of the output video. Everything in the schedule is in pixel frames (1-based).
• negative_prompt - one shared negative for all segments. Defaults to the same Wan-style quality negative as the prompt planner.
• transition_frames - crossfade width between adjacent segments in pixel frames (converted to latent by /4). Default 8; 0 = hard cut. Wider = smoother, but also fuzzier at the boundary.

Then the CLIP handling, which works just like the prompt planner's: clip input (preferred, from BerniniR_CLIPLoader), or clip_name/clip_type/clip_device, plus force_offload and use_disk_cache for VRAM.

Outputs and wiring

Two: positive and negative (CONDITIONING), which connect directly to BerniniR_KSampler or BerniniR_DualExpertSampler. The sampler does the rest.

Where people get burned

Three classic mistakes. Frame accounting - the schedule is 1-based pixel frames, so segments must stay inside total_frames and ideally not leave gaps (a gap means a segment with no prompt). Forgetting the crossfade exists - a huge transition_frames on a short segment eats the whole thing; keep transitions small relative to segment length. Mismatched lengths - if the sampler's latent is shorter than total_frames expects, the schedule just won't cover the video. And one honest caveat: this is prompt-travel, not a multi-scene editor. Each segment gets one prompt, so a "scene change" here is a subject/scene change expressed through the prompt - you can't also change resolution or camera within a run. That's what editing is for.