CLAP, new virtual instrument and effect plugin interface proposal
4 comments
In a few words CLAP features:
- per sample and ramp automation
- per note automation
- you can play a note at any frequency
- extensible design
- preset browsing
- parameters grouping
- event based
- the plugin can say which parameters are used and which aren't
- the plugin can dynamically add new parameters
- the plugin can expose multiple ports configuration, including repeatable sidechain input which lets the host connect any number of inputs to the plugin, and name those inputs. It is useful for an analyzer.
- The plugin can inform the host that it does not need to process the next block, like when all the voices are off. It will help to save a lot of CPU on big project when you have hundreds of plugin instances idle.
- The interface is very easy to understand and use, anyone can get started from the example synthesizer and host.
- per sample and ramp automation
- per note automation
- you can play a note at any frequency
- extensible design
- preset browsing
- parameters grouping
- event based
- the plugin can say which parameters are used and which aren't
- the plugin can dynamically add new parameters
- the plugin can expose multiple ports configuration, including repeatable sidechain input which lets the host connect any number of inputs to the plugin, and name those inputs. It is useful for an analyzer.
- The plugin can inform the host that it does not need to process the next block, like when all the voices are off. It will help to save a lot of CPU on big project when you have hundreds of plugin instances idle.
- The interface is very easy to understand and use, anyone can get started from the example synthesizer and host.
If my DAW gets this, will it cause a burning sensation in the audio I/O ports? ;)
All joking aside, that acronym definitely carries some baggage in some countries ("clap" is a slang term for venereal disease).
All joking aside, that acronym definitely carries some baggage in some countries ("clap" is a slang term for venereal disease).
Hey, yes I've been looking for an other name, but I did not find one. I'm open to suggestion ;-) Also I don't mind too much about the slang term because it is "the clap" and the plugin format is "CLAP". I believe that anything can be turned into a joke anyway :)
If your DAW get this, the burning sensation might spread into the cables, the speakers, the keyboard and even into your genital organ ;-)
If your DAW get this, the burning sensation might spread into the cables, the speakers, the keyboard and even into your genital organ ;-)
In those same countries, though, "clap" is also a musical term and has many other meanings unrelated to both STD's and music.
I mean, I understand your concern, but I think it's a bit of a long shot that someone is going to think of the disease first when they come across this software.
Everything worked out OK for JACK ;)
I mean, I understand your concern, but I think it's a bit of a long shot that someone is going to think of the disease first when they come across this software.
Everything worked out OK for JACK ;)
Did you try the clap host and the clap plugin? :-)
Any chance that you could make the output channels arbitrary? Just yesterday I built a sampler array with Kontakt, in REAPER, that used 28 outputs from a single plugin instance.
You can declare as many output ports as you want. For the sidechain it makes sense to have the repeatable attribute because it let the host decide how many inputs it wants to connect. But for the plugin output, I think that only the plugin can tell the host how many output it wants.
Right now the scenario would be: - plugin send CLAP_EVENT_NEW_PORTS_CONFIGS to the host - the host deactivate the plugin - the host scans the available configurations, the plugin can expose only the new one - then the host can select the new configuration and activate the plugin
What do you think of that?
Right now the scenario would be: - plugin send CLAP_EVENT_NEW_PORTS_CONFIGS to the host - the host deactivate the plugin - the host scans the available configurations, the plugin can expose only the new one - then the host can select the new configuration and activate the plugin
What do you think of that?
What would that feel like in a DAW? You open the plugin, change its default configuration, get rid of it, and then add it back independently and let it tell the DAW how many outputs it has, so you can connect them to tracks (or whatever the analogue is)?
You don't need to remove the plugin and add it again. Just change the config in the plugin, and then when you get back to the daw, you should already see the new outputs.
Hi Alexandre. I've been researching similar things for years, and I've come to realize quite a few flaws in the current suite of available plugin APIs, some of which are reflected in your api as well, some of which I have yet to find a solution to.
For reference, this is what I use to develop my plugins, it's a managed wrapper for creating plugins in C#, and provides a bridge between VST and my interface, called SharpSoundDevice. I develop plugins for personal use, and my choice of C# is not up for debate here, I'm fully aware of its limitations :)
https://github.com/ValdemarOrn/SharpSoundDevice
To me, the biggest problems are:
1. Docking the UI inside the host. This is just an awful way to do things, as the host can intercept (and break) lots of event bindings in your UI. Notice how the scroll wheel and typing are broken in every other plugin in Ableton live? yeah, I mean that kind of stuff. Plugins should have its own window, but then of course, you end up with a problem where they should ideally always be on top of the DAW window, etc... This also means you have lots of platform dependent code for interfacing with the host. (I do my UIs in WPF these days, with some magic to dock the wpf panels inside the win32 window, it's ugly and I wish I could just handle it all inside my own application without worrying about docking windows within windows, etc. Solutions for developing plugin guis exist (like JUCE and VSTGUI, ugh), but it's a restriction on creativity and possibilities for developers (esp. for newcomers who are not familiar with how VST works). Wouldn't it be nice if we could just write "a desktop application", in Qt, WinForms, PyGTK or whatever, and it would just work? It can be done, but it requires someone to sit down and think. real. hard. which leads to my next point...
2. Process isolation... is hard. Wouldn't things be nice if we could just run each plugin as a separate process. Well, you can, but you endure painful context switching. For multiple channels in parallel, it's not actually so bad, because all modern DAWs are multithreaded and can make use of the "lost time". The problem comes when you have 20 plugins in series, and each of them adds context switch latency of 10-15 uS, adding up to half the available time you have to process the buffer :) Still, some DAWS (like Bitwig) claim to run each plugin as an isolated process, I'm curious to know if they just say "fuck it, live with the added overhead", or if they have some magic solution to mitigate the issue.
I applaud the effort, but there is one more issue remaining:
3. Nobody is going to adopt your standard verbatim. Which means people will be creating wrappers, which means inheriting all the warts from VST/AAX/AU plugins. This is what annoys me most about my own interface. It's a relatively clean .NET interface, but I end up having to cover it in a layer of grit to stick it into a VST host :)
...yet I have not given up on building a universal, platform/gui independent, process-isolated plugin standard! Currently experimenting with named pipes and even Standard IO to define a common interface between host and plugin, which should allow running the gui in a separate process, and allowing you to write an audio plugin in any programming language that supports stdio... :)
For reference, this is what I use to develop my plugins, it's a managed wrapper for creating plugins in C#, and provides a bridge between VST and my interface, called SharpSoundDevice. I develop plugins for personal use, and my choice of C# is not up for debate here, I'm fully aware of its limitations :)
https://github.com/ValdemarOrn/SharpSoundDevice
To me, the biggest problems are:
1. Docking the UI inside the host. This is just an awful way to do things, as the host can intercept (and break) lots of event bindings in your UI. Notice how the scroll wheel and typing are broken in every other plugin in Ableton live? yeah, I mean that kind of stuff. Plugins should have its own window, but then of course, you end up with a problem where they should ideally always be on top of the DAW window, etc... This also means you have lots of platform dependent code for interfacing with the host. (I do my UIs in WPF these days, with some magic to dock the wpf panels inside the win32 window, it's ugly and I wish I could just handle it all inside my own application without worrying about docking windows within windows, etc. Solutions for developing plugin guis exist (like JUCE and VSTGUI, ugh), but it's a restriction on creativity and possibilities for developers (esp. for newcomers who are not familiar with how VST works). Wouldn't it be nice if we could just write "a desktop application", in Qt, WinForms, PyGTK or whatever, and it would just work? It can be done, but it requires someone to sit down and think. real. hard. which leads to my next point...
2. Process isolation... is hard. Wouldn't things be nice if we could just run each plugin as a separate process. Well, you can, but you endure painful context switching. For multiple channels in parallel, it's not actually so bad, because all modern DAWs are multithreaded and can make use of the "lost time". The problem comes when you have 20 plugins in series, and each of them adds context switch latency of 10-15 uS, adding up to half the available time you have to process the buffer :) Still, some DAWS (like Bitwig) claim to run each plugin as an isolated process, I'm curious to know if they just say "fuck it, live with the added overhead", or if they have some magic solution to mitigate the issue.
I applaud the effort, but there is one more issue remaining:
3. Nobody is going to adopt your standard verbatim. Which means people will be creating wrappers, which means inheriting all the warts from VST/AAX/AU plugins. This is what annoys me most about my own interface. It's a relatively clean .NET interface, but I end up having to cover it in a layer of grit to stick it into a VST host :)
...yet I have not given up on building a universal, platform/gui independent, process-isolated plugin standard! Currently experimenting with named pipes and even Standard IO to define a common interface between host and plugin, which should allow running the gui in a separate process, and allowing you to write an audio plugin in any programming language that supports stdio... :)
Hi valdiorn,
Thanks for your message!
For the UI docking, it comes has an extension for clap. First there is the gui extension, which just has open()/close(), and then comes an other extension: embed (host), embed/win32 (plugin), embed/X11 (plugin), embed/*. So embedding is available only if the plugin support it.
It would be really nice to have the UI done with Qt or Gtk. Yet they're not fit for such plugin UI (because of the global variables and the main loop, ...).
One of my friend (phant0m) is starting to write a UI toolkit which does not rely on global variables, and should be convenient for plugin UI. I think that we can achieve pretty cool UI with a 2D scene graph, with a vector backend like cairo, and some event handling and windowing abstraction. So work is in progress here.
For the process isolation I like a lot the idea, but if I can have bug free plugins, use them in the same process and benefit from a noticeable performance gain, I prefer "in engine" hosting. Also this is the new option of Bitwig: "only as a bit bridge".
Also the one plugin/one process idea is already possible with jack, right?
For the adoption, it is a big challenge. Let's see how it goes ;-)
I hope that I did not forget to answer one of your point.
Cheers :)
Thanks for your message!
For the UI docking, it comes has an extension for clap. First there is the gui extension, which just has open()/close(), and then comes an other extension: embed (host), embed/win32 (plugin), embed/X11 (plugin), embed/*. So embedding is available only if the plugin support it.
It would be really nice to have the UI done with Qt or Gtk. Yet they're not fit for such plugin UI (because of the global variables and the main loop, ...).
One of my friend (phant0m) is starting to write a UI toolkit which does not rely on global variables, and should be convenient for plugin UI. I think that we can achieve pretty cool UI with a 2D scene graph, with a vector backend like cairo, and some event handling and windowing abstraction. So work is in progress here.
For the process isolation I like a lot the idea, but if I can have bug free plugins, use them in the same process and benefit from a noticeable performance gain, I prefer "in engine" hosting. Also this is the new option of Bitwig: "only as a bit bridge".
Also the one plugin/one process idea is already possible with jack, right?
For the adoption, it is a big challenge. Let's see how it goes ;-)
I hope that I did not forget to answer one of your point.
Cheers :)
I worked on a new plugin interface, it is not yet finished and set in stone, but ready enough to gather initial feedback and advice.
The specification is hosted on github: https://github.com/free-audio/clap and is available under the MIT license. There is a generated specification document at: http://free-audio.github.io/clap/
I hope that you'll find it interesting and give it a chance. Thanks.
Regards, Alexandre