PC: Text Encode with Range (no scheduling)

This is a small efficiency node, and the pack's own description says exactly what it's for: "Like PCTextEncode, but if you know the range you need for a prompt, can be slightly more efficient when you have LoRAs scheduled on a CLIP model." It's not a headline node - it's the kind of thing you reach for once you're deep enough into this pack to have LoRA hooks scheduled and you're optimizing.

What it does and why the range matters

When you schedule LoRAs with PCLazyLoraLoader, Prompt Control attaches hooks to your CLIP model via ComfyUI's built-in hook system - different LoRA weights active over different timestep windows. Every time something downstream encodes text with that hooked CLIP, ComfyUI has to work out which hooks are actually active for the timestep range that encode covers. If you already know a given text encode is only ever going to matter for, say, steps 0.3 through 0.7 of the run, telling the node that range up front means it doesn't have to figure out or apply hook logic outside that window - a small saving, but a real one on a graph doing a lot of encodes with a busy LoRA schedule.

Like plain PCTextEncode, this node does not support scheduling syntax in the prompt itself (no [cat:dog:0.5]) - it's a single static encode for one known window. It's not a scheduling node; it's an efficiency variant of the non-scheduling one.

Inputs and outputs

Required: clip and text (a static prompt, no schedule syntax expected). Optional: start and end, both 0–1, defaulting to the full range (0 and 1) - the timestep window this encode is valid for. One output, CONDITIONING, wired into your sampler like any text encode.

Installing it

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

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

Nothing to download beyond the pack itself - this is pure graph/hook logic, no models.

Where people get tripped up

The most common mistake is reaching for this node when you don't actually have LoRAs scheduled on your CLIP. If there's no hook system in play, start/end here has nothing to optimize against, and you've just added a field to configure for no benefit - plain PCTextEncode does the same job with one less thing to think about. Save this one for graphs that are already using PCLazyLoraLoader's scheduling and where you've profiled enough to know a static-window encode is worth the extra precision.

Also worth remembering: like PCTextEncode, this node doesn't strip <lora:name:weight> syntax out of your text - it'll treat it as literal prompt content. If you want LoRA tags parsed out of a combined prompt, that's PCLazyLoraLoader's job, not this node's.