[Solved] Removing pre-installed unlicensed pugins

[English Guy]

Hi

I would like to be able to blacklist or remove the unlicensed demo plugins that are installed with Mixbus and cannot find how. I can understand the reasons including for them, including collaboration, but I have no plans to collaborate, cannot afford them and I do find it disruptive to my workflow to load a plugin to find that I cannot use it.

many thanks
Guy

[Ben@Harrison]

Hi Guy,

What OS are you using? Generally speaking, you open the Mixbus application folder, find the libs/LV2 subfolder, and remove the items that you don't want.

[English Guy]

Hi Guy,

What OS are you using? Generally speaking, you open the Mixbus application folder, find the libs/LV2 subfolder, and remove the items that you don't want.

Hi Ben
Thanks, I have found it. Sorry I should have said I am using Debian Linux; the folder is /opt/Mixbus-4.0.703/lib/LV2/

Sorry - I am too used to doing all these things with apt. Thanks for your help.

[madmaxmiller]

Sorry - I am too used to doing all these things with apt. Thanks for your help.

Hi fellow Debian user
You could as well have ticked "hide" for the particular plugins in the plugin manager. That keeps them physically intact just in case but they don't pop up anymore unless you click "show hidden".

MMM

[English Guy]

Hi fellow Debian user
You could as well have ticked "hide" for the particular plugins in the plugin manager. That keeps them physically intact just in case but they don't pop up anymore unless you click "show hidden".

MMM

Hi there. Sorry if this OT but as you are a fellow Debian user, may I just ask, do use alsa or jack? I know alsa is recommended but jack works better on my system.

[madmaxmiller]

Hi there. Sorry if this OT but as you are a fellow Debian user, may I just ask, do use alsa or jack? I know alsa is recommended but jack works better on my system.

Jack all the way. You can't beat that flexibility.

MMM

[English Guy]

Hi there. Sorry if this OT but as you are a fellow Debian user, may I just ask, do use alsa or jack? I know alsa is recommended but jack works better on my system.

Jack all the way. You can't beat that flexibility.

MMM

Indeed , I also noticed that on an empty project the DSP load was 5% less with Jack than Alsa (but Alsa on Linux was still about 18% less than a more powerful machine on Windows ).

[x42]

Indeed , I also noticed that on an empty project the DSP load was 5% less with Jack than Alsa (but Alsa on Linux was still about 18% less than a more powerful machine on Windows ).

That's because jackd reports average load, while Mixbus' ALSA backen reports worst-case.
jackd can x-run (actual DSP load > 100%) while reporting a low average load.

JACK's routing capabilities are awesome but that aside, the built-in ALSA backend is not only a tad more effective (no context switch), but also allows to calibrate MIDI latency (jackd can't do that).

[English Guy]

Indeed , I also noticed that on an empty project the DSP load was 5% less with Jack than Alsa (but Alsa on Linux was still about 18% less than a more powerful machine on Windows ).

That's because jackd reports average load, while Mixbus' ALSA backen reports worst-case.
jackd can x-run (actual DSP load > 100%) while reporting a low average load.

JACK's routing capabilities are awesome but that aside, the built-in ALSA backend is not only a tad more effective (no context switch), but also allows to calibrate MIDI latency (jackd can't do that).

Thanks for that. A lot of my workflow uses the DAW synced to Hydrogen drum machine, unfortunately at the moment I cannot see a way to do that in Alsa (I am still trying I will post if I do!)

[johne53]

jackd reports average load

[...]

jackd can x-run (actual DSP load > 100%) while reporting a low average load.

I'm not sure that's true (not in Jack2 anyway). It only reports the average if all values are less than 95%. Otherwise, it reports the maximum value.

In the early days of Mixbus3, I remember us chasing the problem you described (x-runs occurring, even when the DSP reading was low). But it wasn't due to Jack. We were just reading the values too infrequently (i.e. very brief x-runs were slipping through unnoticed).