DyPE_Condition

Calling DyPE_Condition a "conditioning" node is the pack's little lie. It doesn't encode text or touch CLIP at all. What it actually does is take the raw transformer that DyPE_Model loaded and wrap it into a working diffusers pipeline - then glue on up to two LoRAs and, if you want it, an IP-Adapter. It's the assembly step. The name just sounds right in a node graph.

Here's the shape of a DyPE workflow: DyPE_Model hands you a bare, unpatched-ish transformer; DyPE_Condition turns it into a FluxPipeline, QwenImagePipeline, ZImagePipeline, or Flux2KleinPipeline (chosen by what model family came in); and it's here, when the pipeline is built, that the DyPE flag gets set. The position-encoding patch is applied to the transformer during loading, but the pipeline is what actually runs it, so this node is the seam where the whole thing becomes usable. Your actual text conditioning - the CLIPTextEncode → prompt embeds - goes straight into the KSampler downstream, not through here.

The node is also where adapters get attached, which is why it takes folder dropdowns rather than tensors. The IP-Adapter support is Flux-1-only and pulls from photomaker (the xflux adapter), with clip-vit-large-patch14 expected in clip_vision for the image side. LoRAs work across families - the README's examples include the flux turbo LoRA (fast low-step generation for Krea) and Qwen-Image-Lightning for Qwen.

The inputs that matter

• model (MODEL) - the output of DyPE_Model. Nothing else will do.
• lora1 / lora2 (from ComfyUI/models/loras) and scale1 / scale2 - up to two LoRAs, each with a strength from 0.01 to 1.0. The dropdown defaults to "none"; leave it there and the pack skips adapter loading entirely. Two slots because the pack is built around the "turbo base + style" pairing - base model for speed, style LoRA for taste.
• ip_adpter (from photomaker) - the IP-Adapter for image-guided generation. Flux 1 only; leave at "none" for everything else.

One output, also called model - the assembled pipeline - which feeds DyPE_KSampler. That's its only destination.

Installing

Same as the rest of the pack: ComfyUI Manager (search "ComfyUI_DyPE") or

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_DyPE
pip install -r requirements.txt

Dependencies include diffusers, transformers, accelerate, sentencepiece, opencv-python, omegaconf; the Klein models want diffusers 0.37+. Restart after installing.

Where people get burned

• The two LoRA slots are additive, not alternative. If you only want one, leave the second at "none" - a "none" in either slot is skipped, but the scale sliders still count if a LoRA is active.
• IP-Adapter silently does nothing on non-Flux models. The README calls this out; the node won't error, it'll just never load the adapter.
• Because this is a diffusers pipeline under the hood, the LoRA handling is diffusers' own (load + set_adapters), not ComfyUI's. LoRAs trained for the stock ComfyUI flux loader usually transfer fine, but if a LoRA loads "successfully" and does nothing, blame the adapter-format mismatch, not your prompt.
• The whole pipeline gets re-instantiated every run, and the pack aggressively flushes ComfyUI's loaded-model cache first. Expect a model re-load tax on each generation - it's the price of the pack being self-contained.

The trap for newcomers is expecting a CLIP input here. There isn't one. Keep this node fed from DyPE_Model and let the KSampler worry about prompts.