AD_LTX_sampler
The actual sampling step for Apt_Preset's LTX pipeline
- model
- positive
- negative
- img_latent
- img_vae
- audio_latent
- audio_vae
- sampler
- sigmas
- model
- crop_positive
- crop_negative
- crop_img_latent
- img_vae
- audio_latent
- audio_VAE
- frame_rate
This is where the actual diffusion happens in Apt_Preset's LTX_video chain - everything upstream (AD_LTX_load_model, AD_LTX_config, optionally AD_LTX_IC_lora) is setup, and everything downstream (AD_LTX_vae_combine) is decode. This node runs the sampling loop that turns your conditioning and empty latents into an actual generated video (and audio, if you fed it any).
Notice it takes sampler (SAMPLER) and sigmas (SIGMAS) as inputs rather than the familiar sampler_name/scheduler dropdown strings from the stock KSampler. That's the "advanced sampling" pattern - you build those two objects upstream with something like a KSamplerSelect node and a scheduler node (BasicScheduler or similar), which gives you more control over the noise schedule than the simple KSampler exposes.
The inputs and outputs that matter
model,positive,negative,img_latent- the standard sampling quartet, sourced from your LTX config chain (withpositive/negativeoptionally passed throughAD_LTX_IC_lorafirst if you're using a control LoRA).seed- your usual seed control.cfg(default 1, range 0–100) - the default of 1 is telling: LTX's distilled checkpoints are meant to run at CFG 1 with no classifier-free guidance overhead, which is the whole point of a distilled model. Push this higher if you're running a non-distilled ("dev") LTX checkpoint, which needs more steps and actual CFG to behave.frame_rate(default 24, range 4–120) - the render frame rate for this sampling pass.img_vae,audio_latent,audio_vae- carried through from the config so the sampler has what it needs for the audio side too.sampler(SAMPLER) andsigmas(SIGMAS) - your noise-schedule objects, built upstream.
Outputs are prefixed crop_ for the conditioning and latent - crop_positive, crop_negative, crop_img_latent - which points at the sampler internally trimming the result to the valid frame window before handing it downstream, rather than leaving any grid-padding frames in there for you to deal with manually. Also outputs model (pass-through), img_vae, audio_latent, audio_VAE, and frame_rate (INT) so the whole bundle is ready to feed straight into AD_LTX_vae_combine.
How to install it
Via ComfyUI Manager: search "ComfyUI-Apt_Preset". Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git
Then install.bat (Windows) or pip install -r requirements.txt (Linux/Mac), and restart. No extra model files for this node itself - it consumes whatever AD_LTX_load_model already loaded. You do need a valid sampler/sigmas pair from standard ComfyUI sampling-utility nodes wired in upstream, since this node doesn't build those for you.
Common issues & troubleshooting
Output looks static or barely moving. This is the single most-reported LTX complaint in the wider community - weak motion, especially on image-to-video. If you're on an older LTX-2 checkpoint rather than LTX-2.3, that's a known, largely-fixed issue on the newer release; upgrading your checkpoint is worth more than fiddling with cfg here.
CFG at 1 and results ignore your negative prompt. That's expected and correct for a distilled checkpoint - CFG 1 means no classifier-free guidance path exists for the negative to act through. If you need negative-prompt control, you're either on the wrong checkpoint type (switch to a non-distilled "dev" LTX model and raise cfg) or you need a guidance-patching node designed for CFG-1 workflows.
Nothing connected to sampler or sigmas. These aren't optional - build them with the usual advanced-sampling utility nodes (a sampler-select node feeding sampler, a scheduler node feeding sigmas) before wiring them in here.
Slow generation. LTX's whole selling point is speed relative to Wan, especially on distilled checkpoints at low step counts - if it's crawling, check you're actually on a distilled model and a small step count via your sigmas source, not a full 20-40 step "dev" schedule.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| img_latent | LATENT | — | |
| seed | INT | 00–18446744073709550000 | — |
| cfg | FLOAT | 1.00–100 | — |
| frame_rate | INT | 244–120 | — |
| img_vae | VAE | — | |
| audio_latent | LATENT | — | |
| audio_vae | VAE | — | |
| sampler | SAMPLER | — | |
| sigmas | SIGMAS | — |
Outputs (8)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| crop_positive | CONDITIONING | — |
| crop_negative | CONDITIONING | — |
| crop_img_latent | LATENT | — |
| img_vae | VAE | — |
| audio_latent | LATENT | — |
| audio_VAE | VAE | — |
| frame_rate | INT | — |