LZ Dual CLIP Text Encode

Every vanilla workflow has the same two-box ritual: a CLIP Text Encode for the positive, a second CLIP Text Encode for the negative, both hanging off the same CLIP. LZ Dual CLIP Text Encode collapses that into one node with both text boxes and both CONDITIONING outputs, and it adds two text outputs so you can see - and log - exactly what each encoded.

How it works

It's a thin wrapper, which is the right call for this kind of node. Feed it a CLIP, type your positive and negative strings, and it runs the same tokenize-and-encode path ComfyUI's built-in CLIP Text Encode runs - twice. Outputs are:

• positive / negative - the two CONDITIONING tensors, wired to the sampler's matching inputs.
• positive_text / negative_text - the raw strings back out, for logging or for feeding a save node so your PNG metadata and CSV logs carry the actual prompt text.

There's a genuinely useful optional pair hiding in there too: positive_cond and negative_cond. If you connect pre-encoded CONDITIONING to either one, the node skips encoding that side and just passes it through. So you can use this as a hybrid - hand-encoded positive from a fancy prompt-builder node, plain-text negative in the box - and still keep everything in one visual place.

Why you'd bother

It's a graph-decluttering node more than a capability one. Two fewer nodes, one fewer wire to drag, and both prompt strings available as outputs for the logging chain (the LZNodes pack is big on that - LZAppendLogToCSV and LZSaveImageAndLog both want the text). It also plays nicely with the pack's pipe system: drop its positive/negative outputs into an LZPipePack and you've got a self-contained conditioning bundle.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/liz-ils/ComfyUI-LZNodes

then restart. It shows up under MyCustomNodes/Conditioning. ComfyUI Manager users can search ComfyUI-LZNodes. No extra dependencies - it uses only core ComfyUI CLIP APIs.

Where people get burned

The one trap: if you connect positive_cond or negative_cond, the text box for that side is silently ignored - the node trusts the conditioning you gave it and encodes nothing. That's usually exactly what you want (it's the point of the passthrough), but it means your positive_text output will show the typed text even though the encoded conditioning came from elsewhere. Don't trust the text output as ground truth when you've fed it a pre-encoded conditioning.

Otherwise there's not much to get wrong. If your workflow is one CLIP, two prompts, done - this node replaces two nodes with one and makes your graph a little more legible, which is the quiet currency of the whole LZNodes pack.