Nodes/IAMCCS-nodes/IAMCCS H3 R40 · Cached Take Select Control
ComfyUI Node

IAMCCS H3 R40 · Cached Take Select Control

Two widgets that decide the winning take — and which latent stage-2 starts from

By IAMCCS·Created 11 months ago·Updated a day ago· 113
IAMCCS H3 R40 · Cached Take Select Control
    • take_select
    • helper
    selected_candidate1
    stage2_latent_sourcedenoised_x0

    In the R40 Shot Lab, selecting the winning take is supposed to be a two-second decision, not a re-render. IAMCCS_MiniMaxH3TakeSelectControlR40 is the smallest node in the family - two dropdowns, one output - and it's the one you'll touch the most while iterating on a shot.

    It produces a take_select contract object that IAMCCS_MiniMaxH3SeedSelectR40 consumes to know which cached candidate to pull. And because the candidates are all cached and upstream, flipping this node from take 1 to take 4 reuses the entire candidate bank. The node's own helper text puts it plainly: "Changing the take reuses all cacheable candidates." That's the whole R40 caching argument in one sentence - the expensive part of a shot is the scouting and the native decode, and neither one should rerun just because you changed your mind about which take you liked.

    The two widgets

    • selected_candidate - which of the four scout candidates (1–4) won. This is the actual artistic decision: you previewed the takes, this is where you record the verdict.
    • stage2_latent_source - which latent view of that take stage-2 refine should start from: denoised_x0 (the default) or sampled_output.

    The second widget is the one people overlook, and it deserves a beat. When you sample, you get both the noisy-toward-final sampled_output and the denoised estimate (denoised_x0). Stage-2 refine starts from denoised_x0 by default because a refine pass wants to begin from a cleaner prediction rather than re-denoise the fully-noised sample. Think of it as the difference between "redevelop this frame" and "polish what's already developed." Unless you're deliberately experimenting with how much stage-2 re-does, leave it on denoised_x0.

    Both choices get packed into a small schema-versioned object, iamccs.minimax_h3.r40.take_select, which is the only output (plus a helper string echoing the rules). selected_candidate is clamped to 1–4 on the way out, so you can't build an invalid contract by accident.

    Where it sits

    The graph reads: four SeedCandidateR40 nodes → SeedPreviewR40 on each → this selector → SeedSelectR40SelectedDecodeR40 → checkpoint → stage-2/delivery. This node is the "judge," SeedSelectR40 is the "executor," and they're deliberately split so the choice (cheap, human) lives apart from the mechanism (lazy, cached).

    Worth flagging: this node doesn't look at the candidates at all. It just declares a winner. If you select take 2 but candidate 2 never actually sampled (the shot plan only configured one candidate, say), you'll discover it downstream when SeedSelectR40 raises "candidate 2 is not active." The selector's job is to pick among available takes - it can't know what you meant to be available.

    Install

    It's in IAMCCS-nodes, so:

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

    or install via ComfyUI Manager (search "IAMCCS"), then restart. Beyond the pack you need the R40 ecosystem around it and the H3 stack - current ComfyUI (≥ 3.x), MiniMax H3 weights plus video/audio VAEs - and remember the H3 licence excludes the US, EU, UK and Korea. If you're using this node, you've already committed to that pipeline's way of working, and this is the friendliest part of it.

    CategoryIAMCCS/MiniMax H3/R40 Shot Lab

    Inputs (2)

    NameTypeDefaultDescription
    selected_candidateCOMBO14 options: 1, 2, 3, 4
    stage2_latent_sourceCOMBOdenoised_x02 options: denoised_x0, sampled_output

    Outputs (2)

    NameTypeDescription
    take_selectIAMCCS_H3_R40_TAKE_SELECT
    helperSTRING