We also appreciate if you make donations to our regular member Boris Gotsulenko as he is going through ard times and needs some financial support. The current LSP UI/UX design you see is the result of his hard work.
This is a pretty heavy release and contains many new features for different plugins and some minor bug fixes:
Added experimental support of UI for MacOS using FreeType and Cairo libraries. Contributed by Marvin Edeler.
Implemented human-friendly preset management in the pluginās UI.
VST3 plugin state format changed, not backward-compatible with previous versions of plugins. Downgrading version may cause plugin state loss.
Added AHDBSSR (Attack, Hold, Decay, Break, Slope, Sustain, Release) envelope control over loaded samples in Sampler and Multisampler plugin series.
Added DC offset control for Clipper and Multiband Clipper plugin series.
Added frequency linking button to the Phaser plugin series that allows to link minimum and maximum LFO frequencies and to keep logarithmic frequency range being constant.
Added support of linear axis for frequency in Spectrum Analyzer plugin series.
Added frequency inspection mode to the Spectrum Analyzer plugin series activated by āInspectā button or Ctrl + Left Mouse Button on the graph.
Added support of minimum-phase filter mode for Loudness Compensator plugin series.
Added āM/S Linkā and āS/C Linkā buttons to LeftRigth and MidSide versions of following plugins:
Equalizers: Parametric Equalizer and Graphic Equalizer;
Crossover plugin.
Added audio channel pre-mixing controls for the following plugins:
Compressor, Dynamics Processor, Expander, Gate and Limiter;
Multiband plugins: Compressor, Dynamics Processor, Expander, Gate and Limiter;
GOTT Compressor.
Extended collection of built-in rooms for Room Builder plugin series by Boris Gotsulenko aka borT.
Added exciter-like effect presets for Phaser plugin series contributed by Attila Schler.
Added possibility to automatically play samples when navigating file list.
Added command line option for JACK that allows to specify client name.
Some bugfixes and improvements in VST3 plugin format, now UI works for editorhost demo application from the Steinberg VST3 SDK.
Additional optimizations of 3D space mathematics with AVX instruction set.
Fixed improper AVX-512 optimization for lanczos kernel genration function which could cause improper resampling of audio files and yield some plugins to not to work properly.
Fixed bug in frequency split editing for Mid/Side and Left/Right versions of Crossover plugin.
Fixed bug in Mid/Side conversion of stereo signal on 32-bit and 64-bit ARM processors. Contributed by Asahi Lina.
We also appreciate if you make donations to our regular member Boris Gotsulenko as he is going through ard times and needs some financial support. The current LSP UI/UX design you see is the result of his hard work.
The choice depends on your host/DAW. It is a good choice to select the specific plugin format depending on which plugin format your host supports the best.
I always pick VST3 first if available, itās the most commonly used and widely available cross-platform format. I know I make LV2 people annoyed with this but I only use LV2 if it is the only choice for a Plugin and to be fair there are indeed many top-shelf LV2ās. Even though LV2 can be compiled for other platforms it is not a commonly accepted format on anything but Linux and if I ever want to change platforms or collaborate with Users on Win/Mac then VST3 is the best bet to preserve a proven effects chain and give the best potential for session continuity.
Yes, I was aware of those issues and that environment also factors into my decisions about formats. A personal thank you for the tremendous amount of work and maintenance you and your colleagues have done on LSP, you should take some pride in what youāve accomplished! I have responded to your request for Boris and hope others will do the same, I hope for many reasons that things will change so you yourself can receive the support you deserve.
LSP plugins are great but I donāt get the idea behind making so many āclonesā that differ only in quantity or presence of certain parameters or functions (eg. EQ ranges). Thatās weird imho and creates a lot of confusion especially for less experienced users when it comes to choosing the right plugin.
Are you planing to add a ādynamicā feature to the EQs? Thx.
I have responded to your request for Boris and hope others will do the same
@GMaq thank you for your support! We very appreciate it!
Also if you ask any other plugin developer, they prefer a stable SDK.
Hi @x42 . Evolving SDK doesnāt mean it will be unstable. And CLAP is a good example of how experimental things become stable ones. Moreover, you always can get an adequate feedback from CLAP maintainers within few days. All this is what I would like to see in LV2, too. Again, I raise both hands for evolution of open standards. Otherwise they will be far away behind the commercial ones.
I donāt get an idea behind making so many āclonesā that differ only in quantity or presence of certain parameters or functions (eg. EQ ranges)
@skygge This is done for some historical reasons where the LSP UI was not so powerful. Weāre planning to reduce plugin variations but it will force us to deprecate current plugins or at least freeze them and decline any support of them.
LV2 is certainly a format worth preserving. I wonder why CLAP was created in the first place. Why not just develop LV2 further through collaboration? We also need open standards, not closed ones. They benefit all of humanity. Because we canāt forever stay in our own caves and fight each other. Peace and Linux
There are several reasons. According to what I see in CLAP, it is a good try to replace and extend the proprietary VST3 format. Many solutions introduced in VST3 are pretty clearly reflected in CLAP, and sometimes CLAP exactly repeats the VST3 standard.
If we compare CLAP against LV2, the last has too much overhead and steep learning curve. At least consider TTL files and Atoms which were almost never used by any other plugin format. Yes, it allows to scan plugins without loading shared object files but regular users never cared about it. LV2 states that the DSP part of the plugin can be controlled by UI part of plugin from another host but finally we find out that binary atom messages are not portable between systems with different endianess. So to have this ability, you need to perform serialization and deserialization of Atom messages or their transform āon the flyā.
And, moreover, the overall relationship between host developers, plugin developers and plugin standard maintainers can be explained in a simple example: when you open a ticket about extending CLAP standard, it always turns into discussion with argued answers while opening a ticket in LV2 yields to āimplement this in host first, then weāll maybe add it to standardāā¦ for plugin developer, huh. And after that instead of explaining in the standard of how to do some thing in a right manner, we get set of LV2 extensions doing same thing in multiple manners. And after this all this stuff should be supported by host and plugin developers.
My long public discussion about this with David Robillard where one point was that I offered him to delegate the maintenance of LV2 to community was cleaned and closed. With such relation, where one person decides what to bring into the standard and what not, I can not consider LV2 being an open standard.
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
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.
ā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.ā
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.
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
