CMK Pipe Set Sampler

If you have ever wired the same eleven values - model, clip, vae, two conditionings, latent, steps, cfg, sampler, scheduler, seed - across a graph and then had to do it again for the second sampler, you already know why this node exists. CMK Pipe Set Sampler takes all of them as real sockets and returns one CMK_PIPE. After it, the sampler module downstream only needs one wire.

That is the context-bus pattern, and it is old news in ComfyUI: Efficiency Nodes did it with the Dependencies tuple out of Efficient Loader, Easy-Use threads a pipe dict through its whole line, rgthree has Context. What every one of them buys you is legibility, and what every one of them costs you is the same thing - a wire that hides which version of each value is inside it. Keep that in mind and this node is a joy. Forget it and you will spend an hour wondering why your new prompt did nothing.

What it actually does

Feed it the required sockets and it writes a dict back out under keys the CMK sampler module reads by name: model, clip, vae, conditioning_pos, conditioning_neg, latent_image, latent_original, steps_1st_pass, steps, cfg, sampler, scheduler, seed.

Two details in there are worth more than the rest.

Clean model and patched model are stored separately. model_patched is an optional input, and when you connect it the pipe keeps both: model stays your clean checkpoint and model_patched holds the model that has, say, a LoRA or a sampler-side patch applied. Downstream nodes can then deliberately pick. Without that split, anything that patches the model for a sampler leaks the patch into every later consumer on the same bus - the classic stale-context bug you get with these bundle designs.

There is a smart ControlNet step baked in. The optional opt_control_net and opt_controlnet_image inputs get run through core's ControlNetApplyAdvanced inside this node, and the applied conditioning is what lands in the pipe. If either optional input is missing - or the vae or conditioning isn't there yet, or the end percent isn't after the start percent - it does not error. It quietly bypasses, sets boolean_controlnet_enable to false, and writes the reason into controlnet_log. So yes: a ControlNet that "isn't doing anything" is usually a ControlNet that bypassed, and the log tells you which of those reasons it was. Note the applied range is baked in at strength 1.0 across the full 0–100% step range; this node has no percent dials. If you want to tune how long ControlNet guides, that happens upstream in a ControlNet prepare node, not here.

Output: one pipe. It plugs into the sampler execute node of the 10 KSampler module, or anywhere else on the CMK pipe line that expects sampler context.

Installing the pack

ComfyUI Manager → search CMK Flow → install the entry by CMKFlow → restart. The registry package name is cmk-flow; the folder it lands in doesn't matter to the pack.

Manual route, from the folder holding main.py:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

You want to see CMK dependency check: OK at the end. That helper finds the Python ComfyUI is actually running - which matters on Desktop installs where system Python, standalone-env and .venv all sit side by side - and installs requirements.txt there. Python deps only; model weights are deliberately not bundled. Updates are git -C custom_nodes/cmk_nodes pull --ff-only followed by the same install script, because a git clone never runs pip for you.

Two things about this pack that bite people: it wants Vue Nodes / Nodes 2.0 enabled in ComfyUI settings (without it, dynamic CMK nodes fall back to old LiteGraph rendering and the advanced widgets don't behave), and this node family lives under CMK/Developer/. Developer nodes are the pack's internal infrastructure - they are not in the Flow Browser catalogue and the author's own docs treat them as not-for-general-use. You will find them by searching CMK Pipe in the node menu, not by browsing.

Where it goes wrong

The failure mode is architectural, not technical. Anything you change after this node runs is invisible downstream until you re-run this node, because the pipe snapshot was taken here. If you edit a prompt, re-encode it and feed the new conditioning in, don't expect the pipe you built ten minutes ago to notice.

Second: seed on this node is a normal integer widget with the usual control_after_generate behaviour. The control fires after the run by default, so the number in the box is the next seed, not the one that made the image you're looking at. ComfyUI's global "widget control mode → Before" setting fixes that once for your whole install, and it is worth doing.

Third: because the ControlNet bypass is silent by design, wire boolean_controlnet_enable or controlnet_log somewhere visible when you're debugging a ControlNet chain for the first time. Reading the log beats guessing.