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

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

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

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

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

[Vamp SDK version 2.0 is now available]

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

[Vamp SDK version 2.0 is now available]

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

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

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:

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

Yes, I can confirm this.  I'll look into it.


Chris

Just moving this one to the Sonic Visualiser board, as well, since it is about SV (at least, I think it is?) rather than generally about Vamp plugins.

http://vamp-plugins.org/forum/index.php?topic=47.0

Sonic Visualiser can export MIDI files, but only from Notes type layers.  If a note layer is the current layer, then when you go to File -> Export Annotation Layer, you will see MIDI as one of the exportable file types.

If you have data in some other layer (such as a time-value layer) that you want to export as MIDI, it may be possible to do this by copy-pasting the data points into a new Notes layer and exporting that.  You'll always get some sort of MIDI file that way -- but SV is often not clever enough to determine what the correct pitch for each note should be when it is pasted from a non-note layer, so the results may not actually be useful.

There is probably room for improvement in this area, if you have specific test cases that you would like to see working.


Chris

Aymeric,

I'm not sure I understand whether you're asking for something in particular, but there are several built-in functions that provide various ways of looking at FFT data.  All of the spectrogram and spectrum options on the Pane menu, for example, produce different sorts of FFT plot.

I suggest looking at the Sonic Visualiser reference manual, particularly the Spectrogram and Spectrum sections:

http://www.sonicvisualiser.org/doc/reference/1.3/en/#spectrogram
http://www.sonicvisualiser.org/doc/reference/1.3/en/#spectrum

for more information.


Chris

Hannes,

Sorry to take so long to reply to this.  It's a bit of a subtle one, I wanted to check the figures first, and I'm afraid it took a little while to get around to that.

This behaviour is essentially a bug in the result printing part of the simple host in the Vamp SDK, although there is also a shortage of documentation for the (legitimate) behaviour of the SDK code that leads to this bug.  Sonic Visualiser appears to have the correct output here.  I will aim to get the bug fixed and the behaviour properly documented in the 1.4 SDK release.

The cause is to do with the handling of frame timestamps when using plugins that have frequency-domain input.  Sonic Visualiser feeds these plugins frames starting from the frame that is centred on the first input audio sample, which is timestamped at time zero.

The simple host, in contrast, begins with a frame that starts at the first input audio sample (not such a good thing to do, because it means that samples earlier in the file than half the frame size are not properly represented, but technically legitimate).  This host uses a PluginInputDomainAdapter to handle the conversion to frequency domain if the plugin requested it; for the first frame, it feeds to the adapter these time-domain samples starting at the first input audio sample, with a timestamp of zero.  The adapter recognises that the frequency domain input timestamp should be adjusted to the centre of the frame, and makes that adjustment.  However, the host is not aware that that adjustment has happened, and so prints out the results with the un-adjusted timestamps.  That's the bug.

The results shown in SV and those returned by the simple host will match for plugins that use time-domain input, and should also match for plugins with frequency-domain input where their outputs are timestamped explicitly by the plugin using "adjusted" timestamps, for example the Onsets output of the Simple Percussion Onset Detector example plugin.  Where they differ (with SV being correct and the simple host wrong) is for plugins with frequency-domain input whose outputs are timestamped implicitly by the host, for example the chromagram -- the discrepancy is particularly marked for the chromagram because of its long frame size; the difference of 0.74 seconds you mention is half of that frame size.


Chris

Sandy,

I'm afraid it isn't possible in current versions of SV to load two files at different "start offsets".  All of the loaded files effectively start from time 0 on the timeline.

I think there may be an outstanding feature request for this -- it would certainly be a useful feature sometimes -- but it's not there now.


Chris