JLC Multi Set

JLC Multi Set is the publishing side of a wireless channel. Plug any value into one of its rows - a conditioning, a reference image, a seed integer, whatever - give the row a name, and a JLC Multi Get elsewhere in the workflow pulls that same value out without you drawing the connection. It's the "Set" half of the classic KJNodes Set/Get pattern, compressed into one node that holds up to 24 named channels instead of one node per value.

You reach for it in exactly the situation that makes people install rgthree and then still grumble: a large, multi-stage workflow where the same thing needs to be consumed in two far corners. A Flux ControlNet-heavy graph is the poster child - reference images, masks, and conditioning that all need to reach a sampler that lives a screen away. Instead of dragging threads across the canvas or nesting reroutes, the producer just writes to a channel.

How it works

Like its Get sibling, JLC Multi Set is a frontend virtual node. The backend function is a plain passthrough that returns what it's given - the node never stores anything. All the magic is in web/jlc_dynamic_multi_set_get.js, which resolves connected consumers to the real upstream graph link before prompt submission. There is no runtime value registry, which is the design choice that separates this from the older "wireless" extensions the community soured on: those kept global in-memory values, could serve you last run's state, and broke workflows in confusing ways. Here, by execution time, the "wire" is a real link. No stale state, no execution-order coupling, and if the frontend extension fails to resolve, the stub raises a loud error instead of quietly handing you nothing.

Inputs, outputs, and the row mechanics that matter

Each row takes an optional value_1 (wildcard * - it carries any ComfyUI type, and rows can mix types freely in one node) and passes it through to a matching output. The node starts with one visible row and grows: connect the last available row and a new one appears, up to 24 channels. Disconnecting a used row removes it when safe and compacts the survivors while keeping their identities.

A few behaviors worth knowing before you build a workflow on it:

• Unnamed Set rows get default names like channel_1, and those names stay editable.
• Get rows bind to the Set row's identity, not the name string - rename a Set channel and any Gets pointed at it follow.
• The compatibility is one-way: JLC Multi Get can read KJNodes SetNode channels, but a KJ GetNode cannot read JLC Multi Set rows. Don't mix the reverse direction.

Install

Part of the jlc-comfyui-nodes pack (J. L. Córdova, MIT). ComfyUI Manager has it as "jlc-comfyui-nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Damkohler/jlc-comfyui-nodes.git

Restart ComfyUI after. No requirements.txt, no models to download - the pack is pure ComfyUI core plus its frontend JS.

Troubleshooting

• "JLC Multi Set is a frontend virtual node. Its web extension did not resolve this node" - the JS didn't load, so nothing resolved. Restart ComfyUI and confirm the web/ directory is intact next to the nodes.
• Gets come back empty - the Set row has no connected source, or the channel name on the Get side doesn't match a connected Set. Check the row actually has an upstream value.
• Remember it's a passthrough - the node adds nothing on its own. If you wire a Set and see no effect, that's correct; the value only travels once a Get resolves it.

For a workflow that's outgrown the screen, replacing a row of individual Set/Get nodes with one Multi Set is a genuine quality-of-life upgrade. It won't generate anything, but it will make the graph you actually think in readable again.