Re: [LAD] [LAA] CLAP, new virtual instrument and effect plugin interface proposal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
> Hi,
>
> 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,
>

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.

http://i.imgur.com/4MhRWvf.jpg

(yes, this is a two monitor setup with an upright 4:3 monitor on the
left :))

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

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
this way?

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,
Flo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJUp8xtAAoJEA5f4Coltk8ZCogIALDFJMjfOrg3jeGrp6IB6dk/
3LvICyE53XrdjZsBqbETAPY6LAIf5HOwuoyU8JbBPECirILKM0T5diK/+G9CMTJL
gx93UTWkdWVFivVI79y5Rys+Fj3fRBpknBXttplATBohIeMWvam8ey2F5/6UN82H
y3IVPp+y9CXsEZ6Ekv/Z25S5FWlBQ7X2mdojafWnxk8euJedPSAUFF3248LHvAaX
oeNZkMX7KANlw+3r/8R0mOhez/Z1p016Q5/Ckc1U/t6kHoAeSHNSDmL1ONS/0hzL
VEcVHjLoxSDpW3D2NksKtkTK6w98xHS7BQtG9Rm8c2h0ReA6JWXunE2MClbltVI=
=jS92
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Jan 3 16:15:01 2015