LV2 vs CLAP

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: LV2 vs CLAP

Post by tramp »

robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm Like I said, DSP/UI separation is a good thing. Forced DSP/UI separation when there is no reason for it to be forced is not.
The reason will be remote control. And, while IT development moving forward, remote control becomes more and more significant (wasm). So, push out a new standard which ignore this requirements is, sorry, not a good thing. I guess I don't need to include the good old comic about evolving standards here.
robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm That only makes the API more cumbersome to use, because now you need to do things in a certain way that that make binding to the API more difficult or straight up impossible (depending on how enforced it actually is).


What? I cant see a difference here. A API is a API. I've to read and follow to get things done. It is not more difficult to follow a API which provide dsp/UI separation then follow one which don't force that. It's always the same. read, learn, follow. So, why do you think the API of Clap is easier to follow then the one of LV2? It's just a question of mindset.
robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm Good luck using plugins like Melodyne or B.Shapr without a GUI. Not all of a plugin's state can be captured through parameters. How would Vital's or Serum's wavetable editor work if the plugin didn't have a GUI?
Again, a trap you stepped in. It's not about headless plugins, it's about remote control. And, there wont be a single issue providing a remote control for B.Shapr, as it use atom ports instead instance access so all controls could be done from a third party window (given it knows what it does).

(PS:) but now that I've learned that open source developers may get paid when they implement Clap support, I may change my mind and revert all I said above. :lol:
https://www.kvraudio.com/forum/viewtopic.php?t=574861
On the road again.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: LV2 vs CLAP

Post by tramp »

robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm Like I said, DSP/UI separation is a good thing. Forced DSP/UI separation when there is no reason for it to be forced is not.
The reason will be remote control. And, while IT development moving forward, remote control becomes more and more significant (wasm). So, push out a new standard which ignore this requirements is, sorry, not a good thing. I guess I don't need to include the good old comic about evolving standards here.
robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm That only makes the API more cumbersome to use, because now you need to do things in a certain way that that make binding to the API more difficult or straight up impossible (depending on how enforced it actually is).


What? I cant see a difference here. A API is a API. I've to read and follow to get things done. It is not more difficult to follow a API which provide dsp/UI separation then follow one which don't force that. It's always the same. read, learn, follow. So, why do you think the API of Clap is easier to follow then the one of LV2? It's just a question of mindset.
robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm Good luck using plugins like Melodyne or B.Shapr without a GUI. Not all of a plugin's state can be captured through parameters. How would Vital's or Serum's wavetable editor work if the plugin didn't have a GUI?
Again, a trap you stepped in. It's not about headless plugins, it's about remote control. And, there wont be a single issue providing a remote control for B.Shapr, as it use atom ports instead instance access so all controls could be done from a third party window (given it knows what it does).

(PS:) but now that I've learned that open source developers may get paid when they implement Clap support, I may change my mind and revert all I said above. :lol:
https://www.kvraudio.com/forum/viewtopic.php?t=574861

Just for the case, most of my post above is sarcasms, I don't see any concurrency between LV2 and Clap. The only downside I see is that now, host developers have to implement a new standard support in order to suit there users. Plugin developers may chose what ever API they prefer, or, use a frame work which support them all (or most of them), but, at least, I ain't see Clap really as a step forward.
On the road again.
robbert-vdh
Established Member
Posts: 219
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 51 times
Been thanked: 92 times
Contact:

Re: LV2 vs CLAP

Post by robbert-vdh »

tramp wrote: Sun Jul 10, 2022 4:57 pm
robbert-vdh wrote: Fri Jul 08, 2022 3:18 pm That only makes the API more cumbersome to use, because now you need to do things in a certain way that that make binding to the API more difficult or straight up impossible (depending on how enforced it actually is).


What? I cant see a difference here. A API is a API. I've to read and follow to get things done. It is not more difficult to follow a API which provide dsp/UI separation then follow one which don't force that. It's always the same. read, learn, follow. So, why do you think the API of Clap is easier to follow then the one of LV2? It's just a question of mindset.
Well, it may just be a case of requiring a 'different mindset'. But can you imagine a developer with a large back catalog of plugins and hundreds of thousands of lines of code for their internal plugin framework redesign all of that just to accommodate a plugin API that forces them to work in a model that's incompatible with how their plugins work and have always worked? I could ask you a similar question. Why do you think writing a program that prints a listing of the current directory is easier in Python than in x86-64 assembly? After all, they're both programming languages, one just includes some high level abstractions to make things simple while the other is an open canvas that lets you implement those things yourself. With enough documentation you'd be able to write both programs, and it's just a matter of different mindsets.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: LV2 vs CLAP

Post by tramp »

robbert-vdh wrote: Sun Jul 10, 2022 5:20 pm But can you imagine a developer with a large back catalog of plugins and hundreds of thousands of lines of code for their internal plugin framework
Oh no, surly not. :lol:

After all, I wish Clap success. I've no bad feelings about it, just said what I miss, why I think it's not suitable to kill LV2 and why I prefer LV2 (as that was the topic about).
On the road again.
robbert-vdh
Established Member
Posts: 219
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 51 times
Been thanked: 92 times
Contact:

Re: LV2 vs CLAP

Post by robbert-vdh »

tramp wrote: Sun Jul 10, 2022 5:38 pm After all, I wish Clap success. I've no bad feelings about it, just said what I miss, why I think it's not suitable to kill LV2 and why I prefer LV2 (as that was the topic about).
Yeah I definitely agree, that's what I've been saying the beginning. :)
LV2 and CLAP can coexist perfectly fine and they fill different niches. There's no need for an 'LV2 vs CLAP'. They're both plugin APIs, but that's kind of where the similarities end. They were designed with different ideas and ideologies in mind, and they thus achieve their goal of being a plugin API in completely different ways. And as a computer scientist I completely understand why LV2 works the way it does. If you asked a random CS major or PhD to design a plugin API then they'd probably end up with something at least somewhat similar. I've just been trying to explain where some of the developer interest in CLAP comes from.
User avatar
sadko4u
Established Member
Posts: 987
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 360 times

Re: LV2 vs CLAP

Post by sadko4u »

tramp wrote: Sun Jul 10, 2022 4:57 pm The reason will be remote control. And, while IT development moving forward, remote control becomes more and more significant (wasm). So, push out a new standard which ignore this requirements is, sorry, not a good thing. I guess I don't need to include the good old comic about evolving standards here.
The main problem of lv2:Atoms is... That they don't deal with endianess. You can't control a little-endian machine from the big-endian machine and vice verse. I don't recall the place of my conversation with Drobilla but the final solution was that it's 'normal' and 'by design' and won't be fixed.
tramp wrote: Sun Jul 10, 2022 4:57 pm What? I cant see a difference here. A API is a API. I've to read and follow to get things done. It is not more difficult to follow a API which provide dsp/UI separation then follow one which don't force that. It's always the same. read, learn, follow. So, why do you think the API of Clap is easier to follow then the one of LV2? It's just a question of mindset.
LV2 has a steep learning curve. This is my personal opinion but it is one of the hardest plugin formats. We need to learn Turtle format, we need to learn lv2:Atom, we need to deal with multiple UI engines (X11/gtk2/gtk3/Qt etc) and so on. And, the second problem is, that LV2 has no up-to-date tutorials for writing plugins. All what we need we need to learn from other open source projects or ask directly in LV2 community.
LSP (Linux Studio Plugins) Developer and Maintainer.
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: LV2 vs CLAP

Post by j_e_f_f_g »

sadko4u wrote: lv2:Atoms don't deal with endianess.
omg. I had assumed they did, because it makes no sense to create a supposedly "transparent datatype wrapper" which is crippled by something as basic as endian issues. At the very least, a competently written standard would have chosen either little or big endian. Given this oversight, LV2 is just useless as a standard remote protocol.

So this is one more (of many) instances where LV2 has significant drawbacks that are completely undocumented. LV2 is a developer's nightmare.
LV2 has a steep learning curve.
I agree 100% with your statement above, and everything you said after it. It's pretty much the exact same as my analysis of LV2.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

Post Reply