Messages

211

Plugin Development / Re: unresolved symbol errors while linking vamp plugin

« on: March 06, 2009, 13:46:30 »

I put the source files of aubio library in my project but still i got unresolved symbol errors.

Which symbols were unresolved then?  Were they also __imp__ symbols, or something different?


Chris

212

Plugin Development / Re: unresolved symbol errors while linking vamp plugin

« on: March 06, 2009, 10:45:46 »

It's not quite clear to me where you got the vamp-aubio.lib static library from?  There isn't a static library included in the vamp-aubio distribution.

I'm far from expert on the details of Windows libraries and linkers -- and this is clearly a Windows-specific problem.  But I think this sort of error, in which you have an unresolved symbol with an "__imp__" prefix, means that you have code that was compiled specifically to be used in a DLL, where the symbols have been declared with __declspec(dllimport).  I don't think you can link such code statically without some further trickery.  Generally, to produce a static library, you would have to compile the code in a different way using some pre-processor symbol that tells the compiler not to generate the DLL import prefixes.  Exactly how to do this, usually, depends on the build system for the library.

I'm sorry I don't have any specific suggestions.  You might get more help if you ask this sort of question on a site with a higher proportion of Windows experts (such as stackoverflow.com), although it would help if you can express the problem in such a way that people can answer it without knowing too much about the specific libraries you are using.

Alternatively, rather than trying to link against a static library, you might find it simpler to add the source files to your project and compile them all together.

(The specific symbol that you have -- lc_codepage -- comes from the locale library, and possibly originates with one of the Unix-Windows cross compiler support libraries from MinGW.)


Chris

213

Host Forum: Sonic Visualiser / Re: classification

« on: January 27, 2009, 15:02:42 »

Sonic Visualiser aims at analysis and inspection of data within an audio file, not at what you might call collection-level analysis such as classification or searching.  Although there is a Vamp plugin in the QM set that is capable of calculating similarity metrics for audio files, it is not really useful within Sonic Visualiser because SV has no way to provide it with data across collections of files, or to cluster and make use of the results.

The QM similarity plugin expects its input to be in the form of "one audio track per channel" for 2..n channels, and it calculates and returns distance metrics for the channels with respect to each other.  You can (laboriously) get meaningful results from this within SV, if you generate an audio file "by hand" that contains a different track on each channel and then load this file and run the plugin on it.  But it's far from ideal.

It would be nice to have an option in SV's plugin configuration dialog to tell it to use all of a set of audio files as input, one per channel -- there are other plugins that would benefit from this, such as the MATCH alignment plugin.  But that isn't possible now.


Chris

214

Plugin Development / Re: Coding in Vamp and Compiling it..

« on: January 26, 2009, 14:30:13 »

Hazel,

No, the Vamp plugin host does not do any filtering or other DSP preprocessing on the audio data you receive.

I'm not aware of whether there is documentation available for the methods and code used in the Aubio library or not.  You could try its author's PhD thesis (http://aubio.org/phd/) which is quite informative about some of the methods involved, although I'm not sure whether it really covers coding documentation.

If you were using the Aubio library, you could link either dynamically or statically against it -- linking statically would mean you did not need to distribute the library separately, but you would need to build Aubio as a .lib static library.  Alternatively, you could simply draw techniques from it via copy and paste, or use the Aubio code as inspiration.

Note that Aubio is licensed under the GPL, which means that if you draw code from it either by copying it or linking to it, you will need to license your own code under the GPL also (if you publish it), which means providing your source code and properly acknowledging the copyright of the Aubio code, among other things.

I'm not sure that I understand the other question -- it is certainly possible to discriminate on the basis of frequency if your code calculates it, although maintaining a stable frequency estimate (i.e. without artifacts like wild diversions at note onsets) is not all that simple.  That "while" you have should probably be an "if", of course.  The process() function receives a single block of audio each time it is called, so if it can process one block and make a pitch discrimination based on only that block and any prior information it may have, then it can return a feature, perhaps one having a single value that indicates the class of voice (0 for soprano, 1 for tenor or whatever) with an appropriate label.  Check the AmplitudeFollower example plugin for a plugin that returns one single-featured value per process call.  Of course, I'm making an assumption that may not be correct about what your plugin is intended to calculate in terms of returned feature structure.


Chris

215

Plugin Development / Re: Coding in Vamp and Compiling it..

« on: January 20, 2009, 12:57:21 »

Hazel,

There is a VC++ project file for the Vamp example plugins (VampExamplePlugins.vcproj) in the build folder of the Vamp SDK 2.0 release.  This could easily be modified to build other plugins -- just remove the examples\*.cpp files from the project and replace them with your own.

The project file provided is for Visual C++ 2008 (full or express edition), rather than 2005.  However, I had thought that project files for VC++ projects were backward compatible and could be opened in VC++ 2005 as well -- I know that this is not the case for solutions or .NET projects, but I thought it was true of pure C++ projects like these.  I may be wrong about that.  What sort of errors are you seeing?

I'm not especially familiar with pitch detection algorithms, I'm afraid.  There is quite good overview with several promising-looking references on the Wikipedia page on the subject (http://en.wikipedia.org/wiki/Pitch_detection_algorithm) -- some of those links may be worth a try.

Remember that to carry out a frequency-domain algorithm, you should need only to have your plugin return FrequencyDomain from its getInputDomain() method and the host will provide data that has already been processed through FFT (you just need to make sure you've properly understood the format of the data that is passed to the process() call!).  For time domain methods, return TimeDomain and the host will give you the original audio samples, block by block, in process() calls.


Chris

216

Host Forum: Sonic Visualiser / Re: SV tag files syntax

« on: January 09, 2009, 10:45:52 »

Boris,

Sorry to take so long to respond.

Do you mean that you want start time and end time as opposed to start time and duration, which SV normally exports?

If so, then I'm afraid I can't think of a way to do this using SV at the moment -- but it's a good candidate for an additional feature, if you would like to submit a feature request using the SourceForge tracker.

In the mean time, one could always convert the files using an external tool.  To take the immortal example of Perl:

Code: [Select]

$ cat test.txt
1.223 2.1543 sourceA
2.542 14.133 sourceB
3.161 0.041 sourceC
$ cat rewrite.pl
while (<>)
{
    my ($a,$b,$c) = split /\s+/;
    $b = $a + $b;
    print join " ", ($a,$b,$c), "\n";
}
$ perl rewrite.pl test.txt
1.223 3.3773 sourceA
2.542 16.675 sourceB
3.161 3.202 sourceC
$


Chris

217

Host Forum: Sonic Visualiser / Re: 3D visualization?

« on: January 09, 2009, 10:29:58 »

Jokot,

Sorry to take so long to get back to you on this one.

You're referring to a sort of "waterfall" visualisation with a series of tracks shown as individual lines that rise and fall? I'm afraid there's no visualisation like this in SV at the moment, and we don't have any very active plans to add one -- although you're welcome to open a feature request for it on the tracker on the SourceForge page.

This is not something that a plugin can do for you, either; the plugin formats supported by SV, such as Vamp plugins, simply generate structured data -- it's up to SV to decide how to plot the results, so if SV doesn't support a waterfall plot, there will be none available.


Chris

218

Plugin and Host Announcements / Sonic Annotator - a batch utility for audio feature extraction

« on: December 12, 2008, 11:49:48 »

Sonic Annotator is a utility program for batch feature extraction from audio
files.  It runs Vamp audio analysis plugins on audio files and can write the
result features in a selection of formats, in particular as RDF using the
Audio Features and Event ontologies.

A somewhat experimental first public release (0.1) is now available.

For more details and for downloads, please see

  http://www.omras2.org/SonicAnnotator

Sonic Annotator was developed at the Centre for Digital Music, Queen Mary,
University of London.  It was funded by the EPSRC through the OMRAS2 project
and is Free Software published under the GNU General Public License.


Chris

219

Plugin and Host Announcements / Vamp libxtract plugins updated

« on: December 12, 2008, 11:29:26 »

The Vamp libxtract plugin set is a library of low-level feature extraction plugins using Jamie Bullock's libxtract library to provide around 50 spectral and other features.

See http://libxtract.sourceforge.net for more details about libxtract.

A new update of this plugin set (the 20081202 update) is available fixing a number of bugs in the plugins, following a review and user feedback.  This set should be more stable and useful than previously.  See http://www.vamp-plugins.org/download.html for source and binary downloads.


Chris

220

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

« on: December 12, 2008, 11:25: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.4 of Sonic Visualiser is now available.

   http://www.sonicvisualiser.org/

This is a feature release, containing several new features and a number of bug
fixes over the previous 1.3 release.  For more details, please read the release
notes at

   https://sourceforge.net/project/shownotes.php?release_id=646456

Sonic Visualiser contains advanced waveform and spectrogram viewers, as well
as editors for many sorts of audio annotations. Besides visualisation, it can
make and play selections based on the locations of automatically detected
features, seamlessly loop playback of single or multiple noncontiguous
regions, synthesise annotations for playback, slow down playback while
retaining display synchronisation, and show the ongoing alignment in time
between multiple recordings of a piece with different timings.

Sonic Visualiser supports the Vamp plugin API for plugins that extract
descriptive or analytical data from audio.

Sonic Visualiser was developed at the Centre for Digital Music, Queen Mary,
University of London:

   http://www.elec.qmul.ac.uk/digitalmusic/

Ongoing work on Sonic Visualiser and audio feature representation in the
semantic web is carried out as part of the OMRAS2 project funded by the EPSRC. 
See

   http://omras2.org/

for more information.

Sonic Visualiser is Free Software distributed under the GNU General Public
License.  The 1.4 release is available now in source code form or as binaries
for Linux, OS/X, and Windows.


Chris

221

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

« on: December 12, 2008, 11:24:39 »

Version 1.5 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 tracker, tempo estimator, key
estimator, tonal change detector, structural segmenter, timbral and rhythmic
similarity, chromagram, constant-Q spectrogram, and MFCC calculation.

This release focuses on reliability and performance improvements.

For downloads, please see:

 http://www.elec.qmul.ac.uk/digitalmusic/downloads/index.html#qm-vamp-plugins

The plugins are available in binary form only and may be freely used for any
purpose, and redistributed for non-commercial purposes only.  Supported
platforms are 32- and 64-bit Linux, 32-bit Windows, and OS/X 10.4 or newer
(Intel/PPC universal).

This release also features more substantial documentation than previously,
available at:

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


Chris

222

Plugin Development / Vamp plugin SDK v2.0 now available

« on: December 12, 2008, 11:23:28 »

Vamp SDK version 2.0 is now available

Version 2.0 of the Vamp plugin SDK is now available.

   http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins written in C or C++.  Its SDK features an easy-to-use set of C++ classes for plugin and host developers, a reference host implementation, example plugins, and documentation.  It is supported across Linux, OS/X and Windows.

A documentation guide to writing plugins using the Vamp SDK can be found at http://www.vamp-plugins.org/guide.pdf.

What's new in 2.0?

• Each returned feature can now specify a proper duration as well as start time, value array, and label.
• A new PluginSummarisingAdapter is provided in the host SDK, permitting hosts to easily obtain summary results such as averages based on a plugin's returned features.
• An RDF ontology is provided for the description of Vamp plugin capabilities and configurations (see http://omras2.org/VampOntology).
• The SDK libraries have been reorganised so as to draw a clearer distinction between plugin and host SDKs.
• Better platform-specific build documentation is provided (in the build directory), particularly for MSVC builds which now also feature project files for the example plugins.
• Two new example plugins have been added (Simple Power Spectrum and Fixed Tempo Estimator).
• The command-line host provided now has an extra-informative plugin information listing option (--list-full).

Backward compatibility

A detailed compatibility statement is included in the SDK, but to summarise:

• Plugins and hosts built with 1.x and 2.0 SDKs are mutually compatible.  You can load old plugins in new hosts and new plugins in old hosts.
• Plugins written for 1.x can be compiled against 2.0 without modification.
• Hosts written for 1.x will require some changes to #include directives, but most hosts should compile against 2.0 without other modifications.
• Although the plugin binary interface is compatible with 1.x, the SDK libraries are not binary compatible with the 1.x libraries. Plugins and host code will need to be recompiled if they are to be updated to 2.0, not just re-linked.

Credits

This work was carried out at the Centre for Digital Music, Queen Mary, University of London.  It was funded by the EPSRC through the OMRAS2 project EP/E017614/1.  See http://omras2.org/ for more information.


Chris

223

Plugin and Host Announcements / Vamp plugin SDK v2.0 now available

« on: December 12, 2008, 10:38:16 »

Vamp SDK version 2.0 is now available

Version 2.0 of the Vamp plugin SDK is now available.

   http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins written in C or C++.  Its SDK features an easy-to-use set of C++ classes for plugin and host developers, a reference host implementation, example plugins, and documentation.  It is supported across Linux, OS/X and Windows.

A documentation guide to writing plugins using the Vamp SDK can be found at http://www.vamp-plugins.org/guide.pdf.

What's new in 2.0?

• Each returned feature can now specify a proper duration as well as start time, value array, and label.
• A new PluginSummarisingAdapter is provided in the host SDK, permitting hosts to easily obtain summary results such as averages based on a plugin's returned features.
• An RDF ontology is provided for the description of Vamp plugin capabilities and configurations (see http://omras2.org/VampOntology).
• The SDK libraries have been reorganised so as to draw a clearer distinction between plugin and host SDKs.
• Better platform-specific build documentation is provided (in the build directory), particularly for MSVC builds which now also feature project files for the example plugins.
• Two new example plugins have been added (Simple Power Spectrum and Fixed Tempo Estimator).
• The command-line host provided now has an extra-informative plugin information listing option (--list-full).

Backward compatibility

A detailed compatibility statement is included in the SDK, but to summarise:

• Plugins and hosts built with 1.x and 2.0 SDKs are mutually compatible.  You can load old plugins in new hosts and new plugins in old hosts.
• Plugins written for 1.x can be compiled against 2.0 without modification.
• Hosts written for 1.x will require some changes to #include directives, but most hosts should compile against 2.0 without other modifications.
• Although the plugin binary interface is compatible with 1.x, the SDK libraries are not binary compatible with the 1.x libraries. Plugins and host code will need to be recompiled if they are to be updated to 2.0, not just re-linked.

Credits

This work was carried out at the Centre for Digital Music, Queen Mary, University of London.  It was funded by the EPSRC through the OMRAS2 project EP/E017614/1.  See http://omras2.org/ for more information.


Chris

224

Plugin Development / Re: build new dll from the example

« on: November 30, 2008, 11:08:52 »

Hello!

Two possible lines of enquiry:

1. No plugin entry point?

Did you compile _just_ the PercussionOnsetDetector.cpp file into the DLL?

A Vamp plugin library also requires a public entry point which is a C function that lists the plugins that are available in the library.  In the example plugin set, this is provided by the file plugins.cpp -- you will need to compile either this file, or a similar one produced by cut-and-paste but listing only the PercussionOnsetDetector and not the rest of the example plugins, into your DLL as well.

2. Plugin entry point is not public in the DLL?

If you are building using Visual Studio, then the default for the VS linker is to make all symbols in the DLL hidden, which means the host will not be able to find the appropriate entry point when it looks at the plugin library.

You need to change this so that the single entry point (vampGetPluginDescriptor in the plugins.cpp file) is made public in the DLL.  Windows-specific code often does this with a __declspec(dllexport) attribute before the function declaration in the code, but this does leave you with less portable code.  Another way that I think is preferable is to add the linker option /EXPORT:vampGetPluginDescriptor to the project.

The next release of the SDK (due shortly) will be clearer about this in the documentation -- the current version does not really have any documentation specific to Visual Studio (which is the only major compiler/linker for which this is an issue -- the OS/X linker and the GNU linker on Linux both make symbols public by default).  It will also include an example project with this option set appropriately.

Hope this helps!


Chris

225

Getting and Using Vamp Plugins / Re: vamp-libxtract too many outputs from plugin

« on: November 06, 2008, 11:48:29 »

Yes, that was a stupid one.  Thanks for reporting it!

I've fixed it in Subversion (rev 907 at https://vamp.svn.sourceforge.net/svnroot/vamp/vamp-libxtract-plugins/trunk).  If you want to fix your local copy without retrieving a new one, this is the patch:

Code: [Select]

--- plugins/XTractPlugin.cpp (revision 906)
+++ plugins/XTractPlugin.cpp (working copy)
@@ -225,6 +225,7 @@
      m_outputBinCount = 1; break;
     }
 
+    m_outputDescriptors.clear();
     setupOutputDescriptors();
 
     m_initialised = true;

Of course, I will also push out a release with this fix soon.


Chris