Messages

91

Host Forum: Sonic Visualiser / Re: Saving My Preferences To Appear at Startup

« on: April 26, 2011, 16:22:21 »

Thanks for the note -- you make a persuasive case.  I'll have a look and see how much work would be involved.  I think some of the work may have been done already for a different purpose, so let me check up on that.


Chris

92

Host Forum: Sonic Visualiser / Re: Exporting ONE image of all the panes

« on: April 26, 2011, 16:21:28 »

I'm afraid this isn't possible at all at the moment.


Chris

93

Host Forum: Sonic Visualiser / Re: Built on debian wheezy amd64 no audio port

« on: April 26, 2011, 16:20:40 »

/usr/bin/ld: ../svcore/libsvcore.a(Init.o): undefined reference to symbol 'XGetErrorText'
/usr/bin/ld: note: 'XGetErrorText' is defined in DSO //usr/lib64/libX11.so.6 so try adding it to the linker command line
//usr/lib64/libX11.so.6: could not read symbols: Invalid operation

This one is an error on my part -- svcore should not be referring to this symbol.  I'm not quite sure why it should actually fail to link for you, since it works here, but if you've got a workaround that should be enough for the moment.  I'll correct it in the code in the mean time.

But then I get an error:

../svapp/libsvapp.a(AudioTargetFactory.o): In function `AudioTargetFactory::createCallbackTarget(AudioCallbackPlaySource*)':
AudioTargetFactory.cpp:(.text+0x76f): undefined reference to `AudioJACKTarget::AudioJACKTarget(AudioCallbackPlaySource*)'
AudioTargetFactory.cpp:(.text+0xb54): undefined reference to `AudioJACKTarget::AudioJACKTarget(AudioCallbackPlaySource*)'


At this point I'm pretty much stuck. Any hint would be appreciated.

Can you delete svapp/o/AudioJACKTarget.o and re-run make in the svapp directory, and paste the g++ command that make runs?


Chris

94

Plugin Development / Re: Mean of a feature

« on: April 26, 2011, 16:15:36 »

"Plugin chaining is not something that's supported in the Vamp API, although you could write a Vamp plugin that was also a Vamp host and that loaded its own plugins.   The Vamp API won't go out of its way to help you if you try to do this but I don't think it will stand in your way."

I don't realy understand your second sentence. What do you mean ? (that's the topic ). Is it possible (and relatively easy, as I'm not a c++ crack) to do it in a host plugin ?

Sorry to take a while to come back to you on this (I've been on holiday).

All I meant was that the Vamp SDK does not contain any facility that is intended to support the development of plugins that are also hosts -- you would essentially have to write a Vamp host for yourself, using the Vamp Host SDK, within your plugin.

It should be possible to use the Vamp Host SDK from within a plugin, there certainly has never been any intention to prevent this from working.  But I don't know of any existing plugin that does it, and I don't have any example code to offer.

Essentially you would probably want to take the example host code from something like vamp-simple-host in the SDK distribution, and add a plugin load scan into your plugin at the constructor or initialise phase, storing a pointer to your loaded plugin within the "wrapper" plugin, and then delete it in the destructor.

I suspect there may be details that would get fiddly enough to make this a job for the more experienced C++ developer, but I'm not certain (I haven't tried it myself either).  I would in principle be interested in trying this myself, but time is too limited for me to be able to offer to do so.


Chris

95

Plugin Development / Re: Mean of a feature

« on: April 15, 2011, 09:15:54 »

Well, it's obviously possible in code to take some features and calculate their mean!  So I suppose your question is either about doing this within a plugin, or about whether any hosts have this feature already.

Plugin chaining is not something that's supported in the Vamp API, although you could write a Vamp plugin that was also a Vamp host and that loaded its own plugins.   The Vamp API won't go out of its way to help you if you try to do this but I don't think it will stand in your way.

At the host level, you could also look at the batch host Sonic Annotator (http://omras2.org/SonicAnnotator) which includes various averaging/summarising options.


Chris

96

Plugin and Host Announcements / QM Vamp Plugins v1.7 now available

« on: April 14, 2011, 15:09:46 »

Version 1.7 of the QM Vamp Plugins -- a set of audio analysis plugins in the
Vamp plugin format, developed at the Centre for Digital Music at Queen Mary,
University of London -- is now available for download.

Plugins included are note onset detector, beat and barline tracker, tempo
estimator, key estimator, tonal change detector, structural segmenter, timbral
and rhythmic similarity, wavelet scaleogram, adaptive spectrogram, note
transcription, chromagram, constant-Q spectrogram, and MFCC calculation.

The main change for this release is to the license under which the plugins
are distributed.  Formerly they were available in binary form only; they are
now under the GPL, with source code provided.

For downloads, please see:

 http://isophonics.net/QMVampPlugins

For documentation of these plugins, please see:

 http://www.vamp-plugins.org/plugin-doc/qm-vamp-plugins.html


Chris

97

Plugin and Host Announcements / Sonic Visualiser v1.8 now available

« on: April 14, 2011, 15:07:50 »

Sonic Visualiser is an application for inspecting and analysing the
contents of music audio files. It combines powerful waveform and
spectral visualisation tools with automated feature extraction plugins
and annotation capabilities.

Version 1.8 of Sonic Visualiser is now available.

 http://www.sonicvisualiser.org/

This is primarily a bug fix release.
For more information, please read the change log at:

 https://sourceforge.net/projects/sv1/files/sonic-visualiser/1.8/CHANGELOG/download


Chris

98

Getting and Using Vamp Plugins / Re: Problem with Sonic Visualiser 1.7.2 and Vamp Plugs on winXP

« on: April 14, 2011, 15:00:49 »

I recently discovered this site and have a newbee problem:
I copied the Vamp Plugs to C:\Program Files\Vamp Plugins but SV can´t find them.
What did I wrong?

There are two common possibilities for plugins not being found on Windows:

• If you are using a 64-bit version of Windows, then you have to put plugins in C:\Program Files (x86)\Vamp Plugins instead of in the plain Program Files folder (which is for 64-bit binaries; the existing plugins and hosts are all 32-bit).  The Vamp plugin documentation used to be misleading on this point.  I've now updated the instructions at http://vamp-plugins.org/download.html#install to reflect this.
• If your Windows installation does not have English as its native language, then Program Files may be called something else; you need to make the Vamp Plugins folder inside whatever Program Files is actually called (which obviously would depend on the language).

I'm not sure whether the first of these applies to XP though (are there 64-bit versions of XP in widespread use?)


Chris

99

Host Forum: Sonic Visualiser / Re: sonic visualiser real time?

« on: April 14, 2011, 14:57:14 »

I use Sonic Visualiser to analyse industrial sounds like vibrations from pipelines. Is it possible to feed audio real time into Sonic Visualiser? Or what would it take to modify the program to accommodate this?

Hello there, and again my apologies for not attending to this sooner.

I'm afraid the short answer is that this is not possible at all and that none of the current code is designed in a way that would make it easy to adapt to real-time use.  A very early design decision was made with SV to handle only offline use cases, but to do so for arbitrarily large files, and this decision permeates quite a lot of the code.

I'm not quite sure what other utilities to suggest (does anyone else have any ideas?)  Perhaps baudline?


Chris

100

Host Forum: Sonic Visualiser / Re: Built on debian wheezy amd64 no audio port

« on: April 14, 2011, 14:53:58 »

Hi -- apologies to you and to everyone for my inattention to this forum in recent weeks.

I did spot these in the build process which are probably causing the trouble:
AudioCoreAudioTarget.h:0: Warning: No relevant classes found. No output generated.
AudioJACKTarget.h:0: Warning: No relevant classes found. No output generated.
AudioPortAudioTarget.h:0: Warning: No relevant classes found. No output generated.
AudioPulseAudioTarget.h:0: Warning: No relevant classes found. No output generated.

Yes, you need to have at least one playback target!  JACK and Pulse are the most likely candidates on Linux.  With the 1.7 release, this is probably a question of adjusting the defines in the prf/sv.prf file (it does use pkg-config to pick up what libraries are available, but presumably this has failed).

The recently-released 1.8 has a different build system, using autoconf for these things, which may be worth a try.  So far there is only a 32-bit Linux binary available for that, but hopefully I should be able to make a 64-bit one as well shortly.


Chris

101

Plugin Development / Re: Vector problems?

« on: January 31, 2011, 15:59:17 »

Hello there -- I was sure I'd replied to your question, but my reply clearly isn't there -- maybe I composed it but forgot to post it.

My first suggestion in a situation like this would always be to run "make clean" and make again.  I realise that you may have done this already (perhaps many times!) but it's by far the most common cause of this sort of problem -- you change a header but the Makefile lacks the necessary dependencies to rebuild all of the files that include the header when you next run "make", so that two object files end up having different ideas about the size of a particular object.

I'm not sure how that squares with your later comment that you've already tried it on more than one machine, though.  I just thought I should ask anyway.

(I wonder if we could improve the skeleton Makefile from the SDK to help with this situation.)

It _is_ expected that a plugin may crash in the tester but apparently run fine in other hosts -- the idea of the tester is to test the plugin in some situations that other hosts would not necessarily exercise, so that you can get better test coverage before you release and you won't suddenly find that it fails to run in some later version of a host that works differently in some way.  And I'm afraid this is more likely to indicate a bug in the plugin than in the tester -- not that I believe the tester to be bug-free, but it has been reasonably widely tested.


Chris

102

Plugin Development / Re: About debugging a plug-in

« on: January 25, 2011, 10:14:49 »

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?

If m_powerSpectrum is a member of the plugin class and is allocated in the initialise method, then it should be freed in the destructor.

Note that, in this case, it should also be assigned to zero in the constructor, or else the destructor will crash if initialise is never called -- it is OK to delete[] a null pointer, unlike free() in C; but it's never OK to delete a pointer that has been declared but never initialised at all.

In the reset method, then, you could either delete and reallocate the pointer, or more likely you could reset the contents of its array to zero (since its intended size would be unchanged), or even leave them unchanged if their values don't matter.

If powerSpectrum was a variable allocated in process() and then used only in process(), then it should be deleted before process() returned -- but you'd obviously have to be sure to have copied all of the data you needed out of it before deleting it.

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?

It sounds like you just got lucky under Linux and OS/X.  Possibly it would have crashed later if the data had been deleted.

Generally it's a very bad idea to use fixed-size string arrays for data that you can't be totally confident of the length of -- this is a big cause of a very common class of security-related buffer overflow errors and, while that's maybe not going to be a practical issue in this code, it means it's something well worth learning to avoid in general.

Also, if your "strings" are actually char pointers allocated using new char[] or even malloc(), then it's a bad idea to put them into a vector because the vector will be unable to delete them and recover the memory when its destructor is called (as they are not objects with destructors themselves).

Generally, if you want a vector of strings in C++, you should always use a vector of std::string.  If you want to "print" float or int values into the strings, consider using a std::ostringstream to build them.

I hope I'm not barking up the wrong tree here -- I'm making some rather wild guesses about what your data structure actually is, so my apologies if I've misunderstood!


Chris

103

Getting and Using Vamp Plugins / Re: Unable to load library "/usr/../qm-vamp-plugins.so": `GLIBCXX_3.4.9' not found

« on: January 25, 2011, 09:57:34 »

Steve,

For a 64-bit CentOS, it might be worth trying this build:

  http://sonicvisualiser.org/pre/qm-vamp-plugins-0.6-svn20100629.x86_64.rpm

As the title and date-stamp suggest, it was a build from the private QM repository in June made for a particular application on a particular machine -- I'm not totally confident about the details of which machine or application, though!

With regard to source code, the answer becomes more interesting -- the QM plugins have so far always been closed-source, but we have just during the last month published the source under the GPL.

This hasn't been announced properly yet because no binary release has been made from the new code yet, there is some administrative work to do with updating the site for the new code location, and some details like build instructions are lacking, but the code is available:

  http://code.soundsoftware.ac.uk/projects/qm-vamp-plugins

Note that the plugin code depends on another library, also hosted at the same place (it's linked from the intro on that page).  Currently, to build the code, you will need to pull both projects from their Mercurial repositories, use "qmake" to build a Makefile from their project files, and then make.  The use of "qmake" (the Qt build tool -- even though none of the actual code uses Qt) is an untidy stopgap -- sorry -- this is one of the several things still to be tidied up.


Chris

104

Plugin Development / Re: About debugging a plug-in

« on: January 07, 2011, 14:51:27 »

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

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

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.

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.

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.

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.


Chris

105

Plugin Development / Re: About debugging a plug-in

« on: December 20, 2010, 17:28:10 »

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