CLAP... thoughts?

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

pdxindy wrote: Tue Jun 21, 2022 1:44 pm
Pinku Eiga wrote: Tue Jun 21, 2022 1:36 pm If Bitwig continues doing things in this way, this can slow the adoption of the CLAP format. Nobody wants to lost his past projects in the transition.
Most user aren't going to uninstall the VST version and there is no need to. That is a self inflicted problem
Well, I'm masochist. I will sure uninstall the VST3 version, keeping only the CLAP one. Bitwig is the only DAW installed on my Mac. And I'm only using VST because Bitwig doesn't support Audio Units.

I think that CLAP should be the future for cross-platform projects, in conjunction with AUv3 for having a plugin architecture that lets you to translate your iOS plugins to desktop.

I'm still pissed for not having AUv3 support in Bitwig.

The MIDI features of AUv3 are incredibly powerful, and I was missing a lot of the great MIDI effects and sequencers available on iOS. This was a consequence of the MIDI limitations of the VST3 architecture, being the standard for cross-platform desktop projects.

I hope that the adoption of CLAP brings a flood of new dedicated MIDI effects to desktop.

Post

Pinku Eiga wrote: Tue Jun 21, 2022 2:01 pm
I'm still pissed for not having AUv3 support in Bitwig.

The MIDI features of AUv3 are incredibly powerful, and I was missing a lot of the great MIDI effects and sequencers available on iOS. This was a consequence of the MIDI limitations of the VST3 architecture, being the standard for cross-platform desktop projects.
The good side is that Bitwig is fantastic for midi fx and sequencing! :tu:

Post

aMUSEd wrote: Tue Jun 21, 2022 11:01 am
koalaboy wrote: Tue Jun 21, 2022 9:09 am Maybe we need an open-source equivalent to NKS....
Personally I think what we really need is for plugins to be designed with controllers and expression using controllers and keyboards in mind from the start, that don't just passively advertise to controllers what params are available for controlling but also interact with controllers to create the optimal param layout given the capabilities of that controller. Intermediate layers like NKS really shouldn't be needed, it's too clunky and creates a dependency on companies and users doing a lot of hard work in creating mappings and templates (and so much that can go wrong when plugins get updated). Maybe CLAP could make that possible?
Isn’t this one of the basic ideas behind Midi 2.0?
And regarding NKS, the basic idea is a good one, but its bound to a specific hardware. Usually I would think in sounds and not in which plugin does make that sound. It could be a way to simplify things. Within Bitwig I can do that on a personal level, but a standard (with a permissive license like CLAP has) would help a lot. It should be able to import NKS information though…

Post

Can't Bitwig already import NKS information?

BTW. Bitwig has a plugins (side) panel where you can manage missing plugins - never tried if one can switch to a different architecture there if the original used one is missing?

Cheers,

Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." · Rumi
UrbanFlow.art · Instagram · YouTube

Post

Pinku Eiga wrote: Tue Jun 21, 2022 2:01 pm
pdxindy wrote: Tue Jun 21, 2022 1:44 pm
Pinku Eiga wrote: Tue Jun 21, 2022 1:36 pm If Bitwig continues doing things in this way, this can slow the adoption of the CLAP format. Nobody wants to lost his past projects in the transition.
Most user aren't going to uninstall the VST version and there is no need to. That is a self inflicted problem
Well, I'm masochist. I will sure uninstall the VST3 version, keeping only the CLAP one. Bitwig is the only DAW installed on my Mac. And I'm only using VST because Bitwig doesn't support Audio Units.
Right now, it doesn't seem replacing VST3 with CLAP works, so you may be a masochist, but 1) hold your horses and wait for Bitwig to confirm they've got a working, automatic solution, or 2) start manually migrating your plugins first as they become available, then delete the VST3's. If you just start deleting VST3's on your own first, you're going to be in a for a world of hurt, and you won't have anyone to blame but yourself. Then again, that is the definition of masochism.

Post

Tj Shredder wrote: Tue Jun 21, 2022 2:07 pm
aMUSEd wrote: Tue Jun 21, 2022 11:01 am
koalaboy wrote: Tue Jun 21, 2022 9:09 am Maybe we need an open-source equivalent to NKS....
Personally I think what we really need is for plugins to be designed with controllers and expression using controllers and keyboards in mind from the start, that don't just passively advertise to controllers what params are available for controlling but also interact with controllers to create the optimal param layout given the capabilities of that controller. Intermediate layers like NKS really shouldn't be needed, it's too clunky and creates a dependency on companies and users doing a lot of hard work in creating mappings and templates (and so much that can go wrong when plugins get updated). Maybe CLAP could make that possible?
Isn’t this one of the basic ideas behind Midi 2.0?
I thought so too, but I don't think anyone has got hardware or software that implements this in any meaningful way yet. I certainly haven't seen it. This could end up being something in the MIDI 2.0 spec that no one ends up supporting. Or maybe I'm wrong and MIDI 2.0 will be huge and that aspect of it will ultimately deal with it. But I think you'd still need MIDI 2.0 hardware, a MIDI 2.0 host, and MIDI 2.0 plugins that all support this. We're just not there yet.

Would be great if CLAP could somehow solve for this with hosts acting as an intermediary between MIDI (1.x) hardware and plugins. Not sure if that's in scope though.

Post

Tj Shredder wrote: Tue Jun 21, 2022 2:07 pm
aMUSEd wrote: Tue Jun 21, 2022 11:01 am
koalaboy wrote: Tue Jun 21, 2022 9:09 am Maybe we need an open-source equivalent to NKS....
Personally I think what we really need is for plugins to be designed with controllers and expression using controllers and keyboards in mind from the start, that don't just passively advertise to controllers what params are available for controlling but also interact with controllers to create the optimal param layout given the capabilities of that controller. Intermediate layers like NKS really shouldn't be needed, it's too clunky and creates a dependency on companies and users doing a lot of hard work in creating mappings and templates (and so much that can go wrong when plugins get updated). Maybe CLAP could make that possible?
Isn’t this one of the basic ideas behind Midi 2.0?
And regarding NKS, the basic idea is a good one, but its bound to a specific hardware. Usually I would think in sounds and not in which plugin does make that sound. It could be a way to simplify things. Within Bitwig I can do that on a personal level, but a standard (with a permissive license like CLAP has) would help a lot. It should be able to import NKS information though…
As a Bitwig user, the NKS implementation is a mess. You can't use Audio Units, only VST and VST3. Currently, NKS only works with the VST versions, not the VST3 ones.

So the flagship product of Native Instruments, Kontakt, can't be used as an ARM native instance with their own keyboards.

And synths like Plasmonic can't implement NKS support, because Steinberg doesn't give access to the VST license to new developers.

This is one of the reasons of why need an open standard.

The same thing said can be said of Kontakt, but this is a completely different story. If Decent Sampler adopts the CLAP format, including complex MPE functions, I hope that a lot of third party developers start to use this as a replacement. Not the big ones, due to copy protection, and it makes sense. But for small developers, without the margin to pay Native Instruments fees to use its internal copy protection system, Decent Sampler can make a lot of sense. If it's able to catch most of the advanced features of Kontakt. Now with CLAP, a lot of these things can be much more easy to implement, relying in the DAW part.

Post

Pinku Eiga wrote: Tue Jun 21, 2022 2:01 pm
pdxindy wrote: Tue Jun 21, 2022 1:44 pm
Pinku Eiga wrote: Tue Jun 21, 2022 1:36 pm If Bitwig continues doing things in this way, this can slow the adoption of the CLAP format. Nobody wants to lost his past projects in the transition.
Most user aren't going to uninstall the VST version and there is no need to. That is a self inflicted problem
Well, I'm masochist. I will sure uninstall the VST3 version, keeping only the CLAP one. Bitwig is the only DAW installed on my Mac. And I'm only using VST because Bitwig doesn't support Audio Units.
I always thought that the identification is by a unique ID. And plugins usually have names for parameters. That should make it easy to replace programmatically a VST3 with its CLAP version. You might need to trigger a translation process asking: “this plugin was a VST3 plugin I can’t find, but there is a corresponding CLAP plugin, should I replace it with the CLAP version?”
If it is really smart, it could assume the corresponding plugin has the same file name without extension in case the ID does not match, and if its even more smart it could ask for a plugin to choose and show an editable parameter mapping including ranges of units…
This would even allow to replace a plugin you don’t own in a session of a collaborator with a version you own. The mapping would be remembered and you could do a find & replace with plugins…
(Seems I am in an inventors mood…; - )

Post

Regarding this whole plugin name/finding plugins issue: is there any standardization about how a host is supposed to find a plugin? We all know that with it was handled differently by many hosts, some just used the id, some the name, some both.
Will it be mandatory for CLAP hosts to use the plugin id? (I do hope so, because relying on file names is a bad idea imho).
And shouldn’t there be a standardized way of creating the plugin id? In the plugin.h it just says “e.g. com.u-he.diva”, which would be fine, a GUID would be another option. A possible collision of plugin ids should be prevented under all circumstances, so imho there should be a mandatory way of creating the plugin id…

Post

Pinku Eiga wrote: Tue Jun 21, 2022 2:22 pm If Decent Sampler adopts the CLAP format, including complex MPE functions, I hope that a lot of third party developers start to use this as a replacement.
Not likely, you compare a spaceship with a bicyle… Hise would be a better option, its open source as well…
http://www.hise.audio/
I love Decent Sampler, its can do a lot, but not really comparable to scripting monsters like Kontakt, Halion or Falcon…

Post

AFAIK yeah Bitwig doesn't implement plugin migration (VST2 to VST3, for example). Some other DAWs do that just fine. But I am not sure if it's possible to make migration between VST2+VST3 to CLAP, since unique IDs would be different and plugin data chunk formats would also be different as well, most probably.

Post

Tj Shredder wrote: Tue Jun 21, 2022 2:28 pmAnd plugins usually have names for parameters. That should make it easy to replace programmatically a VST3 with its CLAP version.
But plugins can also write non-parameter stuff into their data chunk (for example, store wavetables directly there, or various UI states so that they get recalled properly when you reopen the project). That makes it way more difficult to port things between plugin formats, at least from my perspective.

Post

That would be difficult to transfer to a different plugin, but the developer could take care of that for the same plugin. But certainly it has potential for breaking things.
On the other hand, if only a part is transferred, that would help already…
I had plugins with different IDs for Mac and Windows, which made it impossible to share DAW sessions. Finally they changed the Mac ID, and Mac users couldn’t open their old sessions… It was in an early stage though, the damage wasn’t too hard and preferable to the other option (to keep, them different…)

Post

Like I said, migration is coming to CLAP, it is just not a priority until we have broad support.

Post

Urs wrote: Tue Jun 21, 2022 4:06 pm Like I said, migration is coming to CLAP, it is just not a priority until we have broad support.
I think that this should be a priority, to make things easy to early adopters. In this way, it's much more easy to start migrating plugins libraries to CLAP.

And from a marketing standpoint, it's great to say, once the final version of Bitwig with CLAP support is out of beta: "you can install a CLAP plugin, delete the VST ones to not take extra space on the hard drive, and your old projects will automatically try to load the new CLAP instances".

In the other way, there are people that will think, yeah, CLAP is cool. But it's other added plugin, not a replacement, because I still need to keep the old VST plugins. Managing two plugins libraries, instead of one. And having different projects, mixing the two formats.

But that's just my two cents, I will not complain if it's not at the start. You have done an incredible work :)

Post Reply

Return to “Instruments”