In order for CLAP to succeed where LV2 has not so far, it will need to offer some compelling capability and a smooth transition from VST. It’s a monetary decision.
Actually, there are still a lot of devs out there hesitant about VST3, so provide an alternative format with a Vst3 wrapper and I think loads of devs will consider it just to avoid having to code VST3 and still be able to run in cubase.
But the vst3 wrapper concept won’t solve my own complaint about vst3 which is actually technical in nature, which is that midi is fundamentally flawed in vst3. A vst3 wrapper around CLAP or anything else would not solve that problem unless/until hosts actually support that new format directly.
Back to what I said earlier, hosts won’t support CLAP or LV2 or any other format unless there is some compelling reason to.
Bitwig team wants CLAP in order to further expand their modulate-everything paradigm. I doubt that alone will be compelling enough for other daws to add it. But the multi threading support might be.
Reports are that some devs were able to convert their vst plugins to CLAP in a matter of hours. If the work required to add CLAP hosting is similarly trivial, and if something like better core usage becomes blazingly obvious in bitwig, users will start asking other hosts to add CLAP for that “compelling” reason. If it’s easy to add then it will be added if there is a compelling reason. Otherwise the status quoa of vst will continue indefinitely for the same reason Steinberg has struggled to get wider adoption of vst3
About CLAP
-
- KVRAF
- 1972 posts since 14 Mar, 2006
Licensing issues could also become a compelling reason. Most mainstream hosts I don’t think are too concerned about that because most of them already have both vst2 and vst3 licenses and there are already so many devs and products available under those licenses that there is little compelling motivation for them to spend any time on that fact alone, to add CLAP hosting support.
As a small plugin dev who can’t get vst2 license and has midi problems with VST3; there is a huge compelling reason for me to develop for CLAP. But only when there enough hosts supporting it. And that is the chicken or egg problem which we have yet to see how it will play out.
As a small plugin dev who can’t get vst2 license and has midi problems with VST3; there is a huge compelling reason for me to develop for CLAP. But only when there enough hosts supporting it. And that is the chicken or egg problem which we have yet to see how it will play out.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50
-
- KVRist
- 73 posts since 25 Sep, 2004 from Galisteo, NM, USA
I completely get the "It isn't and it wont." part, and I am no way trying to alter that beyond my initial comment upthread that this is in some ways a little depressing.
The stuff I am arguing about is a bunch of falsehoods about LV2, plugin APIs, what CLAP (or any plugin format) can offer the world, Linux audio, etc. etc.
The stuff I am arguing about is a bunch of falsehoods about LV2, plugin APIs, what CLAP (or any plugin format) can offer the world, Linux audio, etc. etc.
-
- u-he
- Topic Starter
- 28065 posts since 8 Aug, 2002 from Berlin
I'm not sure I get the point.
The issue we're addressing is that hundreds if not thousands of developers still have a development environment built upon a standard that is obviously going to cease to exist. Like us for instance, we have a QA toolchain with automated testing tools etc. built around VST2. We can not move it to VST3 because VST3 does not support MIDI, but MIDI is the protocol our test suite is based upon. We can not move it to AU because AU does not support Windows or Linux. So we're moving it to CLAP instead.
Some other developers have it worse even, they are building their whatever formats by wrapping their VST2 codebase to whatever else. They will need to refactor big time, one day. The design of CLAP makes it pretty easy to move the VST2 base to CLAP, and adapt the CLAP base to other formats. The reason it's simple is that there isn't a framework or library or any other dependency, just a plain set of very plain functions and objects. I think it's easier than VST2 even because it doesn't have an opcode dispatcher and the debug labyrinth it poses. Simplicity is key here.
Supporting a new format is something people absolutely don't *want* to do, but there's compelling reasons to believe that they will *have* to. So they want it to be a task that's manageable, and with CLAP they might feel it is.
The issue we're addressing is that hundreds if not thousands of developers still have a development environment built upon a standard that is obviously going to cease to exist. Like us for instance, we have a QA toolchain with automated testing tools etc. built around VST2. We can not move it to VST3 because VST3 does not support MIDI, but MIDI is the protocol our test suite is based upon. We can not move it to AU because AU does not support Windows or Linux. So we're moving it to CLAP instead.
Some other developers have it worse even, they are building their whatever formats by wrapping their VST2 codebase to whatever else. They will need to refactor big time, one day. The design of CLAP makes it pretty easy to move the VST2 base to CLAP, and adapt the CLAP base to other formats. The reason it's simple is that there isn't a framework or library or any other dependency, just a plain set of very plain functions and objects. I think it's easier than VST2 even because it doesn't have an opcode dispatcher and the debug labyrinth it poses. Simplicity is key here.
Supporting a new format is something people absolutely don't *want* to do, but there's compelling reasons to believe that they will *have* to. So they want it to be a task that's manageable, and with CLAP they might feel it is.
-
- KVRist
- 73 posts since 25 Sep, 2004 from Galisteo, NM, USA
Urs - although I don't 100% agree with your assessment of LV2 vs. CLAP, I do fully recognize that you have an informed, good faith position, and I'm not trying to argue against it.
-
- u-he
- Topic Starter
- 28065 posts since 8 Aug, 2002 from Berlin
I personally don't even have any technical assessment of LV2. I would have to ask Alexandre about his experience porting our stuff back then, and any insights he has in today's state. I have not written a single line of code to support it, I wouldn't know.
My impression is simply that it has not flourished outside of the Linux community, nor have many commercial developers adopted it. I have a similar impression of VST3, where I can not pinpoint any single technical aspect as the reason for people's reluctance to adopt it. I don't really want to conduct a deeper research into this either, I would like to think that the people who have stake in this have already done that. Or at least, it's in their interest, e.g. if they think that something like CLAP has the potential to depress them. If there are efforts to change this, they're not obvious to me. With VST3 my impression is that the stakeholders would rather keep quiet about things. Wit LV2 my impression is that the group of people who could change things is abstract, i.e. what I meant about the absence of a governing body, and maybe nobody feels responsible to do anything, IDK.
My impression is simply that it has not flourished outside of the Linux community, nor have many commercial developers adopted it. I have a similar impression of VST3, where I can not pinpoint any single technical aspect as the reason for people's reluctance to adopt it. I don't really want to conduct a deeper research into this either, I would like to think that the people who have stake in this have already done that. Or at least, it's in their interest, e.g. if they think that something like CLAP has the potential to depress them. If there are efforts to change this, they're not obvious to me. With VST3 my impression is that the stakeholders would rather keep quiet about things. Wit LV2 my impression is that the group of people who could change things is abstract, i.e. what I meant about the absence of a governing body, and maybe nobody feels responsible to do anything, IDK.
-
- Banned
- 3564 posts since 22 Aug, 2019
Stumbled upon CLAP in another thread...Urs wrote: ↑Tue Jan 18, 2022 5:08 pm I'm not sure I get the point.
The issue we're addressing is that hundreds if not thousands of developers still have a development environment built upon a standard that is obviously going to cease to exist. Like us for instance, we have a QA toolchain with automated testing tools etc. built around VST2. We can not move it to VST3 because VST3 does not support MIDI, but MIDI is the protocol our test suite is based upon. We can not move it to AU because AU does not support Windows or Linux. So we're moving it to CLAP instead.
Some other developers have it worse even, they are building their whatever formats by wrapping their VST2 codebase to whatever else. They will need to refactor big time, one day. The design of CLAP makes it pretty easy to move the VST2 base to CLAP, and adapt the CLAP base to other formats. The reason it's simple is that there isn't a framework or library or any other dependency, just a plain set of very plain functions and objects. I think it's easier than VST2 even because it doesn't have an opcode dispatcher and the debug labyrinth it poses. Simplicity is key here.
Supporting a new format is something people absolutely don't *want* to do, but there's compelling reasons to believe that they will *have* to. So they want it to be a task that's manageable, and with CLAP they might feel it is.
What do you mean VST3 does not support Midi?
Even after 14 years, VST3 never really caught on. I still use VST2 stuff. With Retrologue 2 the VST2 version even has a big advantage: one can stack several instances into a single DAW rack, the VST3 version has an additional audio input knob, which somehow prevents stacking several instances.
I don't like Steinberg, I hope that CLAP thingy will be a success. The more developers there are that are openly willing to support it early on, the faster it will become a standard.
-
- KVRAF
- 23102 posts since 7 Jan, 2009 from Croatia
VST3 has an abstraction of MIDI, but it doesn't work with the raw MIDI stream.
-
Super Piano Hater 64 Super Piano Hater 64 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=491312 - KVRist
- 376 posts since 24 Jan, 2021
-
- KVRAF
- 23102 posts since 7 Jan, 2009 from Croatia
You don't say.
-
- KVRist
- 73 posts since 25 Sep, 2004 from Galisteo, NM, USA
There have also been decades of complaints about the limitations of MIDI (it's keyboard orientation, lack of resolution for controllers, and lots more). Some of the have been addressed in MIDI 2.0, which is even less well supported than VST3 (Odd. I mean, the whole electronic music ecosystem has been based on Midi for decades...
) and the complaints have given rise to proposals to use entirely different protocols.VST3 removes the MIDI protocol from the core of the plugin API and replaces it with Steinberg's attempt at a "music performance description API".
-
- KVRAF
- 9133 posts since 6 Oct, 2004
@dawhead:
I was not commenting on 'who was first' or 'who was best', merely stating actual experiences. I also used fst on a regular basis, because for me, it was great.
Everybody knew then, and knows now, that wine updates can break things, and sensible people just don't update willy nilly.
No point blathering on about the obvious.
I did not accuse 'you' of ridiculing wine, but plenty of people have ridiculed it, whether you know of them or not. And misconceptions about current wine performance are still
very common.
Regarding coding, I have read discussions in the past comparing vst2 and lv2, with coders presenting difficulties and deficiencies in each, that they felt needed alternatives.
Your defensiveness and insulting attitude in general, will do much more to insure that clap succeeds, than your arguments against it will ever do to inhibit it.
And for the peanut gallery, I have purchased two Harrison Mixbus licenses, the commercial extract of Ardour, for lack of a precise inner-knowledge of the entanglement, and a paid upgrade, each as a potential support of the Ardour project, not because I use or like Ardour, but because there are many promising artists in actual poverty, for whom Ardour in linux on a rejected but still working older computer, may be the only way to get started in computer based music.
I was not commenting on 'who was first' or 'who was best', merely stating actual experiences. I also used fst on a regular basis, because for me, it was great.
Everybody knew then, and knows now, that wine updates can break things, and sensible people just don't update willy nilly.
No point blathering on about the obvious.
I did not accuse 'you' of ridiculing wine, but plenty of people have ridiculed it, whether you know of them or not. And misconceptions about current wine performance are still
very common.
Regarding coding, I have read discussions in the past comparing vst2 and lv2, with coders presenting difficulties and deficiencies in each, that they felt needed alternatives.
Your defensiveness and insulting attitude in general, will do much more to insure that clap succeeds, than your arguments against it will ever do to inhibit it.
And for the peanut gallery, I have purchased two Harrison Mixbus licenses, the commercial extract of Ardour, for lack of a precise inner-knowledge of the entanglement, and a paid upgrade, each as a potential support of the Ardour project, not because I use or like Ardour, but because there are many promising artists in actual poverty, for whom Ardour in linux on a rejected but still working older computer, may be the only way to get started in computer based music.
-
- KVRAF
- 9133 posts since 6 Oct, 2004
It hasn't flourished inside the linux community, either.
It is merely tolerated, until replaced by something better.
-
- KVRAF
- 9133 posts since 6 Oct, 2004
@dawhead:
I offer a friendly useful challenge. Get X42 and any other dev you trust, to create a new useful plugin from ground up, in three versions, lv2, vst-2-or-3, and then clap, and post their honest opinion of the workflow and results here, and at
www.linuxmusicians.com
and at
https://forum.harrisonconsoles.com/forum-7.html
I'll then donate $50 to the Red Cross, and I encourage others here join in, to a charity of their choice. (needless to say, people are choking in volcanic ash, freezing, fighting diseases etc etc while we debate 1st-world issues)
I offer a friendly useful challenge. Get X42 and any other dev you trust, to create a new useful plugin from ground up, in three versions, lv2, vst-2-or-3, and then clap, and post their honest opinion of the workflow and results here, and at
www.linuxmusicians.com
and at
https://forum.harrisonconsoles.com/forum-7.html
I'll then donate $50 to the Red Cross, and I encourage others here join in, to a charity of their choice. (needless to say, people are choking in volcanic ash, freezing, fighting diseases etc etc while we debate 1st-world issues)
