Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[Christian S. <sch...@li...>]

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