Development Topics > Plugin Development

About debugging a plug-in

(1/3) > >>

jean-louis:
Hi everyone (well, hi chris, actually!)

I have several questions about debugging a plug-in, once again... I feel a bit sorry to post so much lately... I hope that may be of some interest for some other people, still!

First I used the plug-in tester provided on the website: there was a strange error that popped by using it. It said that the parameters were not initialized with the default values. And indeed: in the constructor, I did not use the default values. This however is a bit cumbersome: each time one wants to modify the default values for a parameter, it has to be changed in two places. Is there a way of doing so automatically? What if the parameter is not initialized? how about with another value?

Then, I was wondering whether vamp-plugin-tester was performing some memory checks. That would be a great addition! Otherwise, is it possible to use valgrind for instance to do so? How would you recommend to use it?

Actually, what bothers me, for the latter matter, is that my plug-in needs some arrays, which probably should be freed at some stage... Thing is, I m not so sure about the whole work-flow of the plug-in (maybe the documentation could be a bit more precise about that...). When is the destructor called? the reset? For instance, when a user starts a session, then starts the plug-in as a layer, uses it and closes the layer. When he calls the plug-in as a new layer, is the previous instance called or is it a new instance?

So many questions... I feel sorry about that, since I might have missed the answers in the documentation, but please bear with me!

Best regards,

Jean-Louis

----------
added 2010/12/13:
Just added a second output feature to my plug-in. Launching Sonic Visualiser on it or even the plug-in tester crashes right at the beginning: I figured out that, at the start, SV tries to get some information on the outputDescriptor (from the getOutputDescriptors method), in which I was using attributes that were not initialized yet.

There is something somewhat related to that matter in the plug-in skeleton: handling m_blockSize differently whether it s 0. The comment says:

--- Code: ---    // Just so as not to return "1". This is the bin count that
    // would result from a block size of 1024, which is a likely
    // default -- but the host should always set the block size
    // before querying the bin count for certain.

--- End code ---
Well, I'd say that when starting SV, the block size is not set and the program still calls this method... That's probably not a big issue in the most general cases, in my case, since I am setting the labels for each bin of the output vector, it so happens that, with random values for my attributes (parameters), I end up writing a bit anywhere in memory... Just thought this should be made clear.

Cheers!

jean-louis

cannam:

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

jean-louis:
Thanks again for the answers!

About the guide: I ve gone through it, but could not find answers to some of my questions... I actually found the provided examples more useful than the documentation itself. That's why I thought a post would be good, to share my experience with others and also to keep trace of it!

valgrind: I ll try it, but for some reasons, when I tried it, it was taking ages to compute - far more than necessary. I guess vamp-plugin-tester also needs to be compiled with -g enabled?

outputs: another question! Let's say a vamp plug-in can output several features, is there a way, in SV, for instance, to obtain all of these outputs from one run, or do I need to run several instances of the plug-in so as to extract each of the desired outputs?

Cheers!

jean-louis

cannam:
Computational software under Valgrind does indeed take a very long time to run.  A very, very long time.  That's presumably because of the immense amount of book-keeping work it needs to do for every single memory access.

You'll need to compile vamp-plugin-tester with -g if you want line numbers and suchlike in your Valgrind output for those parts of the stack trace that appear within vamp-plugin-tester.  It probably won't make any difference to whether you get line numbers in the lines related to your plugin -- that should depend only on whether your plugin was compiled with -g or not.

SV cannot extract more than one output in a single run.  (Well, technically it always extracts more than one output -- since a Vamp plugin always calculates all of its outputs at once -- but it won't display more than one output as a result.)


Chris

jean-louis:

--- Quote ---SV cannot extract more than one output in a single run.  (Well, technically it always extracts more than one output -- since a Vamp plugin always calculates all of its outputs at once -- but it won't display more than one output as a result.)

--- End quote ---

Is this a limitation of Vamp plug-ins in general, or would it be something possible within SV in the (hopefully near) future?

For instance, the possibility of choosing which of the outputs should be kept, and display them as new panes and/or as new layers, would be a great addition to SV, if that would be technically possible!

Cheers, and happy new year to everyone involved and interested in SV, Vamp plug-ins, music signal processing or just music!

Jean-Louis

Navigation

[0] Message Index

[#] Next page