226
Getting and Using Vamp Plugins / Re: vamp-libxtract too many outputs from plugin
« on: November 06, 2008, 11:34:38 »
Yes, I can confirm this. I'll look into it.
Chris
Chris
This forum closed permanently at the end of February 2018.
The forum content is preserved here in static HTML form. It is no longer possible to register, log in, or post.
The forum content is preserved here in static HTML form. It is no longer possible to register, log in, or post.
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.
227
Plugin Development / MOVED: Exporting (some) extracted symbolic features/information as .mid
« on: October 14, 2008, 09:06:17 »
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
http://vamp-plugins.org/forum/index.php?topic=47.0
228
Host Forum: Sonic Visualiser / Re: Exporting (some) extracted symbolic features/information as .mid
« on: October 14, 2008, 09:05:12 »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
229
Getting and Using Vamp Plugins / Re: FFT
« on: October 01, 2008, 09:04:25 »
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
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
230
Getting and Using Vamp Plugins / Re: Inconsistencies in QM-plugin output (when invoked using simple-host or SV app)
« on: September 17, 2008, 10:58:38 »
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
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
231
Host Forum: Sonic Visualiser / Re: Comparing two files of different sizes
« on: September 16, 2008, 13:30:50 »
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
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
232
Getting and Using Vamp Plugins / Re: Compilation issues on Kubuntu (RT kernel) 64-bit
« on: September 16, 2008, 13:27:56 »
Darren,
This is simply an error in the Vamp SDK Makefile; it was shipped with a line that should not have been included. Fortunately it's easy enough to correct.
Where you read this text in the Makefile ...
... the comment is wrong: statically linking libstdc++ is not a good idea, and isn't even possible using the particular build you have.
Just comment out the second of those PLUGIN_LIBS lines with the # comment character, and uncomment the first one instead.
Chris
This is simply an error in the Vamp SDK Makefile; it was shipped with a line that should not have been included. Fortunately it's easy enough to correct.
Where you read this text in the Makefile ...
Code: [Select]
# Libraries required for the plugins.
# (Note that it is desirable to statically link libstdc++ if possible,
# because our plugin exposes only a C API so there are no boundary
# compatibility problems.)
#
#PLUGIN_LIBS = $(SDKDIR)/libvamp-sdk.a
PLUGIN_LIBS = $(SDKDIR)/libvamp-sdk.a $(shell g++ -print-file-name=libstdc++.a)
... the comment is wrong: statically linking libstdc++ is not a good idea, and isn't even possible using the particular build you have.
Just comment out the second of those PLUGIN_LIBS lines with the # comment character, and uncomment the first one instead.
Chris
233
Getting and Using Vamp Plugins / Re: Quantization of onset detection
« on: July 17, 2008, 12:30:30 »
Mitch,
For this plugin at least, the quantization of the results is entirely dependent on the step size used when running the plugin: this is a basic limitation of this plugin, it isn't capable of returning results any more precisely than that. Although the default step size is supposed to be 11.6ms, not 25 -- for example, it is 512 samples at 44100Hz -- so I'm a little puzzled about your results.
The step size can be changed from the Advanced section of the transform parameters in SV -- though note that the internal workings of the plugin are somewhat tuned for a particular step size, so if you change the step size you may need to adjust the sensitivity, and may find the results differ substantially. (And be sure to also adjust the block size so that it remains double the step value.)
Chris
For this plugin at least, the quantization of the results is entirely dependent on the step size used when running the plugin: this is a basic limitation of this plugin, it isn't capable of returning results any more precisely than that. Although the default step size is supposed to be 11.6ms, not 25 -- for example, it is 512 samples at 44100Hz -- so I'm a little puzzled about your results.
The step size can be changed from the Advanced section of the transform parameters in SV -- though note that the internal workings of the plugin are somewhat tuned for a particular step size, so if you change the step size you may need to adjust the sensitivity, and may find the results differ substantially. (And be sure to also adjust the block size so that it remains double the step value.)
Chris
234
Plugin and Host Announcements / Sonic Visualiser v1.3 now available!
« on: July 10, 2008, 14:48:58 »Version 1.3 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.2 release. For more details,
please read the release notes at
http://sourceforge.net/project/shownotes.php?release_id=612594
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 also supports the
Vamp plugin API for plugins that extract descriptive or analytical
data from audio.
Sonic Visualiser is Free Software distributed under the GNU General
Public License. The 1.3 release is available now in source code form
or as binaries for Linux, OS/X, and Windows.
Chris
235
Plugin and Host Announcements / OnsetsDS note onset detection plugin now available
« on: July 09, 2008, 13:33:39 »A Vamp plugin implementation of Dan Stowell's OnsetsDS note onset detector (see http://onsetsds.sourceforge.net/) is now available in source and binary form for OS/X, Linux, and Windows.
Please see http://vamp-plugins.org/download.html for download links, and http://onsetsds.sourceforge.net/ for more information about the library and techniques used.
Chris
236
Plugin and Host Announcements / Vamp plugin SDK v1.3 now available
« on: July 09, 2008, 13:31:10 »Version 1.3 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.
Version 1.3 is a maintenance release, with several bugfixes (almost all of which only affect hosts, not plugins) and no new features.
Changes since 1.2:
- PluginBufferingAdapter has several important fixes to bugs that could cause incorrect timings or output descriptors to be returned
- Conversion between real-time and frames has been improved to avoid rounding error in round-trip calculations
- Plugin lookup no longer relies on non-portable DT_REG
- The SDK now compiles with gcc 4.3
Plugins and hosts remain binary compatible with those built using the
1.0 version of the SDK.
Chris
237
Host Forum: Sonic Visualiser / Re: How can I import files from compact discs?
« on: June 04, 2008, 09:29:37 »As I understand it, a .cda file does not actually contain any audio data -- it's just an index that tells the computer where to read the music from the CD. There is nothing in it for Sonic Visualiser to read (unless SV were to include code for direct access to CD drives, which it does not; it just loads files from the filesystem).
You need to use a CD ripper program to read the audio data from the CD and encode it into a file in a format that SV can load, such as WAV.
Chris
238
Host Forum: Sonic Visualiser / Re: vertical scale
« on: May 07, 2008, 14:24:25 »
Marco,
Which sort of layer are you dealing with? Time-value plots, grids,...?
The intention is that the Auto-Align setting for a layer's vertical scale property should do what you ask -- but only if the layers that you want to have aligned to the same scale all share the same (non-empty) scale unit. If the layers were generated by running a plugin that declares unit(s) for its output(s), then that should be the case already. Otherwise, you should find that if you set the layers to Auto-Align and enter some unit text in each layer's Unit setting -- the same text for each layer that you want to line up -- then it does as you would expect. (Note that you have to hit Return after entering a new unit into the text box for that setting. It's actually a combo box with a menu, which remembers the units that you have already used so you can select them again quickly.)
Hope this makes sense! Let me know if you have problems with it.
Chris
Which sort of layer are you dealing with? Time-value plots, grids,...?
The intention is that the Auto-Align setting for a layer's vertical scale property should do what you ask -- but only if the layers that you want to have aligned to the same scale all share the same (non-empty) scale unit. If the layers were generated by running a plugin that declares unit(s) for its output(s), then that should be the case already. Otherwise, you should find that if you set the layers to Auto-Align and enter some unit text in each layer's Unit setting -- the same text for each layer that you want to line up -- then it does as you would expect. (Note that you have to hit Return after entering a new unit into the text box for that setting. It's actually a combo box with a menu, which remembers the units that you have already used so you can select them again quickly.)
Hope this makes sense! Let me know if you have problems with it.
Chris
239
Host Development / Re: Real-time host
« on: April 21, 2008, 09:41:06 »
Florent,
I've recently been discussing this with another developer via email, so I hope you don't mind if I take the liberty of quoting here much of what I said in that discussion as I think it is applicable to your question. The short answer is "it's possible, but with significant limitations that need to be understood".
The first point is that it's important to distinguish between different uses of "real-time", namely strictly real-time versus a looser sense of "causal(*), and fast enough to produce results as quickly as it gets input".
Strictly real-time means that the plugin is able to guarantee to meet a known response deadline -- meaning for example that it is predictable enough to be used when serving short audio buffers directly to a hardware soundcard. This is a much stronger meaning of the term than "causal and fast enough"; in particular it refers to code that is not only suitably bounded in algorithmic complexity but also avoids taking any mutex locks, making any system calls, or allocating any memory on the heap.
The major limitation with using Vamp plugins in a real-time context (in the strong sense) is that the Vamp SDK uses C++ standard library classes, such as string and vector, to pass data back from the plugin's process function. These classes routinely use heap allocation for dynamic storage of data, and so are not generally
suitable for use in a real-time context. It's possible to write plugins using the SDK that satisfy the "causal and fast enough" test, but not the "strictly real-time" test.
As an example of the distinction, consider e.g. a "real-time" spectral visualiser (for which "causal and fast enough" is almost certainly good enough, the graphical part of the visualiser program is unlikely to be able to support any stronger guarantee anyway, and the existing Vamp SDK should be fine) vs. an analysis component in a real-time audio processing effects unit (for which "strictly real-time" is required).
This limitation isn't built in to the Vamp API itself (that is, the C API defined in vamp/vamp.h -- which is the only interface that is relevant to binary compatibility), it's simply a result of decisions taken for plugin authors' convenience in the current SDK. It would not be hard to define an alternative C++ plugin base class that used
preallocation, avoided standard library classes, carried out no heap allocation in process(), and was therefore real-time safe, but it would obviously require that the plugin was written appropriately (with features of a known size, etc). If you'd very much like to see such a thing, let me know, because it's a real possibility.
Of course, one could also write plugins directly using the C API in vamp/vamp.h instead of using the SDK classes at all. There would be no problem making such plugins real-time safe.
The same logic applies to the host side of things -- although it wouldn't be hard to write a host using vamp/vamp.h directly, and a host written specifically for a real-time context would probably find that a reasonable thing to do.
Finally, there is no way for a plugin to indicate to the host whether it is causal and/or real-time safe, which means that a real-time host would need to know in advance which plugins were appropriate. Again, this is an addition that is quite likely to appear at some point.
Chris
(*) - "Causal" refers to an algorithm that calculates results for a particular frame of input audio as it receives that frame, without significant buffering or lookahead. In the Vamp plugin context this generally refers to plugins that return individual result features directly from individual process() calls, rather than returning them all in a big batch from getRemainingFeatures().
I've recently been discussing this with another developer via email, so I hope you don't mind if I take the liberty of quoting here much of what I said in that discussion as I think it is applicable to your question. The short answer is "it's possible, but with significant limitations that need to be understood".
The first point is that it's important to distinguish between different uses of "real-time", namely strictly real-time versus a looser sense of "causal(*), and fast enough to produce results as quickly as it gets input".
Strictly real-time means that the plugin is able to guarantee to meet a known response deadline -- meaning for example that it is predictable enough to be used when serving short audio buffers directly to a hardware soundcard. This is a much stronger meaning of the term than "causal and fast enough"; in particular it refers to code that is not only suitably bounded in algorithmic complexity but also avoids taking any mutex locks, making any system calls, or allocating any memory on the heap.
The major limitation with using Vamp plugins in a real-time context (in the strong sense) is that the Vamp SDK uses C++ standard library classes, such as string and vector, to pass data back from the plugin's process function. These classes routinely use heap allocation for dynamic storage of data, and so are not generally
suitable for use in a real-time context. It's possible to write plugins using the SDK that satisfy the "causal and fast enough" test, but not the "strictly real-time" test.
As an example of the distinction, consider e.g. a "real-time" spectral visualiser (for which "causal and fast enough" is almost certainly good enough, the graphical part of the visualiser program is unlikely to be able to support any stronger guarantee anyway, and the existing Vamp SDK should be fine) vs. an analysis component in a real-time audio processing effects unit (for which "strictly real-time" is required).
This limitation isn't built in to the Vamp API itself (that is, the C API defined in vamp/vamp.h -- which is the only interface that is relevant to binary compatibility), it's simply a result of decisions taken for plugin authors' convenience in the current SDK. It would not be hard to define an alternative C++ plugin base class that used
preallocation, avoided standard library classes, carried out no heap allocation in process(), and was therefore real-time safe, but it would obviously require that the plugin was written appropriately (with features of a known size, etc). If you'd very much like to see such a thing, let me know, because it's a real possibility.
Of course, one could also write plugins directly using the C API in vamp/vamp.h instead of using the SDK classes at all. There would be no problem making such plugins real-time safe.
The same logic applies to the host side of things -- although it wouldn't be hard to write a host using vamp/vamp.h directly, and a host written specifically for a real-time context would probably find that a reasonable thing to do.
Finally, there is no way for a plugin to indicate to the host whether it is causal and/or real-time safe, which means that a real-time host would need to know in advance which plugins were appropriate. Again, this is an addition that is quite likely to appear at some point.
Chris
(*) - "Causal" refers to an algorithm that calculates results for a particular frame of input audio as it receives that frame, without significant buffering or lookahead. In the Vamp plugin context this generally refers to plugins that return individual result features directly from individual process() calls, rather than returning them all in a big batch from getRemainingFeatures().
240
Host Forum: Sonic Visualiser / Re: Can't open Wav file !!
« on: March 31, 2008, 14:24:28 »
Hi,
Sonic Visualiser uses libsndfile (http://www.mega-nerd.com/libsndfile/) for importing uncompressed audio formats, so it should support any format listed at that page. Because this is a third-party library, it is unlikely that we can do anything about it if your file is not supported -- you would need to convert it to something that is.
I'm afraid I don't know anything about the format(s) used by Dalet, so I can't comment any further without more information about what the file format actually is, whether it is one that would be expected to be supported by libsndfile, and what error you are seeing when the file fails to load.
Chris
Sonic Visualiser uses libsndfile (http://www.mega-nerd.com/libsndfile/) for importing uncompressed audio formats, so it should support any format listed at that page. Because this is a third-party library, it is unlikely that we can do anything about it if your file is not supported -- you would need to convert it to something that is.
I'm afraid I don't know anything about the format(s) used by Dalet, so I can't comment any further without more information about what the file format actually is, whether it is one that would be expected to be supported by libsndfile, and what error you are seeing when the file fails to load.
Chris