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
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
