PC: Text Encode (no scheduling)

Every fancier node in this pack - PCLazyTextEncode, PromptControlSimple, the multi-pass Advanced variants - is generating a graph that ultimately calls this node underneath. The README says it plainly: "This is what actually does most of the work under the hood." If you don't need prompt scheduling (no [cat:dog:0.5] timing tricks) but you do want everything else this pack brings to text encoding, PCTextEncode is a straight drop-in replacement for ComfyUI's stock CLIPTextEncode.

What "everything else" actually means

This is where the A1111-era prompt-engineering toolkit lives: multiple weight-interpretation styles (ComfyUI-native, A1111's (word:1.3), compel, and others), the prompt combinators - BREAK to force a hard split, CAT/AVG()/AND mapping to ComfyUI's ConditioningConcat/ConditioningAverage/ConditioningCombine - per-encoder prompts for dual-encoder models like SDXL and Flux, and IMASK() for referencing masks attached via PCAddMaskToCLIP for regional/cutoff-style prompting. It's the whole CLIP-era prompting vocabulary, condensed into one node's text field instead of a dozen conditioning nodes.

Worth knowing before you build around it: that entire vocabulary is CLIP-specific. It does real work on SD1.5, SDXL, and the CLIP-L slot of Flux. On a fully LLM-encoded model - Z-Image, Anima, Flux 2 Klein - weight syntax like (word:1.3) gets fed to the encoder as literal punctuation rather than interpreted, which is worse than leaving it out. BREAK and AND are dead weight there too, since there's no 77-token CLIP chunk boundary to break against and multi-subject adherence is handled natively by the LLM encoder instead. This node is squarely a CLIP-model tool.

Inputs and outputs

Required: clip and text - a single static prompt (no schedule syntax). Output: CONDITIONING, wired into your sampler exactly like CLIPTextEncode's output.

The one thing worth flagging explicitly, because it bites people migrating a LoRA-tagged prompt over: this node does not ignore <lora:name:weight> tags - it treats them as literal prompt text rather than stripping them out. If you want a single block of text to carry both LoRA instructions and your actual prompt, that combo is PCLazyTextEncode paired with PCLazyLoraLoader, not PCTextEncode alone.

Installing it

ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control

No model downloads for this node - it's a graph-generation and prompt-parsing layer over your existing CLIP.

Where people get tripped up

Beyond the LoRA-tag gotcha above, the most common trap is expecting scheduling from this node - it explicitly doesn't do that, and the README is clear on the split: reach for PCLazyTextEncode the moment you want [a:b:0.5]-style timing. Second, watch weight stacking: (((important)))-style compounding still produces artifacts here even where the weight syntax works, same as it always has in A1111 - (word:1.4) is the more controlled way to write the same intent. And if a combinator like AND or CAT doesn't seem to be doing what you expect, double check you're actually on a CLIP-conditioned model - on an LLM-encoded checkpoint those tools are inert by design, not broken.