Hey there,
has someone managed to compile the LSP plugins for windows? There is a kind of tutorial on their site but i fail to get it to work. Noob me would need someone to guide me through the process. I’m stuck at a point and don’t find the issue.
On another note: would the LV2 versions work or do they also have to be compiled to windows? If so, how?
cheers
eighty
The type of plugin (LV2 or VST2 or VST3 for example) is independent of the processor architecture (x86 vs. ARM) and independent of operating system (Windows, gnu/Linux, MacOS).
You should in principle be able to have LV2 linux, LV2 Windows, VST3 linux, and VST3 windows versions of the same plugin (x86_64 processor architecture as an unstated assumption for simplicity).
I guess the actual question is “Would the LV2 versions (for Linux) work (in Windows)”.
The answer is no; they would have to be compiled specifically for Windows.
At what point are you stuck?
You should probably run make config FEATURES='vst3' when compiling for Windows, so you don’t run into issues trying to compile LV2 and VST2 versions that you don’t need.
make lean
Clean OK
make config FEATURES=“vst3”
Architecture: ia32/i686 (-march=i686 -m32)
Features: vst3
Configured OK
make fetch
Fetch OK
make install
make [lsp-common-lib]
g++ [lsp-common-lib] main/status.cpp
In file included from MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/status.h:26:0,
from main/status.cpp:24:
MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/types.h:120:10: warning: #warning “Unsupported architecture bitness” [-Wcpp]
#warning “Unsupported architecture bitness”
^~~~~~~
g++ [lsp-common-lib] main/debug.cpp
In file included from MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/debug.h:27:0,
from main/debug.cpp:22:
MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/types.h:120:10: warning: #warning “Unsupported architecture bitness” [-Wcpp]
#warning “Unsupported architecture bitness”
^~~~~~~
g++ [lsp-common-lib] main/atomic.cpp
In file included from MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/atomic.h:26:0,
from main/atomic.cpp:22:
MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/types.h:120:10: warning: #warning “Unsupported architecture bitness” [-Wcpp]
#warning “Unsupported architecture bitness”
^~~~~~~
g++ [lsp-common-lib] main/stdio.cpp
In file included from MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/stdlib/stdio.h:26:0,
from main/stdio.cpp:22:
MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/common/types.h:120:10: warning: #warning “Unsupported architecture bitness” [-Wcpp]
#warning “Unsupported architecture bitness”
^~~~~~~
In file included from main/stdio.cpp:22:0:
MYINSTLLFOLDER/modules/lsp-common-lib/include/lsp-plug.in/stdlib/stdio.h:35:57: error: ‘va_list’ has not been declared
int vasprintf(char **strp, const char *fmt, va_list ap);
^~~~~~~
Makefile:118: recipe for target ‘MYINSTLLFOLDER/.build/target/lsp-common-lib/main/stdio.o’ failed
make[5]: *** [MYINSTLLFOLDER/.build/target/lsp-common-lib/main/stdio.o] Error 1
Makefile:52: recipe for target ‘compile’ failed
make[4]: *** [compile] Error 2
Makefile:854: recipe for target ‘LSP_COMMON_LIB’ failed
make[3]: *** [LSP_COMMON_LIB] Error 2
Makefile:66: recipe for target ‘install’ failed
make[2]: *** [install] Error 2
Makefile:145: recipe for target ‘install’ failed
make[1]: *** [install] Error 2
Makefile:67: recipe for target ‘install’ failed
make: *** [install] Error 2
i tried with and withoud the “fetch” step but with no different result.
The odd thing is the “i686” since i have an AMD Ryzen 3950X but i tried also with ARCHITECTURE=generic (don’t remember the exact name here. I found a list of possible architectures and tried a few. Don’t find the list anymore though. Noob problem!!)
Yeah, you almost certainly want a 64 bit x86 build. On linux that is referred to as x86_64, I’m not sure if the same term is used with Windows gcc builds, but likely is.
Which MinGW package did you install? The page at lsp says MinGW-W64, which I assume is the 64 bit build for Windows (although confusingly the MinGW page lists MinGW-W64 as “for 32 bit and 64 bit Windows”).
This error indicates that your compiler does not provide __WORDSIZE nor __SIZE_WIDTH__ macro that is used to determine the size of machine word by LSP.
Also LSP automatically detects the architecture for Windows based on the PROCESSOR_ARCHITECTURE environment variable. What’s your value of PROCESSOR_ARCHITECTURE environment variable on a build machine?
I downloaded x86_64-posix-sjlj from MinGW-w64 - for 32 and 64 bit Windows - Browse /mingw-w64 at SourceForge.net (under MinGW-W64 GCC-8.1.0; I tried the online installer first but it just showed “fetching repository description” and then exited).
Unzipped it with 7-zip and set up everything according to the LSP BUILDING instruction.
Ran mingw32-make configure FEATURES='vst3' and it detected my x86_64 arch.
mingw32-make fetch
mingw32-make -j4
mingw32-make install
“install” doesn’t actually install the VST3 package in its proper location, but only creates it in the INSTALL\lib\vst3 subfolder, so you have to manually copy the lsp-plugins.vst to the c:\Program Files\Common Files\VST3 folder
IT WORKED!!!
… kind of. First of all thx for the walk through guys. Seems i messed up the mingw install somehow.
But when i load the plugins the scaling of the gui is bigger than the pluginwindow. When i increase the size of the window the scaling tries to adjust but keeps showing just a part of the gui. I supouse that’s an issue of the plugin, right?!
At least i can use the generic controls but that is not exactly what i was looking for.
What host do you use? Any screenshots? You can configure your own UI scaling using plugin’s global configuration file in your home directory.
I had the same issue when I tried (VST3 in Ardour 8.6 on Windows10 22H2) and it seems to be related to Windows GUI scaling; which is 125% by default.
Right-click on the desktop, select “Display Setting” and under “Scale and Layout” change the size to 100%.
Another problem, in my testing at least, is that if I have two LSP plugins (Chorus Stereo and Parametric EQ 16 Sterero in this case) I can only open one of them.
When I close that and try to open the other one (the order doesn’t matter) Ardour crashes with a “Error registering window class: 1410”
I can reopen the first plugin as many times as I want and also open the ACE-EQ with the Harrison GUI in between.
I could also open another VST3-plugin, TDR Nova, in between, so it seems to be a clash between the LSP plugins, specifically.
Yes, it seems that both windows are trying to call RegisterClassW function with the same window class name. I’ve just fixed it in the devel branch of the lsp-ws-lib library.
Because @SadKo beeing faster fixing than me informing, just for reference:
yepp, it was a windows 150% scale here with the same issue as @peder had screenshotted. But even with scale to 100% scaling had problems. Loaded the multiband compressor and scaling down worked but if i increased window size again, scaling went crazy. Couldn’t do a screenshot because it made windows freeze also.
But let’s hope this is also fixed by sadko’s fix.
Again big thanks to all.
I’ve noticed that Ardour is sometimes behaving bad with window sizes even for Linux. If you try to resize plugin window, the UI will adopt to the new size of the window and cut edges should disappear.
I think it is a good reason for @x42 to check why Ardour is improperly handling embedded window size of the plugin.
Thank you for these flexible plugins. I did notice that when using lv2, and I have more than one LSP plugin open, I cannot adjust anything on the GUI in either plugin. If I close one GUI, the GUI remaining works again and I can adjust. I dont know if it is my system, Ardour, or LSP. I am using the current release of Ardour and LSP.
Ubuntu 22.04 LTS
I cherry-picked the two @%p fixes from lsp-ws.lib devel into 1.2.16 and now I can open and reopen the LSP plugins.
BUT, if I open and close one and then open and close the other and then try to reopen the first one the GUI doesn’t appear until I move the mouse.
And the entire Ardour GUI starts behaving in a similar fashion, requiring me to move the mouse to see the thing I’ve clicked on taking place. That even goes for quitting Ardour.
However; if I open and close the first LSP plugin and then open and close the ACE-EQ (with the Harrison GUI) I can subsequently open and reopen plugins and stuff with expected responsiveness.
So it seems something isn’t reset properly when the LSP GUI closes and that ACE/Harrison somehow fixes that, even going forward.
Hmmm. Need to check.
Could not reproduce the problem on virtual machine with Windows 8.1 and latest nightly build of Ardour.
@peder it would be nice if you could ship a video demonstrating the problem
