

CLAP, new virtual instrument and effect plugin interface proposal - abique

Hi,<p>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.<p>The specification is hosted on github: https:&#x2F;&#x2F;github.com&#x2F;free-audio&#x2F;clap and is available under the MIT license.
There is a generated specification document at: http:&#x2F;&#x2F;free-audio.github.io&#x2F;clap&#x2F;<p>I hope that you&#x27;ll find it interesting and give it a chance. Thanks.<p>Regards,
Alexandre
======
abique
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.

------
al2o3cr
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).

~~~
dfxm12
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 ;)

~~~
abique
Did you try the clap host and the clap plugin? :-)

------
mantis369
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.

~~~
abique
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?

~~~
mantis369
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)?

~~~
abique
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.

------
valdiorn
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](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... :)

~~~
abique
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 :)

