GodnessMerger_MiddleBlockExperimental

Same family, same idea, one difference: where the plain GodnessMerger_MiddleBlock node just spits out a ratio from a seed/min/max/type recipe, this "Experimental" sibling also takes a model input. Everything else on the surface is identical - same knobs, same output type (GM_MIDDLE_BLOCK) - so the honest answer to "what does the model input actually change" is: the pack's README doesn't say, and I'm not going to guess at internals I can't see. My best read, going purely off what taking a live model would let a node do that a model-blind one can't: the U-Net's middle block isn't a single tensor, it's a stack of sub-layers (ResBlocks and attention), and having the actual model in hand would let a node see how many sub-layers are really there and potentially assign ratios per sub-layer instead of one flat number for the whole block. Treat that as an educated guess, not documentation - it's exactly the kind of gap that's worth flagging rather than papering over.

What's grounded, versus what's a guess

Grounded: this belongs to SP-Nodes' "Godness Merger" modular merge system, named after the real sub-modules of the classic SD U-Net (time_embed, label_emb, middle_block, output_blocks, out). The middle block is the U-Net's bottleneck - lowest resolution, most compressed representation, a small slice of total parameters that nonetheless has outsized influence on overall composition. That part I'm confident about.

Guessed, and flagged as such: the exact reason this variant needs a model input where its sibling doesn't. Take the practical advice below at face value regardless - it holds either way.

The inputs

• model - the model this variant needs that the plain version doesn't. Wire in either of the two checkpoints you're about to merge.
• type - custom for a ratio you set by hand, random for a reproducible roll.
• min / max - bounds for the random draw (0–1).
• custom_value - read only when type is custom.
• seed - pins the random draw so it's reproducible.

Output: GM_MIDDLE_BLOCK, same type as the non-experimental version, meant for a merge combiner elsewhere in the pack that this batch of briefs doesn't cover.

Installing SP-Nodes

Manager: search "SP-Nodes," install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Then restart. No model download for this node - it consumes a model you've already loaded, it doesn't fetch one.

Troubleshooting

The usual red "missing node type" box shows up if you load a workflow with this node before SP-Nodes is installed - install via Manager, restart, move on.

Because this node needs a live model wired in, forgetting to connect it (easy to do if you're swapping it in for the plain MiddleBlock node mid-workflow) will error immediately rather than silently doing nothing - that's actually a small mercy compared to some of this pack's other data-only nodes. And since "Experimental" is the author's own label, not mine, I'd treat this one as the node to reach for when you're specifically trying to see if per-layer awareness changes your merge results, not as the default choice - start with the plain MiddleBlock node unless you have a reason to believe it isn't doing what you want.