Pallaidium installs from a branch archive and pins its dependencies to Blender 5.2

The add-on downloads as a zip of the main branch and there are no releases

The documented install is a direct archive link:

https://github.com/tin2tin/Pallaidium/archive/refs/heads/main.zip

The path ends at `refs/heads/main`, which means the file you install is whatever the branch happened to hold at the moment you downloaded it. The repository has no GitHub releases, so there is no tag, no version string and no changelog to compare against. Everything before that step is manual by design: install git and keep it on PATH, fetch Blender 5.2 or later and unzip it into the Documents folder with no spaces or special characters in the path on Windows, then install the zip through Preferences, Add-ons, Install, and enable it. The consequence for anyone reporting a problem is that two people running the same instructions two weeks apart may be running different code, and nothing in the workflow records which. The tree also carries a `blender_manifest.toml` next to `__init__.py`, the shape of a Blender extension manifest, while only the branch zip path is documented.

The uninstall paths are hard-wired to a Blender 5.2 folder

Python dependencies are installed into the Blender user data folder rather than next to the executable, which is why the remove instructions give two exact paths:

%APPDATA%\Blender Foundation\Blender\5.2\datafiles\Pallaidium\site-packages
~/.config/blender/5.2/datafiles/Pallaidium/site-packages

Both name the 5.2 directory explicitly, so the documented removal path belongs to one Blender version. Move to a later Blender release and the site-packages tree for the old version is still on disk, holding a full copy of the dependency stack, and the add-on in the new version will need its own install run. The Windows path uses the vendor folder name `Blender Foundation` in capital letters while the Linux path uses plain `blender`, which is how Blender actually writes them, but it means a scripted cleanup has to match each platform separately. Model weights are handled separately again, through the Hugging Face cache at `~/.cache/huggingface/hub` on Linux and `%userprofile%\.cache\huggingface\hub` on Windows. Deleting the add-on folder removes the libraries but not the weights, and the weights are the larger half of the disk.

The VRAM line gives a range where a minimum belongs

The requirements read: Blender 5.2 or later, a CUDA supported Nvidia card with at least 6-16 GB VRAM, CUDA 12.8, and a 20+ GB HDD where each model is 6+ GB. A range cannot be a minimum, so the line reads as a spread across the models the add-on can load rather than a floor for one of them, and a reader with 8 GB has to guess whether they are above or inside the requirement. The download story is stated twice and the two numbers are not the same. The requirements say 20+ GB of disk; the install steps say 5-30 GB must be downloaded the first time any model is executed. Twenty gigabytes of free space does not obviously cover a thirty gigabyte first run, and nothing on the page says whether the model you pick decides which end of that range you hit. Also note the instruction to restart the computer after the Install Dependencies button, not just Blender.

Some dependencies are installed from git at runtime and never appear in the list

`requirements.txt` is a long pinned list, and it is not the whole story. Two of its comments describe dependencies the file does not pin. One notes that sdnq is pinned to `==0.2.4` inside `DependencyManager.get_phase_3_git_and_extensions`, with a skip-if-present condition, which places the install in code and the source in git rather than in the file. Another pins a second version for one model:

transformers==5.9.0 ##==4.57.6 version for Hviske

A single pinned transformers version cannot satisfy every model plugin in a tree with `models/`, `models_plugins/` and `unsupported_models_plugins/` directories, so the add-on carries a per-model exception and records it as an inline comment. The one-click install and uninstall of dependencies advertised in the feature grid therefore does things the visible file does not describe, and the phase naming in that function name suggests the install runs in stages. Treat the pinned file as the documented floor rather than the full list of what lands in the interpreter.

A training stack is pinned inside a Blender add-on

The requirements file opens with a section of core IO and utility pins, then switches to a section labelled ML framework dependencies and extensions. That second section is where the shape of the project becomes clear: `lightning`, `torchmetrics`, `wandb`, `webdataset`, `torchdiffeq`, `v-diffusion-pytorch`, `vector-quantize-pytorch`, `alias-free-torch`, `prefigure`, `local-attention`, `nitrous-ema`, `einops-exts`, `timm`, `optimum-quanto`, `kornia`, `spandrel` and `laion-clap`. Several of those belong to training or research code rather than to running a panel in Blender, and every one of them has to resolve inside the Python interpreter that Blender ships with, in a site-packages tree of its own. `spandrel` covers the upscale and refinement path, `av==16.0.1` covers video IO, and `standard-aifc`, `standard-chunk` and `standard-sunau` cover audio IO. Two version constraints stand out as deliberate: `setuptools<70.0.0` caps the installer itself, and `protobuf>=5.26.1,<6.0.0` keeps a major version window. The practical consequence is a large install that has to succeed against an interpreter you did not choose.

Three hosted service clients sit in the pinned list

The README frames the project as free and local: a free generative AI movie studio, free and open source, run inside the Video Sequence Editor, with requirements that describe a CUDA card. The pinned list tells a longer story. `wandb==0.15.4` is a hosted experiment tracking client, `opentelemetry-api>=1.34.0` is a tracing library, and `pyannoteai-sdk` sits directly beside the local `pyannote.audio` stack, which is the hosted speaker diarization service offered by the same project. `hf_xet` is the Hugging Face transfer backend for model downloads. The tree agrees with the list: there is a `remote_backends/` directory, a `pallaidium_mcp_tools.py` module at the root, and a `MiniMax_API.txt` file, which is what a provider API note looks like. So remote generation paths and an MCP integration exist in the code. What the documentation does not do is say which models run remotely, what an API key needs, or whether any local-only mode exists at all.

Windows comes first, Linux waits for contributors, and there is no CI in the tree

The requirements open with Windows and follow it with limited support for Linux, pointing at issue 105 and saying the project will have to rely on contributor support. Both remedies in the error table are Windows only as well: a failed MSVC discovery is answered with the Visual Studio Build Tools installer, and a missing DLL is answered with the Microsoft Visual C++ redistributable. Against that, the tree does ship `requirements_linux.txt`, so there is a separate dependency set for a platform described as limited. The testing layout is three loose scripts, `test.py`, `test_models.py` and `test_remote_backend.py`, plus a `test_pkg/` directory, and there is no `.github/` entry in the tree at all, which leaves no visible workflow that runs them on a commit. With six-plus gigabytes per model and pinned dependency versions that one model already contradicts, that is the gap worth watching.

The feature grid has an empty header row and mixes models with panel widgets

The features table opens with a header row of three empty cells, then lists thirty entries in three columns with nothing grouping them. Model controls sit next to queue plumbing and housekeeping: Seed, LoRA Weight, Quality steps, ControlNet, OpenPose, Canny, ADetailer, IP Adapter Face and IP Adapter Style in the same grid as Start, Stop and Cancel controls, PENDING, RUNNING and COMPLETED job statuses, a render finished notification, a user-defined output path, and seed and prompt added to the strip name. Two labels also break their own convention, with `Video to Image` capitalised where `Image to image` is not. The generation matrix above it is the sharper document: text input reaches image, video, text, audio, music and speech, while image and video input reach image, video, text and audio but have empty music and speech cells. So music and speech are text only, and the video to text entry is what backs the reverse path, taking captions off a result and rebuilding a screenplay from them.

Editorial conclusion

Treat Pallaidium as a power-user tool with an honest hardware floor rather than a one-click install. The parts that decide whether it works for you are all stated plainly: Blender 5.2 or later, a CUDA Nvidia card, CUDA 12.8, and a first run that downloads gigabytes of weights, on Windows, with Linux left to contributor support. What to verify before you commit a machine to it: which generation paths call a hosted service, since the pinned list carries an experiment tracker, a speaker diarization API client and a telemetry library next to a remote backends directory and an MCP tools module; whether your Blender version still matches the site-packages path you would uninstall from; and whether the model you want runs locally at all. Record the commit you downloaded, because there are no releases to fall back on.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. tin2tin/Pallaidium on GitHub