👔 AK Garment Mode Controller (1-5)

Virtual try-on is one of the few jobs in this ecosystem that genuinely needs a branching graph. A garment swap on one item is a two-node edit in 2026; a look - top, jacket, trousers, shoes, bag - is a stack of them, and the moment you build five garment paths you have the same boring problem: you want to try three today without deleting the other two, and you don't want to rewire anything to do it.

AK Garment Mode Controller is that switch. You tell it how many garments are in play, and everything tagged for garment 2 and up either runs or doesn't.

How it works

It's a frontend controller, like the pack's tag bypasser and muter, and it uses the same convention: tags in node titles. Put [G2] in the title of every node that belongs to the second garment's path, [G3] on the third, and so on up to [G5]. Then set active_garments to 1 Garment through 5 Garments.

The pack's JavaScript walks the canvas on every change (and again at execution_start, so each queued prompt begins with the state enforced) and applies a simple rule: a node tagged [G2] is active when the count is 2 or more and muted when it's 1; [G3] needs 3; [G4] needs 4; [G5] needs 5. Muting means LiteGraph's mode 2 - the node is skipped entirely, not bypassed. Garment 1 has no tag, and that's by design: the first garment path is always live. Nodes with no garment tag at all - your prompt nodes, your save node, the model loader - are never touched.

Where several controllers disagree about a node, the pack resolves it with a fixed hierarchy: MUTE > BYPASS > ACTIVE. Garment muting wins, which is what you want - a disabled garment branch shouldn't be revived because a generic tag bypasser happens to match the same title.

The inputs and outputs

active_garments is the switch, one of five labels. The node also injects five quick buttons (👉 1 Garment … 👉 5 Garments) that set the value and re-apply the tags in one click - that's how you'll actually use it. There's an optional auto_mute_on_queue boolean beside it; as of v1.0.1 the frontend doesn't read it, since tags are enforced at execution start either way, so treat that toggle as inert for now.

The outputs are garment_count (INT) and active_mode (STRING, the label you picked). Both are worth wiring: garment_count can drive any integer input, and active_mode is a plain string you can concatenate into a prompt - "dress the model in N garments" - so the prompt matches the branches that are actually running.

Using it in a try-on graph

The controller is agnostic about how you're actually doing the try-on. If you're on an instruction editor - Qwen-Image-Edit absorbed garment swaps wholesale, and Flux 2 Klein does "virtual try-on with three reference images, no LoRA" in under fifteen seconds per composite - then a "garment path" is two or three nodes: load the garment reference, join it into the edit prompt, run the edit. Tag those. The older route - masks plus inpainting, or a ControlNet pose stack with an IP-Adapter for the garment - has far more nodes per path, which is where a switch like this earns its keep.

Where people get burned

Mute is a guillotine. A muted node produces nothing, so if garment 3's branch feeds a node you still need - a merge, a second pass, a save - that node is now missing an input and the run skips or errors. This is the most common way the pattern fails: people assume "muted" means "the wires are fine, the node just sits there". It doesn't. Design your garments as parallel branches that converge through a switch or a first-non-null fallback, or keep muted nodes at the leaves.

The tag goes in the title. Double-click the node's title bar and type [G3]. Comment boxes and node types don't count, and the match is a case-insensitive substring test on the title, so [g3] and [G3] both work.

Only the first garment controller is read. If you duplicate the node, the frontend takes the count from the first one it finds in the graph. Keep one and re-use it.

New nodes need a nudge. Tag evaluation happens on widget change, on workflow load, and at execution start. Drop a new tagged node in and then queue - it'll be caught. But if you're staring at a node that looks active when it shouldn't be, change the dropdown or press a quick button to force a re-evaluation.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/AngelosKar-code/ComfyUI-AngelosKar.git
# restart ComfyUI

Or ComfyUI Manager → search ComfyUI-AngelosKar → Install → restart, then hard-refresh the browser so the pack's js/ extension loads and the quick buttons appear. Dependencies are torch, numpy, Pillow, aiohttp, all already in a working ComfyUI install. Python 3.10+. If you run ComfyUI with Nodes 2.0 enabled and the buttons or banners don't show, drop back to the legacy canvas - that's the standard workaround for packs drawn on the old LiteGraph frontend.