CLAP New plugins standard

Off-Topic
1

CLAP is an open source plug-in format originally designed by Alexandre Bique a few years ago that we currently help to bring forward, along with friends at Bitwig and a whole bunch of other developers from both host and plug-in side.

While there is no official launch date, we have decided to include the current state of CLAP in all future updates and installers. That’s why now it’s in the MFM 2.5 public preview/beta installer.

The main reason we (u-he, others may have other reasons) try to bring forward a new plug-in standard is very simple: It’s liberally licensed. No one needs to pay fees, hire lawyers or go through vetting process. No need to sign weird contracts or NDAs that may turn into future risks of investment.

Another reason is its robustness. CLAP is very easy to grasp and very determined to avoid misinterpretation. CLAP is designed to minimise bugs that arise from different host implementations or plug-in implementations. CLAP offers ways and helpers to avoid conflicts between hosts and plug-ins that commonly happen all the time.

A third reason is its completeness. It’s got all the modern features and quite a few that we haven’t seen yet. For instance it takes into account that some hosts are not just modern tape recorders, some hosts are modern modular synthesisers. Such that CLAP offers parameter modulation which is non-destructive (unlike classic automation) and which can be polyphonic. Things like that, including event based parameter, tempo and timing changes.

Another reason is, it solves common problems. It has fast plug-in scanning, it offers host controlled multithreading (which we have benchmarked with eye popping results), it offers plug-in meta data to organise your plug-ins, resource consolidation (i.e. the plug-in can tell the host about the samples and stuff it references so that the host can gather all that in its project file) and a lot more.

As for reasons that we haven’t mentioned, maybe because they’re not as important for u-he as others, CLAP is a pure C ABI, so people can develop in any programming language they like. It can run on pretty much any hardware and operating system, even embedded. I’m writing this off my head, I’m sure there are numerous reasons to develop and deploy CLAP that I can’t possibly all mention here.

But: Please don’t expect a full blown roll-out in the next few months! Even if we offer ready-to-go CLAP plug-ins, we can’t speak for our partners on the hosting side, and CLAP is still in development, i.e. specs might change a bit.

We are however happy to include host and plug-in developers in our chats once the specs are finalised. This is going to happen, we hope, before MFM 2.5 is released, and then MFM 2.5 can be used as one reference implementation for host developers to try.

We are also offering some financial support to open source projects which would like to offer CLAP support. We’re currently supporting three initiatives, we may have room for some more. So if you have a project that’s currently compiling to any other audio plug-in format, or hosting such, we’re happy to hear from you and maybe it fits within our budget.

Btw. some cool open source projects are already running as CLAP in private branches, we can’t wait to see them running in a cool host soon!

7 Likes
2

What was ever wrong with the LV2 plug format? Or am I missing something here?

1 Like
3

LV2 has some really serious issues, I forget the specifics, but you can always jump in the Surge developers Discord, they will run you over it all (And those are some seriously clever guys lol)

1 Like
4

In what way is this a new standard? Has a vendor consortium reviewed a formal spec and signed off on supporting it? Can we expect to see this in Reason, Reaper, Ableton, Cubase, and so on?

ObXkcd: xkcd: Standards

1 Like
5

The best “lever” is the crowdfunding to appear more serious

I wonder if they provide in advance the migration from 64 bit to 128 (96?) bit

6

If the Bitwig team is involved I’m sure it’ll be amazing

7
3 Likes
8

The name feels like a barrier to adoption. Maybe non-native speakers don’t see the problem with saying “hey, did you hear? Renoise has CLAP now!”, but it could get awkward.

2 Likes
9

I see what you’re sayin’… a little penicillin should clear that right up

2 Likes
10
2 Likes
11

Even though I always love an opportunity to share this XKCD comic on Standards, the projects that do already support it are some of my favorites, including Surge and Vital synths.

another standard

I guess time will tell if it catches on. The modulation of parameters looks similar to what’s already possible between Renoise and VST/AU plugins, so I wonder if this actually adds any new capabilities?

I wonder if, from the Renoise dev perspective, if it solves some behind-the-scenes issues like licensing? I wonder if it will make it easier for would-be plugin producers to create plugins in a wider variety of programming languages? If it will ease any incompatibilities between Mac/Win/Lin support of VST (not to mention Apple AU plugins)?

12
1 Like
13

It really doesn’t. Most of the “issues” people have with LV2 is based on FUD.

1 Like
14

Reaper yes, Cubase obviously never. The rest unlikely.

15

Urs at U-he predicted there would be people who responded with this XKCD comic. I think this new format offers a lot of advantages that make it worth adopting

1 Like
16

That MIDI 2 per note modulation spec is massive in itself…something I regularly lean on in audio programming/modular environments. Renoise kind of has it in the instrument modulation, but not for everything else.

1 Like
17
2 Likes
18
1 Like
19

Isn’t it just basically steinberg and apple that won’t accept others formats…which whom coincidentally own both major formats ? I wish they wouldn’t be so proprietary

20

Amazing performance improvement, they say in their tests you can run double the amount of u-He Diva with it … geez I look forward to see this, hope Renoise will add support :astonished:

4 Likes