Derp Router

Derp Router is the node the whole xcp_derp-UI pack quietly depends on. Every derp loader and controller - VAE Loader, Model Loader, Trigger Wall, Slider - communicates by broadcasting wireless signals, and this is the junction box that catches them and hands them to your real nodes. The pack's docs call it the "central nervous system" and are blunt about the consequence: without a Router in the workflow, all those loaders are just very confident paperweights. Add it first. Always.

It's the management node of a small, opinionated UI-framework pack by lordwedggie. Its premise: big ComfyUI graphs get unreadable, so it makes data transfer wireless and lets you tuck workhorse nodes a mile away. It's the rgthree problem - reroutes, group muters - solved by removing wires, and Router is the engine of that.

How the routing actually happens

This one is a two-layer system with a reconstruction engine underneath:

1. In the browser, every derp node registers its current value in a global signal registry, keyed by node ID (and a :0 port suffix for typed outputs).
2. The Router's frontend scans that registry, shows you every detected signal, and packs the ones you added into a JSON blob (signals plus activeOutputIds) that becomes its signal_data input.
3. On the backend, broadcast_signals() parses that JSON and resolves each signal: a live physical wire if one's connected, a live registry fallback, then a reconstruction engine that rebuilds real MODEL, CLIP, VAE, IMAGE, LATENT objects from small descriptors. That's where "extract VAE from checkpoint" lives - the Router does the loading the loaders pretend to do.

If a complex signal can't be resolved it raises a clear error - "Could not resolve VAE signal for 'name'" - instead of silently passing None. It's a lot of machinery, but the user-facing behavior is simple: pick signals, wire outputs, go.

The inputs and outputs

The schema looks intimidating; the behavior's simple:

• signal_data (STRING, multiline) - the JSON package. Don't hand-edit it; the frontend writes it, and it's how the workflow reloads with your routing intact.
• 16 hidden _hidden_wire_0..15 inputs - each accepts any type. They're physical-wire overrides: a hard connection beats the wireless value for that slot.
• 16 * outputs - the ones that matter. They're named with a zero-width space so they render as clean unlabeled sockets, and each is dynamically typed to the signal you assigned it: a Trigger Wall string plugs straight into CLIPTextEncode's text input, a VAE slot goes to VAEDecode's vae input, a MODEL slot feeds a sampler. The pack's own example does exactly this - one Router feeds the sampler and guidance nodes, another feeds both text encoders and the VAE decode.

The UI on top does the real configuration: a searchable detected-signals list, an add-signals dropdown, drag-to-reorder outputs, a refresh button, a "warp to node" click that teleports your canvas to the broadcaster, and an orphan animation for signals from deleted nodes. System-panel toggles show signal IDs, slot names, slot types, and virtual links.

Putting it in a workflow

Derp Vae Loader ──┐
Derp Model Loader ┼── wireless ──> Derp Router ──> KSampler / VAEDecode / CLIPTextEncode
Derp Trigger Wall ┘

Add the Router first, refresh, add signals from the dropdown, drag to order, wire the outputs to your real nodes. Order matters: when a node receives several signals, position decides which slot is which. New node later? Just refresh the registry.

Installing it

Via ComfyUI Manager (search "xcp_derp-UI" or "Derp"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/lordwedggie/xcp_derp-UI-Release

Restart. No requirements.txt, no pip installs, no model downloads - it runs on ComfyUI's own core modules. It targets both the legacy canvas and Nodes 2.0, but it's a fast-moving indie project with basically no community footprint.

Where people get burned

• "Why is my loader a paperweight?" - no Router, or the Router wasn't refreshed after you added the loader. Refresh the registry and re-add the signal.
• Queue-time resolution errors - the signal names a file that isn't in the folder anymore, or a deleted node left an orphan signal (it's the one pulsing). Clean those up; they're the top source of "this worked yesterday."
• Wrong slot wired - with two nodes sharing a name, enable Show Signal IDs in the system panel; the IDs are the only thing distinguishing them.
• The untyped-router tradeoff. This is the same class of node as "anything anywhere" routing, which the community has argued about - invisible routing is convenient until it isn't, because there's no red wire to follow when something breaks. Router softens that with clear resolution errors and warp-to-node, but the honest advice: use it for a few controllers feeding a stable core, not to hide a graph you don't understand.