Re: [Linuxsampler-devel] Possible bug or by design [LV2]

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

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.

> However, once I exit Ardour/Mixbus, it kills the linuxsampler
> process with it and leaves Qsampler hanging with a "broken pipe".

Correct, which you can just ignore. When you reload the session in your DAW, 
QSampler should automatically reconnect to the sampler backend running 
*within* your DAW's process. But that's configurable in QSampler.

> Loading the LV2 plugin on it's own does not load a linuxsampler
> background process. Yet it kills it upon exiting.

Because the sampler backend is not running in its own process, like described 
above. So if the DAW application stops the process where the plugins are 
running in, it also stops the sampler backend as it runs within the same 
process.

> 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