EmAySee Morph Pipe In

EmAySee Morph Pipe In collects twenty float sliders and bundles them into a single custom MORPH_PIPE wire. It's a bookkeeping node, not a computation node: the values go in, nothing is transformed, and one tidy pipe comes out. Its partner, EmAySee_MorphPipeOut, unpacks the pipe back into twenty separate FLOAT outputs on the far side of your graph.

The point is graph hygiene. This pack's author clearly builds body-morphing workflows where a bunch of LoRA-strength sliders - Breast Size, Waist Size, Butt Size, Thigh Size, Body Type, and so on - need to travel from your control panel to wherever they get consumed, possibly across a batch or a sub-workflow. Running twenty individual wires across a busy graph is how you lose your mind; running one pipe wire is how you keep it. Same idea as the Context/pipe nodes in packs like rgthree, just scoped to one very specific set of sliders.

The slider set is opinionated, and you should know that going in: it's a fixed list of twenty labels (Breast Size, Breast Sag, Areola Size, Puffies, Belly Fat, Waist Size, Butt Size, Thigh Size, Thigh Spacing, Body Type, Pregnant, PHP, plus Extra 01–08). All default to 0.0 and range from −2.0 to 3.0 in 0.01 steps - so you've got headroom for "reduce" and "increase" both directions. There's no way to rename or reorder the fixed labels; the eight "Extra" slots are your escape hatch for anything the named ones don't cover.

The inputs that matter

You don't set any of these blindly - the whole node is twenty sliders:

• Breast Size through PHP - the twelve named sliders.
• Extra 01 through Extra 08 - eight spare sliders for anything else.

Each is a FLOAT from −2 to 3, default 0. If a slider is at 0, it's neutral; positive and negative values push whatever the consuming workflow does with them. Since this node just bundles, the real meaning of each value lives downstream - in your prompt-construction or LoRA-strength logic.

How it works

The implementation is literally a dict: all twenty values get packed into a dictionary, and that dict travels down the MORPH_PIPE wire. There's no math, no type conversion. The only thing to internalize is that MORPH_PIPE is a custom type only this pack understands - you must unpack it with EmAySee_MorphPipeOut. You can't wire a Morph Pipe into an arbitrary node expecting floats, and there's no third party that knows this type. Pipe in, pipe out, same workflow.

Installing it

Part of the EmAySee pack:

# ComfyUI Manager: search "ComfyUI_EmAySee_CustomNodes" and install
# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes

Restart ComfyUI. No extra dependencies - this is pure Python, no torch even needed for the bundling itself.

Common issues

The one real trap is the custom pipe type. If you copy a workflow fragment that uses MORPH_PIPE into another workflow without also copying both ends, or if you try to repurpose the pipe for something the pack doesn't expect, you'll get type errors - the pipe only round-trips through these two nodes. Also, since the labels are fixed, workflow files from other authors won't share this pipe type unless they also installed this pack. If your graph keeps the sliders local to one area, you might genuinely not need the pipe at all - but for keeping a 20-slider control panel tidy, it does its one job.