Plugins
Plugins from your distribution, and what the console does with them.
The console runs LV2 and CLAP plugins that were not written for it. Each one runs in a process of its own, and each can be measured before a show, so you know in advance whether it is safe to rely on.
01
Install them from the distribution.
A third-party plugin installs like any other package. As an example, the LSP plugin suite, in its LV2 and CLAP builds:
On Fedora:
sudo dnf install lsp-plugins-lv2 lsp-plugins-clap
On Debian and Raspberry Pi OS:
sudo apt install lsp-plugins-lv2 lsp-plugins-clap
The files land in the distribution's plugin directories. On Debian that is /usr/lib/lv2 and /usr/lib/clap. On Fedora LV2 goes to /usr/lib64/lv2, and this suite's CLAP file goes to /usr/lib64/clap, not to /usr/lib/clap, where the omx plugins and the qualifier's default search look.
02
How the console runs them.
plugin-hostd runs LV2 and CLAP plugins, each in a worker process of its own, behind the same socket protocol the console already speaks. Audio never passes through the daemon: every worker is an audio client of its own.
If a plugin crashes, only its worker is restarted, with its settings put back, and the other plugins keep playing. A plugin that keeps crashing is singled out and given up on without touching its neighbours.
Before a plugin starts, the daemon checks that its files are the ones that were checked: it hashes them and compares them with the plugin's recorded pin. A plugin updated or swapped behind your back is refused until you accept the new files, so a change cannot slip in unchecked. A plugin whose record says it was refused does not start.
What the plugin picker offers on a channel is described in the plugins chapter.
03
Measure a plugin before you rely on it.
plugin-qualify scans a plugin, measures it offline (latency and CPU cost) and runs it under a real host, then gives one verdict. It installs next to plugin-hostd:
On Fedora, with the FreeMixer repository added as on the page of shipped plugins:
sudo dnf install plugin-hostd omx-clap-host plugin-qualify
On Debian and Raspberry Pi OS:
sudo apt install plugin-hostd omx-clap-host plugin-qualify
Name a plugin file, a bundle or a URI:
plugin-qualify /usr/lib/clap/omx-delay.clap
The answer is one line per plugin, here for one of the omx plugins:
plugin-qualify: host profile openmixer-console (in-process)
plugin-qualify: target urn:clap:org.openmixer.delay (/usr/lib/clap)
plugin verdict reason host
urn:clap:org.openmixer.delay suitable - openmixer-console
The exit code is 0 when every plugin qualified, 1 when some did not and 2 when something could not be measured.
--all walks the CLAP search path (CLAP_PATH, then ~/.clap, then /usr/lib/clap) and refuses when LV2 bundles are installed, since it does not measure LV2 itself. In that case name the plugins or bundles.
04
What a verdict means for you.
Four verdicts. The deciding reason is printed beside it.
suitable
Every check was made and passed. The plugin is safe to run inside the console's own engine process. This is the only verdict that counts as qualified.
Rack it.
conditional
It works, with a caution, for example a high cost at small buffer sizes. It is run isolated, and the reason names the caution.
Rack it if you can live with the reason, and read the reason first.
unknown
Something was not measured. An unmeasured plugin is never counted as a pass.
Measure it again, or leave it off the live rig.
unsuitable
A measured failure: a crash, a memory error in the plugin's own code, a real-time violation (it allocates memory, takes locks or makes system calls while it processes audio) or a required feature the host does not provide.
Leave it off the live rig.
The worst check decides the verdict.
A verdict is judged for a particular host. The default is the console itself; the same measurements can be judged for other hosts, so a plugin can be fine in one and refused in another.