# LSP plugins: a Linux audio plugin collection spread across formats

> LSP is an LGPLv3 collection of open source audio plugins for GNU/Linux and friends, shipped in CLAP, LV2, VST2, VST3, LADSPA, GStreamer and standalone builds with an unusually honest support matrix. The judgement is that the binary bundles are the way in, and that the repository itself is now a build shell that pulls source from sibling repositories.

**lsp-plugins/lsp-plugins** — Linux Studio Plugins Project

- Repository: https://github.com/lsp-plugins/lsp-plugins
- Website: https://lsp-plug.in/
- Stars: 897 · Forks: 68
- Language: Makefile
- License: LGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/lsp-plugins-lsp-plugins

## The repository is now a build shell

The most important line in the README is a note about what this repository no longer is. After the 1.2.0 release, the lsp-plugins repository was decomposed into multiple subprojects, and as a result it is a repository without any code that, for build purposes, gathers source code as dependencies from other repositories hosted under the same GitHub organisation. The stated reason for going that way is that, after contributing to other open source projects, the decision was made to implement separate and independent plugin distribution. What remains here is a build system and a set of manifests, with a Makefile at the root, modules.mk, plugins.mk, project.mk and dependencies.mk, and make, misc, res and src directories. The Eclipse project files .project and .cproject and a .gdbinit are also present. So if you arrive expecting a single tree of plugin sources, you will not find one, and the practical consequence is that cloning this repository alone does not give you a buildable source tree.

## Format support is uneven, and the README says where

LSP exists to fill the lack of good and useful plugins under the GNU/Linux platform, and it distributes the same plugin set in every format a host might speak. The support levels differ, and they are stated rather than implied. CLAP, LV2, VST2 and LinuxVST, and VST3 all have full support. LADSPA has partial support, specifically because plugins that use MIDI or file loading cannot work under that format's restrictions, which is a limitation of the format rather than of the code. GStreamer is experimental. Standalone builds work with a Dummy audio backend and a JACK audio backend. That list tells you where to start depending on your host, and it also tells you which formats to avoid if you rely on MIDI control or on loading impulse or sample files inside a plugin.

## The platform matrix grades its own confidence

The system requirements section publishes a table of architectures against operating systems, with a five-level legend, and this is unusually good practice to copy. F means full support. C means the code does compile but there is not enough knowledge about whether it works correctly. E means experimental support with not enough feedback from users. U means unknown, the code may be built but correctness has not been tested. N means no support, the code may compile but the work has not been tested. On GNU/Linux, aarch64, i586 and x86_64 are graded F, while armv6-a, armv7-ar, loongarch, ppc64, riscv-64 and s390x are graded C, and armv5t is graded C as well. On FreeBSD, x86_64 and i586 are F and aarch64 is E. On Windows, x86_64 and i586 are F and the rest are U, with the minimum supported Windows version stated as Windows Vista. On macOS, only x86_64 has a grade, and it is E. Reading the legend is the point, because a C in the table means compiled but unverified, which is not the same thing as working.

## Bundle names encode format, version, platform and architecture

Binary releases contain all possible plugins in one bundle, and the archive name tells you everything you need before you download. The format is lsp-plugins-<format>-<major>.<minor>.<micro>-<platform>-<arch>.tar.gz, where the format property selects between clap for CLAP plugins, doc for documentation, gst for GStreamer, ladspa, lv2, src for the source code, standalone for the JACK capable standalone builds, vst2 for VST 2.4 and vst3 for VST3. The version is split into major, minor and micro, and the micro version carries meaning: if it is odd, the release contains mostly bug fixes and patches for the plugin modules, while an even micro version contains new features and, in most cases, a new plugin series. That is a convention worth internalising before you file a bug against a version number. The history of changes is in a CHANGELOG.txt attached to the release.

## Installing binaries means copying files into the right directory

Installation of the prebuilt bundles is described as ready to launch, with the instruction to copy them to the appropriate directory. The README then lists where those directories are, which is the part that saves an afternoon. For CLAP, the usual directories are /usr/lib/clap, /usr/local/lib/clap, /usr/lib64/clap, /usr/local/lib64/clap and ~/.clap. The standalone core library goes into one of /usr/lib, /usr/local/lib, /lib, /usr/lib64, /usr/local/lib64 or /lib64, and the standalone binaries into /usr/bin, /usr/local/bin, /bin, /usr/sbin or /usr/sbin. The GStreamer core library follows the same pattern, and the plugin directory for GStreamer is not hardcoded but obtained from pkg-config, which is the reliable way to match whatever your distribution actually uses:

```bash
pkg-config --variable=pluginsdir gstreamer-1.0
```

There is one trap worth stating plainly. If you deploy the plugins as a subdirectory of your VST2 directory, that subdirectory must contain the substring lsp-plugins, otherwise the plugins will not find the VST2 core library. The README also notes that releases with an odd minor version provide only enhancements and critical fixes for the previous release.

## Building from source with the make configuration

Source code is also ready for building, and the build system is a Makefile hierarchy rather than a modern one. The root Makefile sets a base directory, a modules directory, a .build output directory, and points at .config.mk for the configuration, plugins.mk for the plugin list and project.mk for the project level settings. The configuration check is explicit, since the build refuses to continue without it and the error message tells you to launch make config first. The file also has a nice touch for debugging, a VERBOSE flag that silences nested make invocations unless you set VERBOSE to 1. Alongside the build machinery the README lists the Linux distribution requirements, glibc at 2.19 or newer, libsndfile at 1.0.25 or newer, libcairo at 1.14 or newer, libfreetype at 2.10 or newer and libGL. Those are the libraries the graphical plugins and the file handling depend on, so a minimal container image without them will not run the whole set.

## Licence, host compatibility and the release rhythm

The project is licensed under the GNU Lesser Public License v3, and the tree ships COPYING and COPYING.LESSER for the two texts, with the note that there is no absolute warranty about stability across different platforms and that you use the software at your own risk. That disclaimer is the same message the platform matrix conveys in table form, which is a good sign about how the project reports on itself. The list of supported plugin hosts is explicit too, covering Ableton Live on macOS with VST3, Ardour, Bitwig Studio, Carla, Mixbus, Qtractor, Reaper, Renoise and Tracktion. On releases, the tags are 1.2.35 on 2026-08-23, 1.2.34 on 2026-08-15 and 1.2.33 on 2026-06-13, and the last push was on 2026-10-11 with the repository not archived, so patch releases continue to arrive between the minor ones. Supplementary information, documentation and the project site live at lsp-plug.in, and the project also runs a donation page since the work is volunteer maintained.

## Conclusion

LSP is worth adopting for a Linux or FreeBSD audio user who wants free effect and instrument plugins in the same formats their host already speaks, especially since the bundles ship prebuilt and the support matrix tells you exactly which architectures are tested. It is the wrong choice for a musician who needs the plugin to be found reliably by a host that scans a single VST2 directory, since the VST2 layout requirement is easy to get wrong, and for anyone on macOS or Windows expecting the same level of assurance, since those columns are marked experimental or unknown. Before you install, read the support matrix for your architecture, copy the bundle into the directory your host actually scans, and check the CHANGELOG.txt in the archive to see whether the micro version you downloaded is a bugfix release or one that introduces a new plugin series.

## FAQ

### Which plugin formats does LSP support?

CLAP, LV2, VST2 and LinuxVST, and VST3 all have full support. LADSPA has partial support, since plugins that use MIDI or file loading cannot work under that format's restrictions, GStreamer is experimental, and standalone builds work with a Dummy audio backend and a JACK audio backend.

### How do I install the LSP plugins on Linux?

The binary distributions are ready to launch, so you copy them into the appropriate directory. The README lists the usual CLAP directories such as /usr/lib/clap and ~/.clap, the standalone binary directories such as /usr/bin and /usr/sbin, and the GStreamer plugin directory, which is obtained with pkg-config --variable=pluginsdir gstreamer-1.0 rather than being hardcoded.

### Why will my LSP VST2 plugins not load in my host?

If you deploy the plugins as a subdirectory of your VST2 directory, that subdirectory has to contain the substring lsp-plugins. Otherwise the plugins will not find the VST2 core library, which is a specific requirement stated in the README installation notes.

## Sources

- [License: LGPL-3.0](https://github.com/lsp-plugins/lsp-plugins/blob/master/LICENSE)
- [lsp-plugins/lsp-plugins on GitHub](https://github.com/lsp-plugins/lsp-plugins)
- [Project website](https://lsp-plug.in/)
- [README](https://github.com/lsp-plugins/lsp-plugins/blob/master/README.md)
- [Releases](https://github.com/lsp-plugins/lsp-plugins/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lsp-plugins-lsp-plugins