-----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'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