Show Posts
106
Plugin Development / Re: About debugging a plug-in
« on: December 14, 2010, 18:13:51 »Hello again.
Some of this, including perhaps the bit about output descriptors, is either explicitly documented or at least "implied" by the Vamp plugins programmers' guide (http://vamp-plugins.org/guide.pdf) in the section "What can depend on a parameter?" But this doesn't cover most of your questions.
First, you're right that the default parameter values need to be set twice -- or else you need a separate variable for the default value, which you assign the parameter variable from. This is something of a deficiency in the specification, as it makes hosts easier to write but plugins harder, which is the wrong way around.
For memory checks, I would certainly use valgrind, assuming you are on a platform on which it is supported. Just stick the valgrind command at the start of your vamp-plugin-tester command line ("valgrind vamp-plugin-tester [options...]") The default behaviour of valgrind, with no fancy options, will show you most of what you need to know, though it's also worth trying the --leak-check=full option to valgrind to find memory leaks for you.
As for plugin lifecycle, Sonic Visualiser generally calls the constructor and destructor quite often -- for example when scanning plugins on startup it will construct each, query its outputs (but _not_ call initialise: the idea is that construction should be cheap and initialise should do the real work) and then destroy the plugin again. SV will also generally destroy and recreate at times when you might expect reset() to be used, as in your example with multiple layers -- the plugin will be destroyed there rather than simply reset. In fact I have a suspicion that SV never calls reset() at all, although some hosts will. Your plugin will need to behave the same in either situation.
Chris