The purpose of a wire loom (also known as a wire sleeve) is to organize, bundle, and protect wires. It can declutter your workflow, but also makes subgraphs more useful for creating custom interfaces.

What are the advantages of these over Set/Get Nodes? There is a lot of overlap but looms are conceptually more of a stream, where you can take something out, modify it and put it back in, things down stream get the modified version.

Status
Detailed Explanation
Simple Tutorial
Gallery and Demos

Status

It's completely functional but needs some optimization, and possibly bug fixes, design changes.

Nodes 2.0 has bugs that make using loom nodes a little harder, for example if you try to move a node by clicking and dragging the arrow icon, Nodes 2.0 will also toggle node collapse, something that doesn't happen in the original node system. I have created a work around for that issue.

Detailed Description

There are multiple ways to organize nodes but let's say we want to organize our nodes such we group our prompts, image resolution, batch, and seed control. Another group for model related settings. And finally nodes for conditioning and sampling. You would end up with something like this:

If you tried to make that into subgraphs you would end up with this:

If you use looms your graph will look like this:

And if convert your groups into subgraphs and connect up the widgets you can end up with this:

To take that a step further you could use the same prompt subgraph to go through multiple model/sampler subgraphs:

The basic nodes are:

Loom In - inserts any kind of wire into the loom.
Loom Out - gets any kind of wire in the loom.
Loom Join - joins two looms, the second loom will override conflicting wires.
Loom Split - a layout node, that allows wires to go out in multiple directions.

There are type specific nodes that prepend the type to the label to avoid name collisions, like nodes for the IMAGE type is named Loom Image In and Loom Image Out, and if a label is not provided it will automatically use "IMAGE" and if a label is provided like "image2" it will stored/retreived in the loom as "IMAGE_image2". The supported types are MODEL, CLIP, VAE, CONDITIONING, IMAGE, AUDIO, LATENT, SAMPLER, SIGMAS, NOISE.

And yes, you can have looms inside of looms! Like if you wanted a different model for upscaling, you can have it in a separate loom to avoid name collisions and then put that inside of your main loom, and pull it out when your sampler wants to upscale.

Simple Tutorial

I recommend starting off by placing Loom Split nodes and linking them together (tip: holding alt-key and click dragging automatically clones a node):

And then collapse the Loom Split nodes by hitting their upper-left arrows, and adjusting them to create straight lines (tip: enabling snap mode makes that easier):

Now you can drag node input and output slots onto the loom and it will automatically create an appropriate loom nodes collapsed. For example Load Image and Preview Image can be attached and you can run them and they should just work.

This will work for MODEL, CLIP, VAE, CONDITIONING, IMAGE, AUDIO, LATENT, SAMPLER, SIGMAS, NOISE, for other kinds of slots and widgets it defaults to a generic loom node requiring labels.

If you needed to add a second image, you would need to uncollapse the nodes and change their labels:

In regard to labels, if you rename the widgets (a right click menu option) of primtive nodes Int, Float, or Text String (Multiline), it will automatically take the widget name as the label when first attaching their output to the loom (note: it doesn't update after it's been attached). So for example renaming a Float nodes widget to cfg by right clicking it:

Attaching the Float node output would then automatically use the widgets new name as it's label when first created. Also nodes with widgets, like CFG Guider for example, will automatically take the widget label when connected to the loom: