Would there be anyone nice who could compile Linux Studio Plugins for Windows in CLAP and VST3 formats?

https://lsp-plug.in/?page=download&section=source

 

I can give it a go, though I need to check if my MINGW toolchain is up to date.

 

https://mega.nz/file/5wk2FKiT#JgqZNb08rqpoXGR_ow5T_Yf1HcFyPOKvZ3Cz0TJG6os

Works on my machine™.

 

@Will Kweks thank you

 

Just curious: you are a windows user and can choose from a lot of plugins. Why these specific Linux plugins?

 

I have 2 systems with Windows and Linux, but work mostly on Windows. In my spare time I am active on Linux, mostly in the audio world.
As for Linux Studio Plugins, I think the plugins deserve more publicity, because they are just really good.

Included in this package is an autogain plugin, a reverb modeler based on the 3d model of the room, some good eqs, A\B plugin.
mass of goodness.


Linux has a lot of great native tools, but it's still a shame that it's not widely supported by developers.

 

Couldn't agree more! I am a Linux user now for 3 years, no windows at all any more. I did not know these LSP plugins. They cover somehow the whole musical area. I discovered the A/B plugins to distinguish between multiple versions. Nice!

 

Sorry to bring up an old thread, but I was unable to get the clap or the vst3 version of this working, I put the vst3 and clap in the corresponding directories and the plugin had failed within reaper, FL studio, and Kushveiw Element. To make sure I wasn't missing anything, I put the lsp plugins folder both in the vst3 and clap directories after it had failed, and it did not make a difference.

Below are the errors from fl studio and element



Am I missing something?

 

Dunno, I only tried on a) my machine and b) with Ableton and Reaper. Both work fine.

An educated guess would be that you're missing some requirements (like the latest VC++ runtime), but you don't mention your Windows version.

You could try running something like Dependencies on the lsp plugin. It's should be in something like

C:\Program Files\Common Files\VST3\LSP\lsp-plugins.vst3\Contents\x86_64-win\lsp-plugins.vst3

or

C:\Program Files\Common Files\CLAP\LSP\lsp-plugins.clap

That tells what libraries (DLLs) the plugin needs to run.

 

I ran dependencies on both the vst3 and CLAP and it said that libwinpthread-1.dll is missing (as shown below) and did not come up with any other errors, I did some experimenting on my laptop as I wasn't home at the time, and it seemed nowhere I put the .dll fixed the issue ( I tried in the system 32, in the daws' wrapper/s), unless I missed something, I am not sure.



My windows version:

Edition Windows 10 Home
Version 22H2
Installed on ‎10/‎8/‎2024
OS Build 19045.6093
64 bit

I do have the latest version of VC++ runtime installed

Something that also concerns me is that I have seen on multiple occasions that on forums about compiling these plugins, is that they have the plugins show up separately, and not as one vst3/CLAP plugin, unless I am missing same steps here, I presume I would have installed them as any other plugin.

 

It's part of the MSYS2/MinGW toolchain, you can find the DLL here: https://mirror.msys2.org/mingw/ucrt...reads-13.0.0.r72.g7010671fa-1-any.pkg.tar.zst

The Windows dynamic linker (the bit that looks for DLL files) is sometimes convoluted, but the search order is roughly: the same directory as the executable or library (in this case the .clap file or the .vst3 inside the VST3 bundle), then PATH environment variable, and finally Windows system directories. So the easiest way to install it is to copy it there. The same paths apply as I previously commented.

Something like this (take note of the paths), after copying the .dll next to the plugin:

I'd highly recommend against copying any DLL from the net to any of the system directories.

And yes, both plugin bundles offer all of the LSP plugins in one file. Most hosts show them as separate plugins, at least the ones I tested with do.

 

I copied it from another application when I was on my laptop (I believe from unreal engine), didn't see the need to download something I have lol

interestingly dependencies shows no errors now, but is still fails (on my pc I just copied the dll from my mingw, as I tried to compile it, but I honestly have no idea what I am doing with that kinda thing)


so I am honestly stumped ¯\_/)_/¯

out of curiosity I tried it in a 4th daw (MOTU Performer LITE) and it also failed

 

You do realize that they can be built on Windows, and they run on Windows, right? Like so many other Linux software, the release tends to be source only and distros normally do the building.

Sure, there's snaps and flaps but those don't work with plugins (just how would you sandbox a plugin anyway from the rest of the system?).

*edit:* For posterity:

 

Last edited: Jul 20, 2025 at 11:35 AM

The pthread library versions should match (which isn't spotted easily, if at all), or the library should be at least newer than what it was designed to be linked against. In this case I built it with version 12.0.0.r423.g8bcd5fc1a-1 so 12 or newer. I linked to version 13.0.0 upthread which also works. Anything else, all bets are off. I attached the one that came with the toolchain (12.0.0) that the plugins were built with.

Again, never ever install DLLs into system directories unless a) you know what you're doing, b) you trust the source (*ahem*). So replace it inside the plugin bundle and you should be good.

Toolchains are fiddly bastards at best I'm afraid.

 

Last edited: Jul 20, 2025 at 11:35 AM

If only somebody had already built them...

 

Reminds me of a line from that old movie Field of Dreams..."If you build it they will come and look you in the eyes while insisting you didn't build it".

Pretty good movie, that one


edit: a word

 

Last edited: Jul 20, 2025 at 9:23 PM

If you pass -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic to the linker, you'll have a binary without dependencies - other than what's already installed installed by Windows anyway (assuming the screenshot is complete).

Couple options:

- Compile, copy the linking step's command (likely the very last line), append -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic to that command, re-run the edited command, binary should be free of dependencies.

- Clean your build directory & cmake/configure gunk, append and export -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic to your LDFLAGS environment variable, re-run cmake/configure and compile.

- Manually edit the Makefile(s)/cmake script.

 

If someone fancies to attempt static building remember that you have to use a compatible runtime and compiler combo, I picked g++/UCRT as it's very well supported though not available pre-7. Also LSP plugins use recursive makefiles so be extra careful editing them unless you fancy tracing declarations across several files. The makefile bundle doesn't do LDFLAGS, and remember that there's also compiler and linker definitions for cross-compilation.

Personally I'm sticking to using a working libwinpthread DLL, but that's just me.