Woosh Model Loader

Woosh Model Loader is the first node in basically every Woosh workflow, because it's the only way to get the model onto your canvas. It's the pack's unified loader for Sony AI Research's Woosh sound-effect foundation model - the text-to-audio and video-to-audio generator that's been quietly filling the foley-shaped hole in ComfyUI's audio layer. If you've ever bolted MMAudio onto the end of a Wan render to give it sound, this is the same job, a generation newer and from Sony's own research arm. One node, four checkpoints: it loads Flow, DFlow, VFlow, or DVFlow depending on what you point it at.

Know this up front: it's a loader, with no sampling in it. All it does is load the right weights and hand them to the Woosh Sampler. That's a relief rather than a limitation - you can't accidentally sample in the wrong place, and the node caches whatever it loaded, so re-running a workflow doesn't re-read gigabytes from disk every time.

How it works

Two inputs, both dropdowns. model_name enumerates every folder inside ComfyUI/models/woosh/ that contains a config.yaml - that's how the pack detects checkpoints, so the folder structure matters more than anything else here. model_type picks the architecture, and each maps to a different code path:

• Flow - full text-to-audio model, best quality, wants ~50 steps.
• DFlow - the FlowMap-distilled text model, 4 steps, roughly half the VRAM.
• VFlow - full video-to-audio, conditions on video frames.
• DVFlow - distilled video-to-audio, 4 steps.

The useful safety net: the loader reads the checkpoint's own config.yaml and refuses to load if your model_type doesn't match what's actually in the folder. Point it at Flow with DFlow weights and you get a clear error instead of silent garbage. It also rewrites the checkpoint paths inside that config to absolute paths while loading, then restores the original file - so a config never gets poisoned with your machine-specific paths. Small detail, but it's why this pack survives being moved between installs without breaking.

Under the hood it wraps the model in a ModelPatcher subclass - the same VRAM-management mechanism ComfyUI uses for image checkpoints. The model starts on CPU and gets shuffled onto the GPU on demand. On a low-VRAM card that's the difference between "won't run" and "slow, but it runs."

What you actually set

• model_name - the checkpoint folder, e.g. Woosh-Flow.
• model_type - must match the checkpoint. That's the whole job.

The single output, gen_model, is a custom WOOSH_GEN_MODEL type that only plugs into the Woosh Sampler's gen_model input. It won't wire into anything else, and that's by design.

Install and models

ComfyUI Manager is the easy path - search Woosh and hit Install. Manually:

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

Then restart ComfyUI completely; a normal refresh won't pick up the new modules. Download the checkpoints from drbaph/Woosh on Hugging Face and drop each folder into ComfyUI/models/woosh/:

ComfyUI/models/woosh/
  Woosh-Flow/          # config.yaml + weights.safetensors
  Woosh-DFlow/
  Woosh-VFlow-8s/
  Woosh-DVFlow-8s/
  Woosh-AE/            # required - every model references it
  TextConditionerA/    # required
  TextConditionerV/    # required

Each folder needs config.yaml and weights.safetensors at its root. The Woosh library itself is bundled inside the pack - no separate Woosh pip package - but requirements.txt installs the supporting stack (hydra-core, omegaconf, torchdiffeq, timm, einops, av, torchvision, huggingface_hub, hear21passt).

The traps

The most common real-world failure isn't a bad download - it's that your checkpoint never shows up in model_name. People hit this constantly. The fix, straight from the pack's README and confirmed in the field: the folder must be named exactly woosh under ComfyUI/models/, each model folder needs config.yaml and weights.safetensors, download every file in the HF repo (not just the safetensors), and fully restart ComfyUI.

Also, Woosh-AE, TextConditionerA, and TextConditionerV are required downloads even if you only ever run text-to-audio - every generative model references them internally, so the loader errors without them. And when loading prints "Error loading state_dict in strict mode"? That's normal, not a failure. Some checkpoint keys don't line up and non-strict loading handles it.