linuxsampler under windows

Hi, I used to be able to use linuxsampler vst in some way under ardour4 (windows version).
Now with 5.4 it does see and mention the linuxsampler.dll during Plugin-scan, but later it does not show in plugin manager…
Am i missing some trick to use it?

Thanks, Arno

i suspect it is getting blacklisted? any particular reason for that?

Maybe a 32 vs 64bit issue (64bit ardour, 32bit VST or vice versa). Preferences > Plugins > verbose plugin scan. Clear cache, re-scan. then check Menu > Window > Log

Thank you for your help!

The log says:

[INFO]: * C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll - x64 (64-bit)
[INFO]: Kann Windows VST Informationen nicht erhalten, Plugin “%1” wird ignoriert.

Last line translates into "Can’t obtain windows VST information. Plugin “%1” will be ignored.

/AppData/Local/Ardour5/cache/vst64_blacklist.txt then contains the path and name of linuxsampler64.dll. I leared the file before the scan.
This happens with fresh install of most recent windows’ linuxsampler. I could reproduce it with a version some months old (which i remember to have worked in ardour4)

What is the next thing i can do?

Thanks, Arno

What i cannot understand from looking at the code is that one should expect some more warnings in the log for a plugin becoming blacklisted, which i cannot see in the log…!?

it seems you have a linux vst downloaded, no windows. could that be your issue?

Why do you think that? It is .dll, not .so, and i ran the windows installer from their website…
It is getting blacklisted for some reason, so how could I find out for what particular reason?

@arnowa To restate a comment from earlier, which version of Ardour are you running, 32 bit or 64 bit?


ardour 5.4 64bit

I am also struggling with this:

Ardour 5.12.0 (rev 5.12) Intel 64-bit
LinuxSampler64.dll (installed via linuxsampler_20190424_setup.exe)
Windows 10 (1809)

[INFO]: — Windows VST plugins Scan: C:\Program Files\Steinberg\VstPlugins;C:\Users\dbolton\Documents\Plugins\VST
[INFO]: * C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll (cache only)
[INFO]: -> Cannot get Windows VST information, plugin ignored.
[INFO]: — Windows VST plugins Scan Done

Why would you even want linuxsampler on Windows? Session compatibility with GNU/Linux systems?
You can use the original: or even NI’s Kontakt player.

To debug this, open a

cd "C:\Program Files\Ardour5\bin"
ardour-vst-scanner.exe -f "C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll"

That may or may not share some light.

1 Like

Thank you! I will look into Sforzando and Kontakt. I’ve used LinuxSampler on Linux before, but less familiar with the options on Windows. (I was trying to use this orchestra template as a starting point).

In the meantime, here’s the debug error message I get when I run your commands:

ardour-vst-scanner.exe - Entry Point Not Found

The procedure entry point ZNSt13runtime_errorC2ERKS could not be located in the dynamic link library C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll.

Looks like the VST was not statically linked and/or depends on libraries not present on your system.
Perhaps inspect the .dll with – but I suggest to rather report this to to linuxsampler devs.

I reported to the LinuxSampler devs as you suggested. They have already fixed another issue I reported in the same email, but replied with the following about the VST links. Here’s a link to mailing list archive:

So like I expcted, the stand-alone app runs there. Then the problem you have
with the LS VST not launching in Ardour is indeed very likely caused by a
conflicting libstdc++ version.

Background: we are currently still using GCC as compiler on our build server
for compiling the daily snapshot installers for Windows. And I am pretty sure
your Ardour binary was compiled with clang. The two compilers use their own
implementation of libstdc++, and both cannot be loaded into one process at the
same time.

Like already suggested in the Ardour forum, one workaround would be if we
statically link libstdc++ into our binaries (instead of letting our binaries
load libstdc++ dynamically as DLL on startup like it is now). But that is
tricky and may introduce new problems, since all libs used must then use our
statically linked libstdc++ instead.

Another option would be if we just switch to clang for compiling the Windows
installer. But then it would cause other DAWs getting the same VST issue if
they were compiled with GCC instead.

IMO the best solution on long term would be Ardour running VST plugins in
their own process, instead of loading VST plugins directly into the Ardour
process. That way libs loaded by VST plugins would no longer conflict with libs
of other plugins or host app (i.e. Ardour). Because even if we do some of the
workarounds mentioned above, the next issue would already be ahead: e.g. if
you want to edit a gig file currently being played back as VST instrument in
Ardour, then our gigedit instrument editor would try to load Gtk3 libs, and
Ardour already loaded Gtk2 libs, hence gigedit would never show up on your

I know the opinion of Ardour developers is that running plugins in their own
process would be inefficient due to expensive context switches, but other DAW
apps like Logic already switched to that new model and performance seems to be
Ok nowadays. In the end this could also become an optional setting per plugin
on Ardour side.


Nope, ardour uses mingw/gcc. To be precise: x86_64-w64-mingw32-gcc (GCC) 4.9.1
Full build information is available here:

This will never happen. Process separating plugin introduces a context-switch and this does not scale. Even on modern systems the overhead is significant. Like ProTools and other professional products we reject plugins from authors who don’t understand this.