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?
[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 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…!?
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?
Why would you even want linuxsampler on Windows? Session compatibility with GNU/Linux systems?
You can use the original: https://www.plogue.com/products/sforzando.html or even NI’s Kontakt player.
To debug this, open a cmd.com
cd "C:\Program Files\Ardour5\bin"
ardour-vst-scanner.exe -f "C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll"
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 http://www.dependencywalker.com/ – but I suggest to rather report this to to linuxsampler devs.
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
screen.
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.
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.