CLAP - CLever Audio Plugin

All your LV2 and LADSPA goodness and more.

Moderators: MattKingUSA, khz

danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

CLAP - CLever Audio Plugin

Post by danboid »

Alex Bique,who is prob most well known around these parts for having ported the Uhe plugs to Linux, has created a new free audio plugin spec called CLAP.

https://github.com/free-audio/clap

I thought I'd email him about his new spec..

---------------------

On Sat, Jan 17, 2015 at 11:48 AM, Dan MacDonald <allcoms@gmail.com> wrote:
> Hi Alex and LA users / devs

Hey :-)

> I think I spotted CLAP2VST and vice versa support.

Yes we could do something here, maybe not cover 100% of both
interfaces, but interesting parts I think so.

> Have you ported any of the Uhe plugins to CLAP or added CLAP support to any
> of the free DAWs Alex?

I made an example synthesizer which you can use into a micro clap host
using jack. You can find both in the source tree.
I'm porting u-he synthesizers to CLAP as well. It is going well so
far. Once they're done, let's see what happens ;-).

---------------------

Thoughts please!
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: CLAP - CLever Audio Plugin

Post by danboid »

Sounds like you're more keen on LV2 than last time I spoke to you about it F.

What about LV2's multiple components, seeming complexity, standard stuff needing extensions and it's frequent updates? I know nothing is pefect and it's very early days for CLAP but I don't think any of those aspects of LV2 are ideal.

Could it be that porting (non-JUCE) VSTs to CLAP would be easier than porting to LV2 for a developer who has no knowledge of LV2? If that alone is the case it could be a justification for having a new standard that is both easier for VST devs to understand but not restricted by its license.
danboid
Established Member
Posts: 1327
Joined: Sun Aug 26, 2012 11:28 am
Location: England
Has thanked: 1 time
Been thanked: 4 times

Re: CLAP - CLever Audio Plugin

Post by danboid »

Thanks for your comments F!

Having never developed an audio plugin, I'm not really qualified to comment myself. I'm merely parroting what other devs have said about LV2 so I trust your opinion much more than any vague ideas I have about CLAP, LV2 and VST.

It's a shame about CLAP's lack of plugin DSP <-> UI separation - that sounds like an important omission.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

None of this addresses the single most important problem with making any plug-ins for linux, which is that you cannot write a plug-in with an embeddable UI, unless you write it to use the particular graphical toolkit which the host uses. Unless you know that in advance (and you can't) or even if you do (and you can't) you would have to (re)write the UI to suit all possible toolkits that the (or any) host might use. Otherwise you are simply tied to DAW specific plug-ins (and as has been proved with Ardour, even if you do that, unless you are careful, you need to ensure your binary is compiled against the specific library versions that the host uses. Not the system libs - or it might be, but you can't know that, unless you know if the user is running a self-build or a pre-compiled bundle - but the specific library versions a - perhaps proprietary - host uses).
We already have multiple LV2 extensions for X11, External UI (several incompatible), GTK2, GTK3, GL (which is really X11) etc etc and the current LV2 "compatibility" hack of providing "x in y" libraries to effectively re-parent the UI window using X11 as an intermediary is, simply prone to exponential expansion in complexity as the number of possible toolkits requiring support grows (for example if a developer wants SDL, FLTK, etc etc)
The only cross-host compatible solution which exists at the moment is to use X11 as the lowest common denominator (which should be present on any system... for the moment) - this is what VST does, and it works.
Unfortunately, this may not be guaranteed in some future linux incarnation which might use Mir, XMir, Wayland, XWayland or any number of other proposed replacements for X, each with their own replacement for X or some compatibility layer. Therefore, at some point, plug-in developers for linux will be faced with writing UIs for Wayland, Mir, X11, X11 with (insert list of toolkits) ... and any other combination of display server and toolkit.
That's the problem that really needs solving, but, unsurprisingly, there's no clear way to unscramble the mess. Until then, VST on X11 works - there isn't anything you can't do with it, the only issue with VST if correctly implemented - was its GPL-unfriendly license.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

linuxdsp wrote:We already have multiple LV2 extensions for X11, External UI (several incompatible), GTK2, GTK3, GL (which is really X11) etc etc and the current LV2 "compatibility" hack of providing "x in y" libraries to effectively re-parent the UI window using X11 as an intermediary is, simply prone to exponential expansion in complexity as the number of possible toolkits requiring support grows (for example if a developer wants SDL, FLTK, etc etc)
The only cross-host compatible solution which exists at the moment is to use X11 as the lowest common denominator (which should be present on any system... for the moment) - this is what VST does, and it works
The most important feature in LV2, for me, is, the separation between engine and UI, and that a plugin have to expose it's ports to the host. That allow a host to create it's own UI's for plugins and remove all the Toolkit trouble you referring to.
Could you do that with VST??
A nice Example were this is Outworked on a professional base is the MOD:
http://portalmod.com/interface

Nothing against nice single plugin User Interfaces (as I try to create some myself), but, it's also nice to have a common plug interface style in a host, which looks like "Hey, that is all out of the same manufacture".
That, you can reach with LV2, not with CLAP, nor with VST.
It was doable with LADSPA as well, but there are to much missing features in it, so I'm glad we have LV2 now.

my 2 cents
On the road again.
glowrak guy
Established Member
Posts: 2315
Joined: Sat Jun 21, 2014 8:37 pm
Been thanked: 251 times

Re: CLAP - CLever Audio Plugin

Post by glowrak guy »

I don't like uniformity of interfaces. The differences make remembering things easier.
A stompbox, synthesizer, amplifier, and sampler are different beasts, and I prefer them
to be presented uniquely, and organized for workflow.

Uniformity can also be boring. A beautiful gui is inspiring, and welcoming.
Starting Hive or Diva invites creative exploration. Guitarix feels good,
just looking at it, makes you want to plug something in.

Then there is the dreaded chasm between commercial, and open-source developement.
Career path, versus artistic fervor. Problematic dance partners, in some halls.
One can build bridges, or keep destroy them. Ego and religious fervor
can drive one man to success, and trap another in poverty.

Can LV2, or DSSI ever make it into the win/mac/commercial domain?
Public sentiment still seems to be, vst works, so vst sells, so vst is the future.
Gonna be tough to beat it. But new generations and new money are out there,
waiting to be convinced. Alex and CLAP might be in the right place at the right time,
which can be the deciding fundamental for success among giants.
Cheers
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

I guess my point (or rant) was fundamentally that there is a technical issue - a technical "elephant in the room" (if that makes sense) - which everyone is ignoring, and that all the extra frills on various plug-in formats, and the effort spent in developing them, and arguing them to the n'th degree, are all so much p*ssing in the wind (to be blunt) until the basic problem of a how to implement custom UIs reliably on linux is solved.
Plug-in UIs are not just there to be pretty. Especially in emulations of real hardware, they provide visual cues to those familiar with the original, which help quickly locate controls and understand how they work, intuitively. This just doesn't happen if you have a generic set of host generated sliders for example. Equally, a graphically complex plugin such as an EQ / FFT or some multi-band compresors etc (think fab filter etc) simply don't work if they're represented by a bunch of sliders, and to think that they could be is laughable. The only software which can know how to implement such a UI in any way which makes sense - in this case - is the plugin.
What linux needs is simply a common format into which the plugin can render its UI (think about audio, we just pass a buffer of float32 samples around) we could do the same with e.g. RGBA format video buffers - a standard. All the plugin needs is a pointer to some memory into which it will draw, the host can sort out making it appear infront of the user (using its own native prefered toolkit) just as the host takes the audio buffer and plays it out through the hardware, because it knows more about that than the plugin.

LV2 / (insert some other format) on other platforms such as Windows / Mac? Why? LV2 primarily exists to solve problems specific to linux, there is only one other (commercial) host which supports it on anything other than linux, so the incentive for plug-in developers to expend yet more scarce time and resources to support it on those OS is non existant. Coupled with the fact that the only host which does support it on Windows / Mac, also supports more common formats native to those OS (VST, AudioUnit etc). If I'm developing for Mac, why should I take my AU / VST and convert it to LV2 just so it works with an application it already works with.
The only incentive for uptake of a new plug-in format is if some "must have" plug-in were to be developed only in that format (and the odds of such a plugin happening on linux are very slight) and paradoxically, if anyone were to invent such a "must have" plugin then they would be crazy to release it only in a format hardly anyone uses. Hence new formats struggle to get adopted.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

linuxdsp wrote: Equally, a graphically complex plugin such as an EQ / FFT or some multi-band compresors etc (think fab filter etc) simply don't work if they're represented by a bunch of sliders, and to think that they could be is laughable.
With port descriptions there is a lot more possible in LV2.
linuxdsp wrote:The only software which can know how to implement such a UI in any way which makes sense - in this case - is the plugin.

Wrong, the plug could expose all the needed information to the host.
linuxdsp wrote:What linux needs is simply a common format into which the plugin can render its UI
Exact, LV2, just didn't stream any graphics, but the information which is needed to create the graphics.

And, the real question, you've avoid to answer,
Could you separate the engine and the GUI in VST??

Without that feature, VST simply didn't "just works" for me,
On the road again.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

And, the real question, you've avoid to answer,
Could you separate the engine and the GUI in VST??

Without that feature, VST simply didn't "just works" for me,
VST2 no, at least, that's not how its really designed*, but that doesn't really matter as much as anyone here seems to think. At least, it only matters because (if you weren't using X11) on linux you might have more need to run the UI as a separate process, due to the unique complications linux has with UIs and toolkits (in the absence of something like X11 which at least provides a 'common base' which at the moment you can expect to be on every system. Lets not forget that even GTK was originally just a part of one application to enable a more friendly abstraction from X11 ).
The only other case where it matters is if the UI is e.g. on a different machine. This hardly ever happens. It is important to separate GUI and audio threads, all of which is much harder to be sure you have done than may first appear, but you just need to get that right. In some cases the lack of separation between UI and audio engine actually makes things such as interchange of data between the two easier - for example large buffers for FFT etc, but again comes with the caveat that you need to be sure about thread interraction.

*It is possible... I've run experimental VST plug-ins where the UI and audio are on different machines, the thing with VST is that you can just about do anything you want. At its heart its actual a very simple (as in elegant / efficient) design, with a lot of clever features. Its extensible (the core API is - can be - based around one or two callbacks wich use opcodes and parameters, so if you need more functionality, (you could) add more opcodes and the functions to handle them. That's how you get backwards compatibility between VST2.x and earlier - no need for insane .ttl files and convoluted may-or-may-not be supported host vs plugin extensions and incompaitble APIs). There are some things about VST that could be improved yes, and much of that has been in VST3, but if it gets bad press sometimes its normally from people who don't understand how to use it.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

linuxdsp wrote:The only other case where it matters is if the UI is e.g. on a different machine. This hardly ever happens.
Well, I've already given you a example, were exactly this happens/matter, and it isn't one of the typical Linux Hobby Projects.
http://portalmod.com/interface
As well, when you use a RPI, or similar Micro computer, it's most likely that you will run the UI on a separate Machine.

However, I understand that from the view of a commercial Plugin developer, VST may be more attractive, as it is a way more easy to maintain/implement. Maybe the same is true for CLAP, didn't know, but from my view, LV2 had a bunch more potential as both together.
On the road again.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

We can say the same about LV2.
Or perhaps LV2 only gets a good press from people who don't understand how to use it... :wink:
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: CLAP - CLever Audio Plugin

Post by tramp »

linuxdsp wrote:
We can say the same about LV2.
Or perhaps LV2 only gets a good press from people who don't understand how to use it... :wink:
Busted :wink:
On the road again.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

There's probably more that I'm not remembering right now.

Anyway, I got to know LV2 pretty well. Both it's weaknesses and strong points.
The good things about LV2 far outweigh the bad things...
@falkTX: All very commendable efforts, I'm not doubting your ability, or the amount of work that you contribute but my feeling is that a lot of these are clever solutions to problems which should never have existed in the first place - and that unfortunately is quite common in linux audio, and one of my biggest frustrations with it. The reason I'm critical about these things is because I can see the potential and I want to give that my support, but I also see that potential consistently failing to be realised. And there are some serious technical issues which need to be resolved, but which no-one is giving time to, prefering instead to re-invent standards that don't need re-inventing.
Having spent more years in the pro-audio industry than some of the linux audio devs have been alive for and the bulk of that time with one of the world's top pro-audio console companies, having been part of the team which developed some of their very successful plug-ins and associated DSP hardware, and therefore being familiar with creating, developing and supporting audio hardware / software / plug-ins in just about all of the available formats (amongst other things), I thought my opinions might be useful - that was all.
User avatar
linuxdsp
Established Member
Posts: 147
Joined: Sun Mar 01, 2009 12:40 pm
Location: Oxford, England
Contact:

Re: CLAP - CLever Audio Plugin

Post by linuxdsp »

The LV2 mailing list is open for discussion.
Yes I've read some of it..
Some of the things you mentioned before are just not issues to me (the various toolkits).
Windows/Mac sorta have a single windowing system for plugins, but it needs so many hacks to make everything work it's crazy...
I simply don't agree that you need any 'hacks' to make that work - not compared to the horrible stinking mess that the mixture of possible linux toolkits, graphics servers, and configurations enforces on any unlucky developer... or user.

To me its like this:

If I write a Windows plug-in, the UI renders into an HWND, so that's it. Whichever host application, on Win95 upto Win8.1 (and probably 10) so I write the UI once - or rather, I write a port of the GUI engine which I use, ontop of which all the UI components sit, so once that small 'engine' works, everything else just automatically works. No crazy hacks required. Not if you design it properly.

If I write a Mac plug-in, the UI renders into a Cocoa View (ok, there are still some hosts which use carbon, so that can get a bit messy, but, it really comes down to, if 32Bit, carbon, if 64Bit Cocoa - therefore its quite easy to know what to expect the host to do - and on anything from 10.5 up, that just means writing the UI for a Cocoa View anyway, and then using a very thin carbon <-> Cocoa wrapper if necessary). I'll emphasise again for any host application. No crazy hacks, unless you count using a wrapper for Cocoa UIs but that's about it.

So in these examples, its a case of write once, use with any host application - the user installs a plug-in and it works in all their host applications.
Compared to Linux we have some different toolkits in UIs, but how they work it's well established (Gtk2 widget goes into a Gtk2 container, etc etc).
Yes, how they work (or not) is well established, and I understand how all those toolkits work, the problem is, I don't know which one the host will be using so unless I target X11 directly , simply because its the 'base' for all those toolkits (at the moment), I would possibly have to write a different UI, or a wrapper for my UIs in each of whichever toolkit the host may or may not use, which could be GTK, GTK2, GTK3, SDL, NTK,FLTK,X11, etc etc. In addition, in some great future where X11 may or may not be obsolete or some incompatible comaptibility layers are shipped with different distributions it may be that you can't even use X11 as the base - it might be Mir or it might be Wayland or whatever else. At the moment its possible to write an LV2 in "pick any toolkit" - just because LV2 has a lot of hacks in it to make all that embedding of different UIs kind of work - which it does via X11 - but there are still hidden complications, if you use gtkmm for example, as some developers do, you also need to know which specific version of the library the host is using (if at all) in order to guarantee success - complicated, as it might be using the system libs or e.g. ardour builds from ardour.org - it might be using some pre-packaged custom version. All of which limits compatibility - or at least - reliable compatibility across different host applications (and distributions).
Drumfix
Established Member
Posts: 299
Joined: Mon Jan 26, 2009 5:15 pm
Been thanked: 11 times

Re: CLAP - CLever Audio Plugin

Post by Drumfix »

external ui, external ui and again: external ui. Its the ignorance of the LV2 advocates that makes LV2 a nogo.

What plugin developers don't like about LV2 has been discussed to death on the LAD mailing list for the last 8 years.
Pointless to discuss all this here again.

VST has (almost) everything i'd ever want from a plugin Api. Things that i don't like about it could be changed within less than a minute,
and they don't even break compatibility to existing hosts or plugins. So, no need to go with anything else.
Post Reply