Messages

1

Plugin Development / Visualisation Plug-In, with Matrix Processing

« on: July 11, 2014, 20:54:35 »

I have been developing an "IMMF0Salience" plug-in that provides an estimate of fundamental frequencies (F0) for audio signals, which can be found at https://github.com/wslihgt/IMMF0salience. It is still work in progress, but can already be used in some cases.

I wanted to mention in this forum that, recently, I found out the solution for an issue that was bugging me for all this time: the algorithm I developed is based on some matrix processing called "Non-negative Matrix Factorization" (NMF), meaning that it operates most meaningfully when I can process several frames in one go. The architecture of the framework for Vamp-Plugins is appropriate for frame by frame processing, and matrix-like processing is possible, but somewhat tricky. It took me a while, but I could at last make that work, and the solution is on this branch: https://github.com/wslihgt/IMMF0salience/tree/matrixProcessing.

I describe in more details how I do this, and also the process that led me to this solution on my "blog": http://durrieu.ch/wordpress/?p=269.

To put it in a nutshell: I did not really understand how the SampleType and the SampleRate attributes for the OutputDescriptor worked, at least not from the documentation. Digging in some other plug-in, I found the correct combination, and that actually helped me understand what the documentation was describing... Don't get me wrong: I do not say the documentation is bad or missing something, but rather that some more examples (or tutorials) would have helped me to figure that out easier.

I hope this little piece of information may help others to develop such plug-ins! Comments are welcome, of course.

Cheers,
Jean-Louis

2

Plugin Development / Re: Visualisation plug-in development

« on: July 11, 2014, 20:25:41 »

Hi Chris,

This topic has been inactive for quite some time! As it were, I solved also a long time ago this issue (cross-compiling for Windows), and I managed to compile a version for Windows, from Linux, as you suggested. Actually it was rather complicated, I had to compile ATLAS under Windows, directly, and I used Cygwin, although probably only to run some Unix compiler (mingw?). I started to describe that there: http://durrieu.ch/wordpress/?p=35, but that's still a bit elliptic. I did not make the Windows binary for the latest version of the plug-in, so I unfortunately can't remember much of what I then did, but it worked! When I find some time again (and a Windows machine to build the ATLAS lib...).

I will anyway make another topic to announce the availability of the plug-in in a more formal way.

Voilà ! Just thought would be good to close the topic in a nice way! Thanks again for your help.

Cheers,
Jean-Louis

3

Plugin and Host Announcements / Re: MELODIA - Melody Extraction plug-in now available!

« on: October 26, 2012, 08:51:04 »

Hi justin,

Just for information, I also developped a plug-in related to yours:
https://github.com/wslihgt/IMMF0salience

It only does the representation part, but does it with another algorithm (Source/Filter NMF, as you may know). Any comment welcome!

Best regards,
Jean-Louis

P.S.: since the new version of SV for macosx, in native 64bits, I m not quite sure the compiled version works anymore. yet another TODO...

4

Plugin Development / Re: About debugging a plug-in

« on: January 10, 2011, 13:22:49 »

Some more comments on the previous matters.

Code: [Select]

vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
After which the plug-in still seems to have gone on with its work... Is that normal? is this a problem with the plug-in, or with the plug-in tester?

This is a problem with the plugin, but one that the tester can't detect -- the message probably comes from a debug version of the C library which the plugin is linked with.  This is the sort of thing that Valgrind would detect and show a more thorough explanation of, if you could get it to run satisfactorily.  It means just what it says -- at some point you are freeing a pointer that you didn't allocate -- but unfortunately that on its own isn't necessarily going to help you much to find the cause.  Review all places where a pointer may be freed or deleted.

I actually had a question related to this problem.

Let's say I have an array in my plug-in, which is also the output feature. For instance, say in the power spectrum example (http://www.vamp-plugins.org/code-doc/PowerSpectrum_8cpp-source.html), instead of returning the values directly in the feature set (with a push_back, at line 00157), you define an array in the class:

Code: [Select]

float *m_powerSpectrum;
and then initialize it, work on it in the process method:

Code: [Select]

size_t n = m_blockSize / 2 + 1;
m_powerSpectrum = new float[n];
... // filling in the array and
... // after processing, putting the result in the desired feature set

Since this array has been allocated, I guess I should free that memory at some stage... but when would be the best time to do so? It seems that freeing it at the end of process makes the plug-in crash, and some of the errors I talked before might come from freeing these arrays in the destructor, or in the reset method.

Does this make sense, or should I look for some other potential reason?
I tried again with valgrind, but I seem to ask too much memory (by the way, is that something bad for the plug-in, if I want more memory than valgrind can use? I mean, should I expect problems after, when using the plug-in in SV?).

Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:

Code: [Select]

This application has requested the Runtime to terminate it in an unusual way. Please contact ...
Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:

Code: [Select]

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc


That error means that operator new() failed -- you requested allocation of more memory than was available.  That may mean you have tried to allocate far more memory than you actually needed for some reason, or that you simply don't have enough memory -- or it might indicate a more subtle programming error such as unsigned integer underflow.  For example, something like

Code: [Select]

float *f = new float[n - m];

may cause that exception to be thrown if either n or m is unsigned and n is smaller than m.

See if you can run it under a debugger and get a stack trace for the crash -- the innermost stack frames should show where the exception was thrown.

It would seem that the error was caused by some unlucky combinations, at the plug-in first call. That seems related to a problem I talked about some time ago, with the initialisation of the parameters.

In order to provide the binNames, in the getOutputDescriptors method, I was filling-in a vector of strings, for which I assumed the size could not exceed 10 characters. At the first call, however, the values of blockSize and inputSampleRate make the strings a bit longer. Since I was using them to fill my array of char, I was basically writing a bit everywhere, which seemed not to worry SV under Linux or Mac, but which caused SV under Windows to crash right away. Does this sound like a normal behavior for SV, under these different OS's?

I m still running some tests to check whether some more bugs appear... I must admit I have gone through some strange crashes, like some sets of parameters that (randomly) led to unexpected crashes. Hard to trace back...  Does the plug-in tester also test several parameter configurations? That would be an interesting feature.

Regards,

Jean-Louis

5

Plugin Development / Re: About debugging a plug-in

« on: January 08, 2011, 21:02:53 »

It's a limitation of SV, not of the plugin format.  It would certainly be possible to implement it...

That would be an interesting addition to SV! Well, assuming there are enough other vamp plug-ins that are developed. I guess this is an on-going project anyway, at QMUL?

Well, if I think about it, it would be great to be able to at least 1) select which output to display and 2) select whether they appear as new panes or new layers.

Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:

Code: [Select]

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc


That error means that operator new() failed -- you requested allocation of more memory than was available.  That may mean you have tried to allocate far more memory than you actually needed for some reason, or that you simply don't have enough memory -- or it might indicate a more subtle programming error such as unsigned integer underflow.  For example, something like

Code: [Select]

float *f = new float[n - m];

may cause that exception to be thrown if either n or m is unsigned and n is smaller than m.

As this is a C++ exception, it's possible to catch it rather than permit the program to crash -- but it's usually a waste of time; there's not really any reliable way to recover from running out of memory, especially if you don't know at what point in the program the failure happens.

What surprises me  is that it occurs while loading the program, and not when calling the plug-in. Furthermore, this error did not (yet...) appear with my tests under Linux and MacOsX. Could it be that under Linux and OSX, the memory management allows bigger allocations? Is there any known way to allow more under Windows (at compilation or from Windows)? At least trying this before looking for something else...

See if you can run it under a debugger and get a stack trace for the crash -- the innermost stack frames should show where the exception was thrown.

Any experience with a debugger under Windows? Or does gdb (or ddd) work with wine?

Thanks for your help!

6

Plugin Development / Re: About debugging a plug-in

« on: January 06, 2011, 22:39:46 »

I know I get to talk a bit too much about that plug-in... I ll soon send an announcement for it, as soon as the article that goes with it is accepted.

For now, I still need help! Well, it basically works on Linux and Mac, with some bugs, but I guess I cannot really do much at the moment (valgrind tells me I want to use too much memory so it stops before saying anything useful).

Now, I just tried under Windows. I used to have a version which worked - but which was slow  because during initialization, I generate big matrices that in the last version, I manually entered. Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:

Code: [Select]

This application has requested the Runtime to terminate it in an unusual way. Please contact ...
Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:

Code: [Select]

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc
Any idea what might have gone wrong, and if I can solve this problem? I am only asking whether there would be an obvious answer (not much hope). Otherwise, I know I might need to check better the linux version, maybe some bugs may give a hint about that particular problem. But I still think it s a bit strange that it should crash right from the start under windows, while the other versions can work almost without bugs...

Cheers!

7

Plugin Development / Re: About debugging a plug-in

« on: January 05, 2011, 10:57:52 »

Since this is also about the same plug-in, and running vamp-plugin-tester, I post a little remark in this topic (although some digressions have already be done there...)

I just ran vamp-plugin-tester on my plug-in, and obtain a nice

Code: [Select]

vamp-plugin-tester: All tests succeeded for this plugin

However, checking a bit further up, I noticed this:

Code: [Select]

-- Performing test: B2 Invalid or dubious timestamp usage
vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x90ce18ae: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
After which the plug-in still seems to have gone on with its work... Is that normal? is this a problem with the plug-in, or with the plug-in tester?

Cheers!

8

Plugin Development / Re: About debugging a plug-in

« on: January 02, 2011, 21:26:45 »

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

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

9

Plugin Development / Re: About debugging a plug-in

« on: December 17, 2010, 08:41:04 »

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

10

Plugin Development / Re: Licensing a Vamp plug-in

« on: December 17, 2010, 08:14:27 »

Thanks for the answer!

About licensing, since I am willing to provide the source, I guess I will no big issue there... Can something go wrong?

jean-louis

11

Plugin Development / About debugging a plug-in

« on: December 01, 2010, 22:55:28 »

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: [Select]

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

12

Plugin Development / Licensing a Vamp plug-in

« on: December 01, 2010, 10:00:55 »

Hi everyone,

I would like to ask: I used the skeleton from the plug-in SDK to make my plug-in. Can I release the source code and provide these source files (notably the modified plugins.cpp)? Is there some restrictions on the license I have to use in this case?

By the way, if I release the binaries (for free), are there restrictions? As I understand, the license on the SDK is quite loose w.r.t. that aspect. Of course, since I use other libraries (atlas, fftw), I ll check on those too... By the way, the fftw license is a GPL, which, from what I understand, makes it compulsory that I also release the source code, am I right?

Regards !

Jean-Louis

13

Host Forum: Sonic Visualiser / "Segmentation fault" on Ubuntu 10.04 ?

« on: November 30, 2010, 09:32:02 »

Hi everyone !

I have been developing a plug-in, lately, for sonic-visualiser (SV). I tested it with SV, under Ubuntu 10.04, using a command line like the following:

Code: [Select]

VAMP_PATH=. sonic-visualiser
When I try to load a file with the option in the menu (or equivalently with the button on the menubar), SV crashes with a "Segmentation fault" error message. I can however load a file by drag-n-dropping it over the window. I can then run my plug-in, which seems, on my few tests, to work without errors. When I try to open the plug-in dialog before the file is entirely loaded (I'm the impatient type of person), it again crashes with a segfault.

The weird thing is that, since it crashes even before I tell him to load the plug-in (and even when the plug-in is nowhere for SV to be found), I tried to launch it the "normal" way, from the ubuntu menu. It then seems to work OK.

If I run it from the terminal, though, I get the same behaviour. Here is the output I get:

Code: [Select]

$ sonic-visualiser
Registering interactive file finder
Loading qt_en_US... Failed
Failed to load Qt translation for locale
Loading sonic-visualiser_en_US... Done
OSCQueue::OSCQueue: Base OSC URL is osc.udp://...
View::View(0x9167a10)
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:f0salience:f0salience:f0salience" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:f0salience:f0salience:output" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:vampy:vampy-zc2:vampy-counts" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:vampy:vampy-zc2:vampy-crossings" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:mvamp:marsyas_bextract_zero_crossings:zero_crossing_counts" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:qm-vamp-plugins:qm-dwt:wcoeff" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:qm-vamp-plugins:qm-constantq:constantq" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:qm-vamp-plugins:qm-segmenter:segmentation" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:vampy:vampy-sf3:vampy-sd" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:vampy:vampy-sf3:vampy-sc" in recent transforms list
WARNING: MainWindow::setupRecentTransformsMenu: Unknown transform "vamp:vampy:vampy-mfcc:warped-fft" in recent transforms list
View::View(0x92ef150)
NOTE: Document::setModel: Layer 0x92f3408 ("Ruler") is already set to model 0 ("(null)")
NOTE: Document::setModel: Layer 0x9307c70 ("Waveform") is already set to model 0 ("(null)")
PluginRDFIndexer::indexConfiguredURLs
PluginRDFIndexer::indexConfiguredURLs: index url is http://www.vamp-plugins.org/rdf/plugins/index.txt
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/index.txt"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:35 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/vamp-example-plugins
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/vamp-example-plugins"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:35 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/ofa-vamp-plugin
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/ofa-vamp-plugin"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:36 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/vamp-libxtract
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/vamp-libxtract"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:37 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/qm-vamp-plugins
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/qm-vamp-plugins"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:37 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/mazurka-plugins
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/mazurka-plugins"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:38 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/vamp-aubio
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/vamp-aubio"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:39 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/match-vamp-plugin
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/match-vamp-plugin"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:39 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/vamp-onsetsds
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/vamp-onsetsds"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:39 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/mvamp
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/mvamp"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:40 2010
PluginRDFIndexer::indexConfiguredURLs: url is http://www.vamp-plugins.org/rdf/plugins/nnls-chroma
CachedFile::CachedFile: origin is "http://www.vamp-plugins.org/rdf/plugins/nnls-chroma"
CachedFile::check: Valid last retrieval at Tue Nov 30 09:12:40 2010
Finished setting up OSC interface
Comparing current version "1.7.2" with latest version "1.7.1"
Segmentation fault
The last line only appears when I try to open the "open file" dialog. On this log, the plug-ins were not found, because I removed them from the ~/vamp folder (I guess).

Well, I m not sure what exactly goes wrong there... Could the plug-ins I used (especially the one I develop) have "broken" my current installation of SV? Or is this something related to a build problem within SV?

Best regards,

Jean-Louis

added 1/12/2010: I ran the plugin-tester with the following command line:

Code: [Select]

$ VAMP_PATH=. ~/PATH/TO/vamp-plugin-tester -a
and obtained:

Code: [Select]

... <a lot of debugging "printf" stuff > ...
vamp-plugin-tester: All tests succeeded for this plugin

vamp-plugin-tester: All tests succeeded
Segmentation fault
What should I think of that?...

14

Plugin Development / Re: Visualisation plug-in development

« on: November 17, 2010, 13:27:25 »

A general colour-range editing function would be a very handy addition to SV, in fact...

Oh, yes, that's actually how I meant it. Is there some kind of "wish-list" where we could write that down?

With regard to compiling for distribution, I think the problem is that you can't build a dynamic object completely statically.  What you can do is enable static linking for the libraries that are not part of the standard runtime.  Something like:

Code: [Select]

g++ -o f0salience.so f0Salience.o plugins.o -Wl,-Bstatic -Wl,-soname=f0salience.so /usr/lib//libvamp-sdk.a \
  --version-script=vamp-plugin.map -llapack -lcblas -latlas -lfftw3 -Wl,-Bdynamic -lm

which switches static linkage on at the start of the library list and off again before the end of the library list and the (implicit) standard C and C++ runtimes.  That means your plugin will still link dynamically against libstdc++, but that is probably OK in practice.

Considering your answer, I tried several "flavors" for the flags. The following line actually did work:

Code: [Select]

g++ -o f0salience.so f0Salience.o plugins.o -shared -Wl,-soname=f0salience.so /usr/lib/libvamp-sdk.a \
    --version-script=vamp-plugin.map -static -Wl,-Bstatic -lcblas -latlas -lfftw3 -lm
which ends up with a significantly bigger .so file (a good sign?) and ldd tells me:

Code: [Select]

ldd f0salience.so
statically linked
So I guess I got what I wanted!

Now another trickier problem: do you think it could be possible to compile a DLL for windows, knowing that I use ATLAS and FFTW within my program? I checked a bit Cygwin and MingW, without much success so far... I saw in the plug-in skeleton Makefile some instructions to use mingw, but that did not help much.

It makes me think: would it be possible to make some more tutorials, on that topic (cross-compiling) and others? I have read a lot of the example plug-ins in order to get my own plug-in to work, which is fine, but some more comments on certain fields would have been helpful: I had to check the nnls-chroma plug-in by M. Mauch in order to fill-in the output descriptor's binNames field (BTW, I'd like to thank Matthias for releasing the source code)! But that's probably a lot to ask: I am already more than happy with what we already have thanks to your efforts!

So, thanks again for your reply and your help!

Jean-Louis

15

Plugin Development / Visualisation plug-in development

« on: November 05, 2010, 15:40:38 »

Hi everyone!

I develop a plug-in that provides a visualization of the F0 salience for an audio file.

I would like to know a few things, to make it more "user friendly": as I understand, the field 'binNames' of the output descriptor can be set such that it reflects the corresponding bin meaning (the F0 in my case). Would there be a way of calling some internal Sonic Visualiser (SV) things such as the piano display, on the left of the pane, to make this display a bit more meaningful?

By the way, in the visualisation, in SV, would there be a way of setting the min and max of the displayed values? for instance, let's say that for all the frames, all the bins, I have values between 0 and 10^8, and I would like to display a dynamic only between 0 and 100, would that be possible? From what I understand, that is not the way the little "turn button" does, am I wrong? For a better picture of what I m talking about, this would be the Matplotlib equivalent of "plt.clim([0, 100])".

At last, I was wondering how I should distribute it. I tried to compile my plug-in under Linux (Ubuntu 10.04) with the '-static' option, but I got a few errors:

Code: [Select]

g++ -I/usr/lib/ -Wall -fPIC   -c -o f0Salience.o f0Salience.cpp
f0Salience.h: In constructor ‘F0Salience::F0Salience(float)’:
f0Salience.h:94: warning: ‘F0Salience::m_maxIterations’ will be initialized after
f0Salience.h:84: warning:   ‘size_t F0Salience::m_numberFrames’
f0Salience.cpp:3: warning:   when initialized here
g++ -I/usr/lib/ -Wall -fPIC   -c -o plugins.o plugins.cpp
g++ -o f0salience.so f0Salience.o plugins.o -static -Wl,-Bstatic -Wl,-soname=f0salience.so /usr/lib//libvamp-sdk.a --version-script=vamp-plugin.map -llapack -lcblas -latlas -lfftw3 -lm
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22
/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [f0salience.so] Error 1

If anyone has an idea of what is going on there... Under MacOsX, it seems that the created dylib is statically linked with the necessary libraries.

Cheers! And thanks again to everyone working on that project! The plug-in interface is really simple and makes it (almost) easy to develop plug-ins! Congrats!

Jean-Louis