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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.01.2015 12:48, Alexandre Bique wrote: OK, let me put it this way. It really is a number's game. Let's take a successfull plugin standard like VST. There's thousands, maybe tens of thousands of plugins, but maybe tens to hundreds of hosts. So there's an order of magnitude or two difference. Every plugin has to have this extra check. What are the chances that a few plugin authors forget to do this check? What are the chances that a few hosts get this wrong? What are the chances that plugins get fixed? What are the chances that hosts get fixed? Also it's just boilerplate code. If every plugin has to do it, then it shouldn't have to do it at all since it clearly can be automated. And the automation in this case is just the host calling deactivate before destroy. Give the plugin authors as much guarantees as possible. With the proposed way around plugins might work in some hosts that honour the standard, but not in others (I.e. ones that do call deactivate() before destroy() vs. those that do not). If you make calling deactivate() before destroy() a requirement this whole problem just goes away. It makes life easier for the plugin developer while not making life _much_ harder for the host dev. Also it's trivial to implement a test plugin for host devs to use that checks things like this - one that does basically just copy input to output but checks that lifecycle requirements are met by the host: - - abort() on calling process() before activate - - abort() on calling destroy before deactivate() - - etc.. Have fun, Flo