linuxsampler-devel

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

[Jim H. <la...@gm...>]

Hi all,
This is my first post to this mailing list. I recently built the full 
latest version of the LinuxSampler suite for Fedora 41 (RPMs) and it's 
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. However, once I exit Ardour/Mixbus, it kills the linuxsampler 
process with it and leaves Qsampler hanging with a "broken pipe".

Loading the LV2 plugin on it's own does not load a linuxsampler 
background process. Yet it kills it upon exiting. 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.

Thanks,
Jim Hines

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

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

[Jim H. <la...@gm...>]

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