x42

x42, 1 month ago

@amadeus the GUI is not encumbered by DSP constraints. Then again almost all authoring tools do not use the system’s theme. LV2 plugins can use the host‘s colour theme. This looks better compared to than just generic light/dark modes. Sadly not many plugins support this.

x42, 6 months ago

@amadeus

I have shipped x-platform VSTs via https://github.com/x42/lv2vst in the past. These days few users who need VST, wrap them themselves or use @falktx Ildaeil to do so.

While I like, and was involved with CLAP since 2014, there is nothing CLAP offers for those plugins that LV2 does not already do.

x42, 5 months ago

@amadeus I don't have an answer. Often curiosity is what motivate me, but that does not apply here.

Maybe there is also hope for Bitwig to add LV2 support?!

Reaper has added it a while ago, JUCE now supports LV2, as does Audacity. Not to mention the usual suspects, Ardour, Mixbus, QTractor, Carla, zrythm etc have supported it for a long time.

x42, 5 months ago

@amadeus

1. don't know, don't care.

2. LV2 has the maxim "if the host can do it, the should should do it". It takes work off plugin devs and has lead to various neat features (host provided worker, host provided threads), many of which we copied to CLAP.

LV2 builds on existing standards and is more rigorous computer science, rather than hands-on. -- While this appeals to some, it likely hindered widespread adoption.

Over VST, LV2 has similar advantages as CLAP, notably performance related.

x42, 5 months ago

@amadeus @dreamer

From a user's perspective, you should not care what standard a plugin uses. They're all the same :)

From a development or project-management perspective it is very significant. Take mod.audio as example. Thanks to LV2's UI separation, they could easily add HTML GUIs to LV2 plugins without changing existing plugins (!) - something CLAP or VST does not support.

Inline displays in Ardour is another example.

Historically LV1/LV2 was the first cross platform standard (incl BSD)

x42, 7 months ago (edited 7 months ago)

@amadeus You do realize flatpaked plugins not only locks you into the flatpak ecosystem, but also constrains performance due to sandboxing, and can cause conflicts when loading plugins by 3rd party vendors?

x42, 7 months ago

@amadeus you can measure effects caused by sandboxing. Since it comes up regularly we have written about this at https://ardour.org/plugins-in-process.html

To prevent context switch overhead plugins need to reside in the same memory space with other plugins. This only works if a plugin does not have any external dependencies. Since plugins may require different conflicting libraries, they have to be statically linked to be loaded into the same process.
Flatpak however bundles shared libraries hence the sandbox.

x42, 7 months ago

@ercanbrack @amadeus Most major Linux plugin vendors just provide a tar or zip with an installer or file to copy (u-he, vital, decentsampler overtonedsp, auburnsounds, pianoteq, etc).

The general problem with flatpak is that flatpak'ed plugins can only be used a flatpak'ed DAW (and vice versa).

While, say, RPM packaged plugins on the same system do not have this limitation if the flatpaked plugin-host has read-access to the file-system.

x42, 7 months ago

@ercanbrack The poll by @amadeus is "flatpak" or "other" you cannot pick both :)

x42, 7 months ago

@amadeus That is great news!

We've come full circle.

In the early 2000s (Saffire) they provided free hardware to those who write Linux drivers.

That changed around 2010.

When I reverse engineered the Scarlet Gen 1, and wrote the kernel driver they were not very helpful. I got a 18i6 from a friend who was frustrated it didn't work on Linux. Focusrite showed little interest when I contacted them.

It's 2023, why can't they use a web interface, and still require custom drivers for the mixer?

x42, 10 months ago (edited 10 months ago)

@prokoudine I tried to imagine you forking and rebranding it, and stopped after reaching The PIMP (Prokoudine Image Manipulation Program) :)