Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cannam

Pages: 1 ... 4 5 [6] 7 8 ... 19
76

jVamp is a JNI (Java Native Interface) library that permits Java applications to load and use Vamp audio analysis plugins.

jVamp is intended for application developers who are interested in adding capabilities to Java applications or a Java environment; it's not currently something that an end-user would normally wish to install. But if you are working in Java, you might well find it interesting.

Note that jVamp is intended to be compatible with the Android NDK as well as desktop Java, though it hasn't been tested there (and existing binary distributions of plugins do not usually include ARM builds).

See http://code.soundsoftware.ac.uk/projects/jvamp for more information.

Chris

77
Plugin Development / Vamp plugin SDK v2.4 now available
« on: July 18, 2012, 13:16:57 »
Version 2.4 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.

Version 2.4 is a maintenance and bugfix release. The main addition is a simple FFT implementation for plugins to use. For more details, see the changelog at

http://code.soundsoftware.ac.uk/projects/vamp-plugin-sdk/repository/entry/CHANGELOG


Chris

78
Sonic Annotator is a utility program for batch feature extraction from
audio files.  It runs Vamp audio analysis plugins with specified
parameters on audio files, and writes the result features in a
selection of formats, in particular as RDF using the Audio Features
and Event ontologies, or as simple CSV files.

Version 0.7 is now available.

For more details and for downloads, please see

 http://www.omras2.org/SonicAnnotator


Chris

79
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 2.0 of Sonic Visualiser is now available.

 http://www.sonicvisualiser.org/

This is a maintenance release -- the major version-number bump
arrives simply because the previous release was 1.9 and 2.0 is the
obvious next number!

This release adds a fullscreen mode and restores the ability to
replace the main audio model (leaving the rest of the session intact)
which was lost in the session-templates feature work for 1.9.

Note that the default OS/X build of Sonic Visualiser is now a
64-bit one. This means it requires Vamp plugins with 64-bit
support (either 64-bit plugins or at least plugins with a 64-bit
Intel version in their universal wrapper). Many of the commonly
used Vamp plugins have had 64-bit distribution for some time,
but not all of them have -- a couple still need to be updated.

For more information, please read the change log at:

 http://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG


Chris

80
But when trying this with SV, the plugin runs (i.e. there's no initialisation error), regardless of what blockSize I choose in the graphical interface.

Ah, I see what's happening here... SV is being too clever for its own good.

What's happening is that when initialise() fails, SV then quietly reinitialises the plugin using its preferred settings and runs it with those instead.

That is almost certainly a bad idea. I'm struggling to think of any situation in which it would be a particularly wise thing to do. There might be one, though, and I ought to check the version control logs before I intemperately rip out the code for the forthcoming release!


Chris

81
Nice. I've had a look - any specific reason for using Cross's implementation?

Just that it is very, very simple -- it's the simplest implementation I know for the most basic level of support.

Users who really care about it (either because they want the fastest or because they need some specific functionality) will probably want to do something else regardless of whether the provided version is from Cross, Ooura, or KissFFT. This way at least it doesn't provide a significant overhead in library complexity.

It's slow, compared to the fastest implementations, but it's not so slow as to be a huge overhead in most real-world methods. It's good enough to be a sensible way to get your algorithm started.


Chris

82
Extra question 1: from the programmer's guide I take it the first block is not centred on time zero but rather starts at the first sample of the audio right? (double checking, as this could cause alignment issues when checking against ground-truths centred on time 0).

Depends on the host, but you can tell from the timestamp provided.

The docs (http://code.soundsoftware.ac.uk/embedded/vamp-plugin-sdk/classVamp_1_1Plugin.html#ae4aed3bebfe80a2e2fccd3d37af26996) say that "[t]he timestamp will be the real time in seconds of the centre of the FFT input window". Therefore, if the first timestamp is zero, that should mean you are being passed a window centred on the start of the audio rather than starting with the first sample.

Quote
Extra question 2: imagine I want initialisation to fail because I'm not happy with something (e.g. sampling rate). Is there any way of communicating the specific reason for the failure to the user?

Sadly not.

Quote
Quote
In hindsight I wish we had put a generally accessible FFT implementation in the SDK on the plugin side

Yes that would definitely speed up the development process for us MIR folk rewriting our code as vamp-plugins.

Well, I was working on the SDK today anyway so I've added it for the 2.4 release. Not everything is updated yet, but the source is at http://code.soundsoftware.ac.uk/projects/vamp-plugin-sdk/files now.


Chris

83

Hello!

1) Sampling rate:

Imagine my algorithm requires a fixed sampling rate (e.g. fs = 44100), block size (e.g. 2048 @ fs = 44.1k) and hop size (e.g. 1024 @ fs=44.1kHz). I understand that I can specify a preferred block and hop size, and even return false in the initialization function if the host specifies something else. But, what about the sampling rate? Specifying a required block/hop size (in samples) is not really useful if the sampling rate is not known.

I'm afraid the samplerate is one thing your plugin has no control over. It must accept whatever's supplied in the constructor, and can only then return false on initialise if the rate is unsatisfactory.

Note that the plugin's block and hop size can depend on the samplerate, they don't have to be hardcoded -- if the reason you want to fix the samplerate is in order to have known block and hop size in physical units (i.e. seconds), you may be able to do it the other way around -- calculate the block and hop size on request based on the samplerate.

Quote
I realise I can save the value of inputSampleRate to a parameter

You don't actually need to save it, it's stored for you in the Plugin base class. (This is probably bad form in terms of software practice, but still)

Quote
Is there no way to re-sample the audio before it is chopped into blocks?

No.

Quote
2) Time-domain filtering:

Is there any way to apply a time domain filter first, and then get the input in the frequency domain? Just hoping to avoid having to compute the DFT inside the plug-in itself.

No, the frequency-domain input is essentially a convenience option for plugins simple enough to be happy to work from STFT data without having to have too much control over it (the host also controls the window shape, for example). More sophisticated plugins will need to work from time-domain data.

In hindsight I wish we had put a generally accessible FFT implementation in the SDK on the plugin side, as well as in PluginInputDomainAdapter on the host side -- there are now many, many duplicates of FFT functions in Vamp plugins out there! Perhaps it's not too late to add it, even.

Quote
3) Sonification (sonic visualiser):

In sonic visualiser I see that some output types can be sonified (e.g. clicks at detected onsets). If the output of my plug-in is a continuous per-frame frequency value (in Hz), is there any way to sonify the output in sonic visualiser, e.g. with a sinusoid that follows the frequency of the output?

No, Sonic Visualiser only contains a MIDI-note-based sound generator that uses sampled sounds. Again though, I know quite a lot of people would find this useful. Maybe I should look at it...

Sorry to have such a negative list of responses for you. The positive side is that it looks as if you've understood the SDK and its limitations pretty well...


Chris



84
Plugin Development / Re: VamPy: Vamp plugins in Python
« on: July 11, 2012, 12:00:57 »
Hi there --

The forum is not abandoned exactly, but it is certainly a bit... sleepy.

It's become quite hard to maintain because most of the monitoring work goes into eliminating spam registrations (there is a ratio of at least 100 to 1 of spam to non-spam registration attempts). This also means new registrants can take a long time to be approved, contributing to the general lack of liveliness -- I suspect quite a few people have registered but forgotten what they were going to ask by the time their registrations were approved.

In this case, also, I am not sure whether the main VamPy developer reads the forum -- I will forward these questions.


Chris

85
Host Development / Re: Host SDK: Thread Safety
« on: February 08, 2012, 13:15:12 »
Hello there -- thanks for the comment.

Thread safety is an important requirement for Mixxx. We have three threads accessing the PluginLoader class.
A brief look at the PluginLoader source code showed that PluginLoader::getInstance() is not thread-safe. Moreover, 
PluginLoader::loadPlugin returns a " new Vamp::PluginHostAdapter "( PluginLoader.cpp:407 ). At this point, I think that we are a bit unsafe.

You're quite right that PluginLoader is not at all thread-safe and that it would be nice if it was.

At this stage, though, I think it's unlikely that this will change in a future release. That's because (a) it would introduce a further platform dependency for thread synchronisation and (b) it would change the semantics of the library without changing the API which is itself a hazardous thing to do.

So I'm afraid you will have to synchronise your plugin load code (i.e. the code that calls PluginLoader) instead, and accept the fact that the library doesn't do it for you.

One thing I certainly should do, though, is document this!

Just for completeness -- it should be OK to load plugins in multiple threads (so long as the PluginLoader calls are synchronised and the plugins themselves are well-written!) but you should only use a single plugin instance from within a single thread (don't access the same plugin from multiple threads) and you should always delete a plugin from the same thread you loaded it from. There should be no problem loading the same plugin multiple times in different threads if necessary, PluginLoader does not share instances.

It's also perhaps worth adding that you don't have to use PluginLoader. In fact, it didn't exist in the very earliest version of the SDK: that just said you should load the shared library and look up the descriptor function, as is usual with (for example) LADSPA plugins. That method still works too.

QM beat track and 4/4 signatures

I know this post refers to host development but I would like to give feed back about beat tracking. All QM beat trackers are flexible in a sense that they are not limited to music having a 4/4 signature. However, most dance music today is written in a 4/4 signature. I personally have analysed the raw beat positions of the QM beat tracker with hundreds of songs. It was found out that the resulting beat grid was not always correct which negatively affects the BPM. QM frequently gets confused when the rhythm pattern changes within a track. Luckily, we have "invented" a method to to correct the raw beat positions. It would be great to have a native QM beat tracker for 4/4 signatures. If you are interested I can describe "invented" method and point to the implementation.

On a personal level I would certainly be interested, and I can point the beat tracking researchers behind the QM plugins at this forum too.


Chris

86
I would like to know how to make it,  so that when I zoom-in,  the level of detail is good like in SV. What is the concept behind this kind of implementation?

The main idea is that each pixel width on the horizontal axis should correspond to the peak sample value for the range of audio samples covered by that pixel.  In most cases, peak values are more useful and recognisable to the user than averages, and since the peak of a range of peak values is the same as the peak of the underlying samples covered by that range, that means you can generate a peak cache at an intermediate resolution and refer to it whenever the view is zoomed out at that resolution or further.

Many audio editors restrict the permissible zoom levels to power-of-two samples-per-pixel.  This means you can scan the audio file when it is first loaded and generate a peak cache at (say) 64 samples per cache element (meaning that each value in the cache represents the peak value found in a contiguous 64-sample range of the file).  Then, in order to display a waveform at (say) 256 samples per pixel, it is necessary only to scan the cache and take the peak of each consecutive set of 4 cache values to generate each pixel level.  (If the user zooms in closer than 64 samples per pixel, you just read the relevant section of the audio file directly instead.)

Sonic Visualiser varies this slightly in permitting zoom levels at power-of-sqrt-two samples per pixel (i.e. twice as many zoom resolutions as the most naive implementation) but the basic principle is as described.  The cache code is in svcore/data/model/WaveFileModel.cpp.

Incidentally, ensuring that the preview remains consistent and no peaks are missed when scrolling (as well as when zooming) also takes care.  The main thing is to remember that each pixel represents a range of the underlying audio file and ensure that the range is preserved -- i.e. work from pixel resolution back to file resolution ("what is the file range for this pixel? which samples contribute to it?") rather than the other way around.


Chris

87
Plugin and Host Announcements / Sonic Visualiser v1.9 now available
« on: October 14, 2011, 09:26:57 »
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.9 of Sonic Visualiser is now available.

 http://www.sonicvisualiser.org/

This release adds session templates, simplifies the file open mechanism and related menu entries, and fixes a number of bugs.  For more information, please read the change log at:

 http://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG


Chris

88
The new version 1.9 contains a template feature which I hope will go some way to addressing this -- see the short description at http://www.sonicvisualiser.org/doc/reference/1.9/en/#templates .

Let me know how you find this; it can be refined in further point releases as necessary.


Chris

89
Getting and Using Vamp Plugins / Re: Scientific filters for SV
« on: June 22, 2011, 16:42:17 »
SV can use LADSPA plugins, and there are certainly various filters there -- for example in the basic CMT set which is available from various sources, e.g. from http://audacity.sourceforge.net/download/plugins for Windows.


Chris

90
Getting and Using Vamp Plugins / Re: Problems with Match Plugin
« on: June 22, 2011, 16:40:19 »
Do you have a 64-bit version of Windows, perhaps?  If so, then the Vamp plugin needs to go in C:\Program Files (x86)\Vamp Plugins rather than just Program Files (which is generally for 64-bit programs on Windows 64; the plugins are 32-bit).  See the bottom of http://vamp-plugins.org/download.html.

The .cat file should be included with the MATCH plugin distribution and it should be copied to the same place as the .dll.  It tells Sonic Visualiser where to place the plugin within the Transforms menu.  If you don't install the .cat file, the plugin should still work, it'll just be uncategorised.


Chris

Pages: 1 ... 4 5 [6] 7 8 ... 19