h4 - Traffic Merge (Zipper)

This is the node at the center of h4_Live's flagship pattern: the wireless loop. H4_TrafficMerge sits right before your KSampler and acts like a zipper - on run 0 it lets your initial data (an empty latent, say) through; on run 1+ it zips that shut and feeds in the previous result instead. It also auto-switches the denoise value to match: full strength to create, lower strength to refine. One run to hallucinate, then a loop of gentle passes to evolve the image. That's the whole "make workflows feel like processes instead of one-shot vending machines" idea the pack is built on.

The one thing you must internalize before touching it: you do not wire the loop back to this node directly. ComfyUI's graph is a directed pipeline - no true cycles - and the node's own warning is blunt: wiring loop_input straight from a later node causes a Cycle Error. The intended path is the pack's wireless buffer trick.

How it works

• Run 0: it passes run_once_input through and emits first_denoise (default 1.0 - create from scratch).
• Run 1+: it looks for loop_input; if that's empty, it goes "wireless" and pulls the previous result from the pack's in-memory image buffer (fed by H4_ImageBuffer, which sits at the end of your generation block). It emits loop_denoise (default 0.45) instead.

So the classic graph is: H4_TrafficMerge → KSampler → ... → H4_ImageBuffer, with the merge's loop_input left empty. The buffer catches each generation's output and the merge "phones" it on the next run. No giant feedback wire, no cycle.

There's also a type-safety guard worth appreciating: on run 0 it remembers what type of data came in (latent vs image), and on later runs it refuses to route data of a different type, raising a clear "TYPE MISMATCH" error instead of letting a wrong-typed tensor crash your sampler somewhere confusing.

The inputs that matter

• first_denoise (float, default 1.0) - denoise for run 0.
• loop_denoise (float, default 0.45) - denoise for runs 1+.
• restart_on_true (boolean, default OFF) - OFF keeps looping (counter increments); ON resets to run 0.
• run_once_input (*) - the start data (empty latent, first image).
• loop_input (*) - leave it empty; that's the wireless mode. Wiring it triggers the Cycle Error.

Outputs: Selected_Output (*) - the data to feed your sampler - and Denoise_Val (float) - wire that into the sampler's denoise so it follows the run count automatically.

Installing h4_Live

One install gets the whole pack. ComfyUI Manager: search h4_Live, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/m3rr/h4_Live

Restart. No model files, no pip extras. It's an actively-developed one-person pack, so expect updates to shift behavior - and understand this corner of the ecosystem is young: there's essentially zero Reddit history on these loop nodes yet, so the pack's own examples folder (01_Simple_Wireless_Loop) is your best documentation.

Common issues

• Cycle Error when you wire the loop. The #1 footgun, and the node screams about it in its own description. Leave loop_input empty and use H4_ImageBuffer. The pack's own example workflow does exactly this.
• Forgetting the buffer, or buffering the wrong type. If the buffer is empty or holds the wrong kind of data, you get the type-mismatch error or a "wireless buffer is EMPTY" log. If run 0 is a latent, the buffer must capture a latent, not an image.
• One global counter for all loops. Every h4 traffic node shares the same run counter, so two loops in one workflow collide. One loop per workflow, or accept the interference.
• "Looping" here means re-queueing. Nothing runs by itself; you press Queue and each execution is the next run. If you expect the graph to iterate internally in a single press, that's not what this does.