TextToConditioningLite

TextToConditioningLite is what you drop in place of a CLIP Text Encode pair when you're using the preset hub. It takes the positive and negative prompt strings straight off LoadSetParametersLite and turns them into the conditioning your KSampler needs - and while it's at it, it also applies any LoRAs you wrote into the prompt as <lora:name:strength> tags.

The wiring is simple: model, clip, positive_prompt_text, negative_prompt_text, and seed go in; model, clip, conditioning_positive, and conditioning_negative come out. The model and clip pass through unchanged unless a LoRA tag is present - the idea is you can chain this node after a LoRA loader, or let it handle LoRAs entirely on its own.

Under the hood it does three things in one pass. It extracts <lora:...> tags from the positive text and loads those LoRAs (the same extraction logic the pack's dedicated LoRA loader nodes use). It tokenizes and encodes both prompts while keeping the pooled output - that matters for SDXL-style models, which need the pooled vector alongside the regular conditioning to behave. And it hands you standard CONDITIONING outputs that plug straight into the KSampler's positive and negative sockets. One node in, two conditioning wires out, no text-encode pair needed.

The honest gotcha: the negative prompt passes through as-is, with no LoRA extraction on that side. LoRA tags belong in the positive prompt, full stop. Also, seed only matters if you use the pack's random-vector LoRA syntax (<lora:name:1:lbw=R> and friends) - the seed drives those random ratios, which is why the node asks for it even though plain prompt encoding never touches it.

Is it worth it outside the pack? The <lora:> tag handling is genuinely handy - typing LoRA tags into your prompt is a common ComfyUI convention that usually needs a separate helper node, and this bakes it into encoding. But for a plain workflow, a stock CLIP Text Encode plus a normal LoRA loader is fewer concepts to hold in your head. This node earns its keep when the prompt text is being swapped by presets, because it makes "a prompt with LoRA tags" a first-class citizen of the whole switching system - swap the preset, and the LoRAs it names get loaded automatically.

Install via ComfyUI Manager (search "ComfyUI_mittimiLoadPresetLite") or clone https://github.com/mittimi/ComfyUI_mittimiLoadPresetLite into custom_nodes and restart. The only dependency is toml, and there's a known quirk if you also run RES4LYF - the README's three-line init.py patch fixes the scheduler conflict.