Thank you for you detailed explanation.
On 11/13/25 8:11 AM, Christian Schoenebeck wrote:
On Wednesday, November 12, 2025 7:49:44 PM CET Jim Hines wrote:
[...]
quite impressive having not used LS in a few years. However there is
something that just doesn't seem right with the LV2 plugin. If QSampler
is already running (and hosting linuxsampler 2.4.1) loading the LV2
plugin freezes both Ardour and Mixbus until Qsampler is exited therefore
also exiting linuxsampler, then Ardour/Mixbus will unfreeze and load the
LinuxSampler LV2 plugin. I can then load QSampler and everything is
fine.
This is the status quo: no matter if LV2, DSSI, VST or AU plugin, Linux,
Windows or Mac, the basic behaviour and usage procedure for LinuxSampler
plugins is the same, simply because they all share the same common plugin base
class (src/drivers/Plugin plus subdirs).
The plugin type specific code (under src/hostplugins) OTOH is very little and
just provides the glue code to the respective plugin specific API.
Current usage: First you load the LinuxSampler plugin instance(s) into the
host application of you choice. The first plugin instance automatically spawns
the sampler's backend (e.g. central C++ API control class "Sampler", sampler
engines, effects, editor plugins, drivers) *within* the plugin's process! The
first plugin instance also launches the LSCP server which binds to local TCP
port 8888.
From this point on you can use your sampler frontend of your choice (e.g.
QSampler GUI, Fantasia GUI, LSCP shell CLI) to setup the LinuxSampler plugin
instances for your current DAW session. The sampler frontends all communicate
via LSCP protocol on TCP port 8888 with the sampler backend.
The overall LinuxSampler plugin setup is automatically stored and restored
with your DAW's project. So you don't have to grab a frontend again just to
continue with a song. You just load the song in your DAW application next time
and that's it. You only need a frontend again if you need to make changes
obviously.
Maybe all we need is a LUA script within Ardour to be able to send lscp
scripts directly to the LV2/DAW instance of LinuxSampler. This could
potentially open up an entire world of possibilities including making
use of the instrument.db. But, with the current sandboxing of LUA within
Ardour, it may still not be possible. sigh.
This seems odd. Why
does the plugin not just connect to a running linuxsampler process if
found and leaves it running upon exiting? Also, why can't the LV2 plugin
connect to a remote instance of LS? This seems to defeat the purpose of
having a dedicated remote LinuxSampler server(s) which would be super
useful.
Because the plugins (or rather their shared plugin base class) are currently
requiring the sampler backend to be within the same process. The plugin just
calls the sampler's native C++ API to request it render audio and return that
audio buffer to the plugin.
Of course this could be changed by implementing IPC for transferring the audio
in real-time from a separate sampler backend process. But apparently nobody
cared enough to sit down and write that audio IPC transfer code. Plus it would
also bring certain disadvantages: e.g. the minimum latency possible is much
smaller if host, plugin and backend are within the same process.
The problematic would become worse of course if the sampler backend would even
run on another machine of course.
Everything is possible, but someone has to do it. ;-)
/Christian
Yes, I can see there could be some serious latency issues introduced by
something like this.
Jim
_______________________________________________
Linuxsampler-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
