Thanks for the clarification.
As someone who was involved with creating both LV2 and CLAP, the reason for the latter was NIH and the need for an in-house standard at a host developer’s. Since it is the newest it thankfully took a lot of inspiration from LV2 and VST3 (except for LV2’s clean DSP/UI separation and VST3’s automation and MIDI controls).
I don’t buy the “steep learning curve” for LV2 argument. It’s not more complicated than VST3, just different, and more computer-sciencey. Since JUCE added support for LV2 and REAPER added host support things have been smooth sailing.
As plugin dev I still very much prefer LV2 over CLAP and VST3 for various technical reasons. Interface wise it’s also still the most efficient.
I also only every had interesting discussions with the LV2 maintainer. The discussion style might be seemingly more aggressive, yet for technical discussions that often leads to the best result, and it’s a much cleaner standard for that.
Different people prefer different styles. So soon we’ll have yet another standard 
3 Likes
I largely agree, even though I’m just a user – not a developer. I’d really like to learn how to make plugins, especially in the LV2 format, but so far my time has mostly gone into recording and mixing.
That said, I have huge respect for you developers. The expertise and dedication you bring to these standards and tools is incredibly valuable. For someone like me with a simpler mindset, it often feels like fewer formats and standards would be better than constantly introducing new ones. Simplicity is beautiful – and it might also give us users more time to focus on making music rather than figuring out the tech.
1 Like
“CLAP also takes into consideration some criticism that LV2 received from developers over the years, and thus it has neither RDF 1.1 Turtle metadata (too lengthy to write by hand, requires build system enhancement when automated), nor versioned extensions (dealing with those is cumbersome). There are even more LV2-specific issues that CLAP does not appear to have, like heavy, under-documented APIs, design limitations that even the LV2 maintainer thinks call for a partial API deprecation, and more.”
1 Like
Obligatory disclaimer: I don’t have a beef with LV2. In fact, I don’t really have feelings about plugin formats. When the software works, it works. When it doesn’t, the fault is usually not with the SDK.
That’s what I’ve seen developers say time and time again. But you don’t have to trust (or distrust) words, when actions speak so much louder.
If you go shopping for a proprietary DAW or a proprietary plugin for Windows, which one are you more likely to find: one with support for LV2 or one with support for CLAP? The answer is CLAP.
In other words, people who don’t have your kind of involvement with LV2 see competing standards and tend to choose CLAP over LV2 (and VST3 over CLAP). Some developers who supported LV2 before have started dropping the LV2 support in favor of CLAP (Surge XT, Vital), while the reverse doesn’t seem to be happening.
It looks like the ease of development and wider proprietary host support are more important to 3rd-party plugin developers than things like DSP/UI separation. They don’t even mind having to use a JUCE extension to build CLAP, which is not necessary for LV2.
Personally, I don’t think CLAP will phase LV2 out on Linux any time soon, and I’ll happily continue using LV2 plugins. But LV2 has been getting absolutely nowhere outside Linux since inception, and CLAP is clearly doing a far better job there.
5 Likes
Is there any way to transfer settings of the LV2-Version of the LSP-plugins to the VST3-Version? I have the strange problem here that I get a segfault as soon I open any LSP-plugin the second time. I can open e.g. an parametric eq, all fine. But if I open ANY other LSP-plugin the system crashes. This only happens in the LV2-version. With VST3 everything seems to work.
With other LV2 plugins this doesn’t occur.
I think it’s not really a LSP problem, more a libc problem. I’m on Manjaro Linux. I tried Kubuntu on a virtual machine, where it worked.
If it helps:
Sep 05 10:24:18 darcy kernel: ArdourGUI[2278]: segfault at 0 ip 000077cdb6308e31 sp 00007fff9d6dacf8 error 4 in libc.so.6[bfe31,77cdb626d000+172000] likely on CPU 2 (core 0, socket 0)
Sep 05 10:24:18 darcy kernel: Code: ff 0f 00 00 66 0f 60 c9 48 3d bf 0f 00 00 66 0f 60 d2 66 0f 61 c9 66 0f 61 d2 66 0f 70 c9 00 66 0f 70 d2 00 0f 87 ff 02 00 00 <f3> 0f 6f 1f 66 0f ef ed f3 0f 6f 67 01 66 0f 6f f3 66 0f 74 d9 66
Sep 05 10:24:18 darcy systemd-coredump[2343]: Process 2278 (ArdourGUI) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Sep 05 10:24:18 darcy systemd[1]: Started Process Core Dump (PID 2343/UID 0).
Sep 05 10:24:21 darcy systemd-coredump[2344]: [🡕] Process 2278 (ArdourGUI) of user 1000 dumped core.
Stack trace of thread 2278:
#0 0x000077cdb6308e31 n/a (libc.so.6 + 0xbfe31)
#1 0x000077cd0d7707e4 _ZN3lsp2ws3glxL18check_gl_extensionEPKcS3_ (lsp-plugins-lv2ui.so + 0x5317e4)
ELF object binary architecture: AMD x86-64
You can export configuration from LV2 UI and import it in VST3 one.
Yes I can confirm this issue. I’m on CachyOS. Same issue with ZynAddSubFx LV2. VST working.
https://tracker.ardour.org/view.php?id=10003
But the issue only occurs in Ardour, no issues in Reaper or Qtractor.
@werner.back @axra Is is possible for you to obtain the stack trace of Ardour? It may be very helpful.
How do I do that? I just get the message “segmentation fault (core dumped)”, but where is the dump?
They also say that about VST3
1 Like
cat /proc/sys/kernel/core_pattern
Usually a file called core in the current working directory, but some distros set a dedicated path or redirect it.
Note that the core file only applies to your system. You then have to load it into gdb to get a backtrace: see Debugging Ardour | Ardour DAW
I find it much easier to directly run Ardour in gdb instead.
Selfcompiled Version of both Ardour(8.12 from git) and LSP (current git). I created 2 Tracks and put a parametric EQ on each of them. Opened the first one and made some adjustment and closed it. Then I opened the second EQ, the window appears, but then the crash happens.
Output fom gdb is here:
File
So …
#0 __strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:41
#1 0x00007fff4b102144 in lsp::ws::glx::check_gl_extension(char const*, char const*) () from /home/werner/.lv2/lsp-plugins.lv2/lsp-plugins-lv2ui.so
#2 0x0000000000000000 in ?? ()
@SadKo could it be that unloading the UI (lsp-plugins-lv2ui.so) causes it? Is there static init happening? That would explain why the VST3 is not affected.
The check of OpenGL extensions is performed at the start of UI when we’re creating OpenGL context of the window. The verification routine is the following:
I need the OpenGL string to perform the test.
@werner.back could you please build plugins with make config ... TRACE=1 option and uncomment this line:
In the log of LV2 plugins you will see the output of this command:
Compiling atm…but where do I find the log?
The log is written into /tmp/lsp-lv2ui.log.
Looks like second call of the glXQueryExtensionsString call returns NULL on your system. That’s strange and looks like a driver bug. Do you use XWayland or pure X11?
Please consider applying this patch:
I tried both (at login chose plasma-X11, also tried plasma-Wayland). With the patch applied, everything seems to work fine again, though.
Thank you very, very much!