SDXL Basic Settings (JPS)

SDXL has more moving generation parameters than most models - resolution buckets, sampler, scheduler, steps, two separate CFG values if you're running a refiner, an aesthetic score, clip skip - and wiring each of those as its own node scatters widgets all over your canvas. SDXL Basic Settings (JPS) is JPS's answer: one node, every one of those settings in a single place, bundled into one output wire that a companion SDXL Basic Settings Pipe node unpacks wherever you actually need the individual values. The README calls it "required for most SDXL workflows," and if you're building anything SDXL-based with this pack, it's the node everything else hangs off of.

How it works

It's a pure settings menu - no image, no model, no conditioning passes through it. You configure every widget, and the node outputs one BASIC_PIPE carrying all of them. Nothing generates here; the actual sampling, encoding, and saving happens in nodes elsewhere that read values off the paired Pipe node.

The inputs that matter

• resolution - a dropdown of SDXL's actual trained aspect-ratio buckets (square 1024×1024, several landscape/portrait ratios) plus "Use Image Resolution." SDXL was trained multi-aspect specifically on these buckets; picking an off-list resolution is a real, common cause of stretched anatomy, and this dropdown exists to keep you on the buckets that actually behave.
• sampler_name / scheduler - the full ComfyUI sampler and scheduler lists. SDXL is a DDPM-style architecture (not the newer flow-matching kind), so the safe default here really is DPM++ 2M with the Karras scheduler, or Euler a on anime finetunes - don't import the "never use Karras" rule that's floating around for Flux-era models; that rule is specific to flow-matching architectures and doesn't apply to SDXL.
• steps_total / base_percentage - total step budget, and how much of it runs on the base model before a refiner would take over. The paired Pipe node actually computes the literal handoff step for you, so you don't do that math by hand. Worth being honest here: SDXL's refiner stage is widely considered skippable by the community at this point - most modern fine-tunes made the second stage unnecessary. If you're not wiring up a separate refiner KSampler, base_percentage is a number this node computes that nothing downstream reads.
• cfg / cfg_rescale - standard CFG, plus the rescale trick for taming oversaturation at higher CFG values.
• clip_skip (default -2) - and that default is correct, not arbitrary. SDXL's own text encoders already condition on the penultimate CLIP layer by design, so -2 is confirming the architecture's own default rather than overriding anything. Wander to -1 or -3 and you're fighting how the model was trained, not tuning it - leave it unless a specific checkpoint or LoRA's page tells you otherwise.
• cfg_refiner / ascore_refiner - refiner-specific CFG and the aesthetic-score conditioning SDXL's refiner was trained with. Only relevant if you're actually running a refiner pass.
• res_factor (1–8) - a multiplier value, meant for pairing with an upscale pass.
• filename (default "JPS") - the prefix that flows through to your save nodes via the Pipe.

Output: sdxl_basic_settings (BASIC_PIPE) - feeds directly into SDXL Basic Settings Pipe (JPS).

How to install it

ComfyUI Manager: search "JPS Custom Nodes for ComfyUI." Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart. No models to download - this is a settings/math node, same as the rest of the pack.

Common issues & troubleshooting

Stretched or distorted output. Check resolution first - make sure it's set to one of SDXL's trained buckets rather than something copied over from another workflow. This node exists specifically to keep you on-bucket, so use the dropdown rather than an "Use Image Resolution" pass-through if you don't have a specific reason to deviate.

Refiner stage not behaving as expected. base_percentage only means anything if you've actually built a two-stage base-then-refiner sampling chain downstream - JPS doesn't enforce that architecture on you, it just outputs the derived step number. If you're single-pass, ignore it.

Confusion over clip_skip. -2 is SDXL's "leave it alone" value, not a special tweak. If a workflow you copied has it set to something else, that was a deliberate (or blindly copied) choice by whoever made it - check a LoRA's model page for its trained clip skip before assuming the default is wrong.