Set Mute State

Set Mute State does one weird, specific thing: while a graph is running, it reaches over to another node and flips it muted or active. That's it. If you're here because a tutorial dropped it into a workflow and never explained why, the short version is that this is a loop-building node, and it makes almost no sense on its own. It only earns its keep as part of Impact Pack's little suite of experimental "logic" nodes for building auto-queuing loops.

Here's the pattern it belongs to. ComfyUI normally runs a graph once and stops. Impact Pack ships a handful of nodes (Queue Trigger, ImpactInt, ImpactCompare, ImpactConditionalBranch, Set Widget Value, and this one) that let you fake iteration: the graph re-queues itself, a counter ticks, a comparison decides whether to keep going, and along the way you mutate the graph's own state between passes. Muting a node is one of those mutations. Maybe you want a heavy upscale branch to sit dormant for the first N iterations and switch on for the last one. Set Mute State is how you throw that switch without touching the mouse.

What it actually takes

Three inputs, and only two you think about. node_id is the numeric ID of the node you want to mute - you find it by turning on node ID badges in ComfyUI-Manager (the Badge: #ID Nickname display), then reading the number off the node you're targeting. set_state is the boolean: true mutes it, false wakes it up. The third input, signal, is a wildcard passthrough - you feed anything through it, and it comes back out unchanged as signal_opt. That signal isn't data the node uses; it's a scheduling handle. It's how you force this node to run after something else, because in a graph with no data dependency there's no other way to say "do this last."

And "do this last" is the whole game. This is an output node, and the pack's own docs are blunt that state-changing nodes like this must sit at the very end of the workflow. If Set Mute State fires before the nodes it's meant to gate have run, you've muted them for the pass they were supposed to work in. So you chain the signal from the last real output back into it, guaranteeing it runs after everything that matters.

Where people get burned

The documented limitation is the one to memorize: this stuff does not behave with a batch count above 1. The loop machinery assumes one prompt per queue entry, and cranking the batch count breaks the assumption. Keep batch at 1 and drive repetition through the queue instead.

The other trap is subtler and it's about ordering, again. If you randomize a seed somewhere, or another state-changer runs before this node, the mute can land against a stale view of the graph. The fix is discipline: put every state-mutating node (Set Mute, Set Widget Value, Queue Trigger) at the tail end, wired through signal so their order is explicit and not left to chance.

Honestly, this is fiddly, undocumented-by-example territory - it lives in a category literally named _for_test. If you just want to skip a branch on a normal single run, don't reach for this; bypass the node by hand, or use a proper Switch node. Set Mute State is for the narrow case where the workflow itself has to decide, mid-loop, what runs next.

Installing it

Set Mute State comes with the whole Impact Pack, so you don't install it separately. Easiest route: open ComfyUI-Manager, search ComfyUI Impact Pack, hit Install, restart. Manual works too - cd ComfyUI/custom_nodes, git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack, then install its requirements.txt in the same Python environment ComfyUI runs in (for the portable build that's ..\..\..\python_embeded\python.exe -m pip install -r requirements.txt), and restart. Since v7.6 there's no more silent auto-install, so if you clone by hand, run the requirements step or the pack won't load. Impact Pack is by ltdrdata, the same maintainer behind ComfyUI-Manager, so it's about as load-bearing and well-kept as custom nodes get - but these logic nodes are the experimental corner of it, so expect to wire things a couple of times before it clicks.