[LAD] [LAA] CLAP, new virtual instrument and effect plugin interface proposal
Florian Paul Schmidt
mista.tapas at gmx.net
Sat Jan 3 11:03:09 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
Sending this to LAD (additionally to replying to the author directly)
as I cannot post answers to LAA and maybe it's interesting to keep
this discussion on LAD..
On 29.12.2014 16:48, Alexandre Bique wrote:
> 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:
> I hope that you'll find it interesting and give it a chance.
Hi, I'm just skimming over the generated docs. Generally it's a
laudable effort but maybe a few years too late. I guess many people in
the linux audio community would agree that there is no lack of plugin
standards :) Some remarks:
1] The generated docs display rather badly in my browser as I cannot
move the separator between the two "lanes" which results in the left
one not being readable at least partly.
(yes, this is a two monitor setup with an upright 4:3 monitor on the
2] It would be cool if clicking on a function name in the left panel
would take you to the function declaration in the right panel. E.g.
3] It would make plugin development easier if it was required to call
deactivate() on a plugin before clap_destroy'ing it. The additional
burden on the host would be small. Is there a good reason for it to be
4] The plugins collection query mechanism (with index 0) seems a
little "hackish". Why not have extra functions for it?
5] tunning -> tuning (spelling)
6] Adding to 3]: Change some of the "should not" to "must not" as it
would make the API semantics clearer. Example:
"Also deactivate() should not be called if the plugin is not
activated. Yet the plugin should handle a call to deactivate() even if
it is not activated."
How should it handle it? It would be simpler to just make this a "must
not". Little additional burden on the host while making every single
plugin easier to implement and less error prone..
That's it for now (it's how far I got into reading the spec). Have fun,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Linux-audio-dev