FL MiniMax H3 Beat KSampler

This is where a beat-scheduled H3 workflow actually burns GPU. FL MiniMax H3 Beat KSampler takes the shot_plan from the Beat Shot Planner (or Shot Motion Context), and samples every planned render independently, as its own H3 generation - one editable nested latent per render, returned as a ComfyUI list. Each render can be one prompt section, a shared-context chunk, or a hidden prior-shot prefix from motion context.

The sampler is otherwise a familiar KSampler, just configured to run per planned render: steps, cfg, sampler_name, scheduler, denoise all apply independently to every latent in the plan. The H3-specific bits are the seed policy and the live preview.

The inputs that matter

• seed + seed_mode - the base seed for the first planned render. increment adds the render index to the base seed, so every shot gets a different noise while staying reproducible; fixed reuses the same seed for every render (useful if you want motion context to carry the visual language and don't want per-shot noise divergence - or for A/B testing).
• cfg - the multiplier for the planned visual reference strength. The tooltip is worth reading twice: leave it at 1 for the planner's direct 0–1 blend, because higher values can over-guide references. This is not a "crank for more pop" knob.
• steps - sampling steps per planned render. A long plan times out as steps × renders, not one clip.
• vae (optional) - the H3 video VAE. Required only when the connected Shot Motion Context plan uses visual context, or when live_preview is on.
• live_preview (optional) - decode a lightweight silent MP4 after each completed render. Off by default and costs one extra VAE decode + preview encode per completed render.

Output and workflow flow

The latents output is a list - one nested H3 latent per planned render. Here's the ComfyUI quirk to know about: list outputs aren't streamed between nodes, so this sampler finishes its entire latent list before any downstream node starts. First render finishes, you wait through the rest, then assembly begins. Once the pixel-upscale sampler starts chewing on that list, its completed renders do appear incrementally.

The embedded preview player is genuinely nice - it shows ComfyUI's live latent preview while a chunk is sampling, then swaps in that chunk's completed MP4 when live is on. Preview errors surface in the dashboard without failing the render, and a cached sampler won't regenerate completed previews. Native and Video Helper Suite preview widgets are hidden on this node so you don't get the same preview twice.

Gotchas

Sampling H3 is the heavy part of the whole stack - this is the 33B omni-modal model, and each planned render is its own full generation, so a 10-shot plan is roughly 10× the VRAM-time budget of one render. Don't start with an enormous plan. The hook it installs for motion context is marker-scoped on a cloned model and doesn't modify ComfyUI files, so it's safe to experiment with context on and off. And standard install rules: ComfyUI Manager → FL MiniMax H3, or git clone https://github.com/filliptm/ComfyUI-FL-MiniMaxH3.git into custom_nodes, restart, no extra Python deps, models live in your normal ComfyUI model directories.