GodnessMerger_LabelEmb
Dialing in the merge ratio for SDXL's conditioning block
- GM_LABEL_EMB
This one won't do anything visible by itself, so let's set expectations first: GodnessMerger_LabelEmb is a single ingredient in SP-Nodes' "Godness Merger" system - the pack's homebrew take on controlled-randomization checkpoint merging (the README literally files it under a screenshot titled "model merging based on controlled randomization"). It doesn't take a model and doesn't output one. It outputs a ratio, tagged for one specific sub-module of the U-Net.
Why label_emb specifically
The Godness Merger nodes are named after the actual sub-modules of the classic Stable Diffusion U-Net class: time_embed, label_emb, middle_block, output_blocks, out. label_emb is the one SDXL uses to embed its "extra" conditioning vector - the pooled text embedding plus the micro-conditioning inputs (original size, crop coordinates, target size) that SDXL folds in alongside the usual cross-attention conditioning. In a plain, non-class-conditional SD1.5 checkpoint this block is mostly inert, so in practice this node is an SDXL-era tool: merging it changes how strongly a blend leans on one parent's sense of "how was this image framed and cropped" versus the other's.
What it actually does
Feed it a seed, a min/max range (both 0–1), a type (custom or random), and a custom_value. If type is custom, the node just hands out custom_value as-is. If it's random, it draws one number between min and max, deterministically, from seed - same seed, same draw, every time. That number comes out as GM_LABEL_EMB, a typed value that only a Godness Merger combiner node knows what to do with. This batch of node briefs doesn't cover that combiner, so I can't walk you through the exact downstream wiring - take it as read that somewhere else in the pack, a node collects the GM_* outputs from LabelEmb, MiddleBlock, OutputBlocks, TimeEmbed and Out, along with your two source checkpoints, and does the actual merging.
The inputs that matter
type-customfor a fixed ratio you pick,randomfor a reproducible random one.min/max- the rangerandommode draws from. Leavecustom_valuealone if you're in random mode; it's ignored.custom_value- the exact ratio, only read whentypeiscustom.seed- makes "random" reproducible. Same seed, same ratio, forever.
Installing SP-Nodes
Through ComfyUI Manager: search "SP-Nodes" (or the full name, ComfyUI-SP-Nodes), install, restart. By hand: drop into your custom_nodes folder -
cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes
- then restart ComfyUI. Nothing about this particular node needs a model download or an extra Python dependency; it's pure arithmetic on a couple of floats.
Where people get tripped up
If you paste in a workflow that uses this node before you've installed the pack, you'll get ComfyUI's standard red "missing node type" box - install SP-Nodes first (or use Manager's "install missing custom nodes" on the workflow), then restart.
The more common confusion is thinking this node is broken because nothing happens when you run it. It's a data node, not a generation node - running the graph will produce a number, not an image, and that number only matters once it reaches whatever merge node consumes GM_LABEL_EMB. If you're trying to merge SD1.5 checkpoints and wondering why the label_emb ratio doesn't seem to change anything, that tracks: SD1.5's label_emb is typically a no-op unless the checkpoint is class-conditional, which almost none in the wild are. Save the fiddling for SDXL merges.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| seed | INT | 00–18446744073709550000 | — |
| min | FLOAT | 0.00–1 | — |
| max | FLOAT | 1.00–1 | — |
| type | COMBO | 2 options: custom, random | |
| custom_value | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| GM_LABEL_EMB | GM_LABEL_EMB | — |