IAMCCS H3 R40 · Cached Take Select Control
Two widgets that decide the winning take — and which latent stage-2 starts from
- take_select
- helper
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) orsampled_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 → SeedSelectR40 → SelectedDecodeR40 → 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.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| selected_candidate | COMBO | 1 | 4 options: 1, 2, 3, 4 |
| stage2_latent_source | COMBO | denoised_x0 | 2 options: denoised_x0, sampled_output |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| take_select | IAMCCS_H3_R40_TAKE_SELECT | — |
| helper | STRING | — |