IP_Adapter_Settings_Distribution

IP_Adapter_Settings_Distribution is a "settings on a wire" node: you set an IP-adapter weight and a weight type, and it passes both through as outputs instead of making them widgets buried inside an apply node. The point is distribution - the same weight and weight_type can fan out to several IP-adapter steps at once, so your whole style-transfer setup stays in sync from one control point.

It's part of eden_comfy_pipelines, Eden.art's 70+ node suite. It's a pass-through: the source literally returns what you give it. No math, no transforms - it's a structured-constant node.

What you set

• weight - the IP-adapter strength, −1 to 2, default 1.0. Negative weights are a real IP-adapter feature (they push away from the reference); above 1.0 starts to oversaturate the style.
• weight_type - a dropdown with 15 options. This is the same vocabulary the popular IPAdapter Unified Loader uses: linear, ease in, ease out, ease in-out, reverse in-out, weak input, weak output, weak middle, strong middle, style transfer, composition, strong style transfer, style and composition, style transfer precise, composition precise. They control how the weight is applied over the sampling steps - "style transfer" types bias toward keeping the reference's style, "composition" types preserve layout, "strong" variants push harder on the beginning of sampling.

Two outputs, ready to wire:

• weight (FLOAT)
• weight_type (wildcard - plugs into whatever IP-adapter node you're using, since it's just a string underneath).

Why this pattern exists

If you've used IP-adapter at all, you know the settings usually live as widgets on the apply node itself. That's fine for a single use. The trouble starts when you want one strength to control multiple IP-adapter branches - a style reference, a character reference, a composition reference - because now you're editing three widgets to change one decision. This node turns the decision into a single value that distributes everywhere. It also lets you drive the weight from another node - animate it over a sequence, or derive it from a random sampler - which a widget can't do.

The honest framing: this is a pattern node, not a feature node. If you use IP-adapter once per workflow with static settings, it adds nothing. If you're building a moodmix-style workflow with several adapters and a shared look, it's exactly the plumbing you want. The KB's ControlNet essay makes the same point about IP-adapter generally - it conditions on what things look like (style and content) - and a node that lets you tune that influence from one knob fits right into the "style library" workflows this pack is built around.

The one caveat

Because it's a pure pass-through, the node trusts you to pick a weight_type that your IP-adapter node actually supports. The list here mirrors the common IPAdapter Unified Loader types, but if you're mixing node packs, an obscure variant might not match what your apply node expects - at which point you get a type mismatch instead of a graceful fallback. Keep both sides on the same vocabulary.

Installing it

Standard pack install - ComfyUI Manager (search "eden"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/edenartlab/eden_comfy_pipelines.git
cd eden_comfy_pipelines
pip install -r requirements.txt

Restart ComfyUI. It needs no models itself - the IP-adapter models you feed downstream are the real requirement. Zero dependencies beyond the pack, and a good example of why "boring node" and "useful node" aren't mutually exclusive.