Menu
▾
▴
linuxsampler-devel
|
From: David B. <dav...@gm...> - 2019-05-21 18:02:33
|
I'm having trouble getting LinuxSampler to run as a plugin within Ardour on Windows 10. Here's the error message as reported by Ardour: The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located in the dynamic link library C:\Program Files\Steinberg\VstPlugins\LinuxSampler64.dll. I posted initially in the Ardour forum. https://discourse.ardour.org/t/linuxsampler-under-windows/89908/13. They said, "looks like the VST was not statically linked and/or depends on libraries not present on your system" and suggested reporting to the LinuxSampler developers. Happy to run tests as needed. David |
|
From: Christian S. <sch...@li...> - 2019-05-23 16:29:30
|
On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote: > I'm having trouble getting LinuxSampler to run as a plugin within Ardour on > Windows 10. > > Here's the error message as reported by Ardour: > The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located > in the dynamic link library C:\Program > Files\Steinberg\VstPlugins\LinuxSampler64.dll. Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib already been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS VST plugin later on). Does the LS stand-alone app run? CU Christian |
|
From: David B. <dav...@gm...> - 2019-05-23 19:07:13
|
Christian, Thank you for your reply. Here's the messages I get when I launch linuxsampler.exe from the command line: C:\Program Files\LinuxSampler\64>linuxsampler.exe LinuxSampler 2.1.0.svn8 Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck Copyright (C) 2005-2019 Christian Schoenebeck Binary built: Mar 11 2019 Detected features: MMX SSE SSE2 Automatic Stacktrace: Off Creating Sampler...OK Registered sampler engines: 'GIG','SF2','SFZ' Registered MIDI input drivers: MME Registered audio output drivers: ASIO Loading instrument editor plugins...OK Registered instrument editors: 'gigedit' Registered internal effect systems: LADSPA Could not scan LADSPA effects: library path 'C:\Program Files\ladspa' doesn't exist Registered internal effects: 0 Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind server socket, retrying for 180 seconds...gave up! If try to open the qsampler.exe stand-alone app, I get the following error: --------------------------- qsampler.exe - System Error --------------------------- The code execution cannot proceed because Qt5Network.dll was not found. Reinstalling the program may fix this problem. --------------------------- OK --------------------------- (reinstalling the program didn't fix the issue). If I open JSampler, it complains about not being able to find javaw.exe (even though I added the javaw.exe folder to the Windows path variable and restarted the computer). However, I can manually browse to javaw.exe at each start up and JSampler opens. When it opens I get the following error message: "Connecting to LinuxSampler: Can't establish connection" David On Thu, May 23, 2019 at 10:51 AM Christian Schoenebeck < sch...@li...> wrote: > On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote: > > I'm having trouble getting LinuxSampler to run as a plugin within Ardour > on > > Windows 10. > > > > Here's the error message as reported by Ardour: > > The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be > located > > in the dynamic link library C:\Program > > Files\Steinberg\VstPlugins\LinuxSampler64.dll. > > Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib > already > been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS > VST > plugin later on). > > Does the LS stand-alone app run? > > CU > Christian > |
|
From: Christian S. <sch...@li...> - 2019-05-24 15:39:24
|
On Donnerstag, 23. Mai 2019 14:06:51 CEST David Bolton wrote: > Here's the messages I get when I launch linuxsampler.exe from the command > line: > > C:\Program Files\LinuxSampler\64>linuxsampler.exe > LinuxSampler 2.1.0.svn8 > Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck > Copyright (C) 2005-2019 Christian Schoenebeck > Binary built: Mar 11 2019 > Detected features: MMX SSE SSE2 > Automatic Stacktrace: Off > Creating Sampler...OK 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. Opinions? > Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind > server socket, retrying for 180 seconds...gave up! That error is probably because the LSCP server crashed with your VST plugin. Rebooting should fix that issue. > If try to open the qsampler.exe stand-alone app, I get the following error: > > --------------------------- > qsampler.exe - System Error > --------------------------- > The code execution cannot proceed because Qt5Network.dll was not found. > Reinstalling the program may fix this problem. I just fixed that in our Windows installer scripts. So when you download the latest installer, that error should be gone now. > If I open JSampler, it complains about not being able to find javaw.exe > (even though I added the javaw.exe folder to the Windows path variable and > restarted the computer). However, I can manually browse to javaw.exe at > each start up and JSampler opens. When it opens I get the following error > message: "Connecting to LinuxSampler: Can't establish connection" No idea about that one. I have to add, I am actually no longer using Windows for several years, same applies to Java. CU Christian |
|
From: David B. <dav...@gm...> - 2019-05-24 20:53:27
|
Christian, Thank you for your detailed response. 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. > I will pass this information along to Ardour via my original post: https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12 > > Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind > > server socket, retrying for 180 seconds...gave up! > Rebooting fixed the issue as you suggested. > > qsampler.exe - System Error > > I just fixed that in our Windows installer scripts. So when you download > the > latest installer, that error should be gone now. > Thank you. The new version of qsampler opens without errors. I had a little trouble with setting up the audio device. Qsampler didn't explain why (except messages like "AudioOutputDeviceAsio (errno=100)" and " lscp_get_audio_device_info: DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't find any ASIO-capable sound card. Make sure you have an ASIO driver installed for your sound device. If you are using a consumer sound card that does not provide an ASIO driver to be installed, then consider installing an alternative like ASIO4ALL." I installed ASIO4ALL and it appeared to work well with LinuxSampler (I could loads the instrument samples and qsampler reacted to MIDI signals (with the green flashing light). Maybe there's a problem with ASIO4ALL and my sound card or setup. I tried rebooting, but still no sound. I can try on a different machine later. > > If I open JSampler, it complains about not being able to find javaw.exe > > When it opens I get the following error > > message: "Connecting to LinuxSampler: Can't establish connection" > > No idea about that one. I have to add, I am actually no longer using > Windows > for several years, same applies to Java. > These errors have gone away now. In the meantime I have another sampler working on Windows, but I'm happy to continue testing if needed. David |
|
From: Christian S. <sch...@li...> - 2019-05-25 11:53:28
|
On Freitag, 24. Mai 2019 15:53:08 CEST David Bolton wrote: > 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. > > I will pass this information along to Ardour via my original post: > https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12 Yes, I see, expected old answer from their side on this issue. We are in 2019, and process separation for audio plugin scales well even on iOS (which even wraps that into a virtualized container). I mean these days even nested virtualization starts to be come a topic, which is far more expensive than just process separation. The thing that they probably don't see is that process separation for plugins is usually done by using *one* process for all instances of one particular plugin. So both resource consumption, as well as the required amount of context switches is far less than the typical performance calculation that I read from Ardour developers several times before. It usually requires 2 context switches per period for all instances of one plugin, no matter how many tracks you have on DAW side, because a plugin like LS is not an insert effect. And the argument that process separation was even unprofessional is not rational. Logic supports _optional_ process separation for AU plugins on macOS already. If you add this feature as optional setting per plugin then nobody gets hurt. But I don't expect their opinion to change on this issue any time soon. Potential library conflicts is an issue when only supporting in-process plugins, which I don't expect to become less of a problem in future. Just take the Gtk libs as an example: Gtk currently consists of around 24 separate libraries, many of them are not even designed for static linking. They are loading modules for core functionalities at runtime (plus various resources with absolute pathes) which cannot be linked statically with stock gtk, at least not without heavily patching them (and heavy continuous maintenance of the gtk libs on our side). Another fact is: plugins may crash; some(times) more, some(times) less. From usability point of view it is just contempoary to accept that this may indeed happen, and that this should not tear down the entire DAW (like it is inevitable with in-process plugins), only the causing plugin should crash, and the user should get a clear error message by the DAW which plugin crashed, and asking the user whether the plugin shall be reloaded. > Thank you. The new version of qsampler opens without errors. I had a little > trouble with setting up the audio device. Qsampler didn't explain why > (except messages like "AudioOutputDeviceAsio (errno=100)" and " > lscp_get_audio_device_info: > DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more > instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't > find any ASIO-capable sound card. Make sure you have an ASIO driver > installed for your sound device. If you are using a consumer sound card > that does not provide an ASIO driver to be installed, then consider > installing an alternative like ASIO4ALL." I hooked off from Windows years ago, and the current ASIO driver on LS side are more than 10 years old. So yes, there are certainly things to be improved on that driver. Probably there is even a better alternative than ASIO4ALL nowadays. Maybe people still working on Windows know more on that. > > > If I open JSampler, it complains about not being able to find javaw.exe > > > When it opens I get the following error > > > message: "Connecting to LinuxSampler: Can't establish connection" > > > > No idea about that one. I have to add, I am actually no longer using > > Windows > > for several years, same applies to Java. > > These errors have gone away now. I assume that's because you changed the PATH variable by using Windows' system settings graphical user interface, which requires a reboot for the PATH variable change to become effective. Next time you can also set the PATH variable immediately without rebooting from the terminal by doing: SET PATH=%PATH%;C:\yournewpath That way you can experiment with PATH issues more effectively. > In the meantime I have another sampler working on Windows, but I'm happy to > continue testing if needed. No problem! As you can see, the Windows version of LS should probably receive better maintenance. However since I am not using Windows anymore, it is not my personal focus. I mean I try to fix reported issues wherever I can, but beyond minor changes (like the missing Qt5Network DLL discussed here) it usually requires testing on Windows of course as well, so ... :) CU Christian |
Thanks for helping keep SourceForge clean.
X