Messages

166

Host Development / Re: Hosting the vamp-example-plugins

« on: July 06, 2009, 12:32:39 »

Sorry... I had intended to reply, I must have got distracted or something...

Just to recap, the first two values should represent the square of the magnitude of the DC output of the short-time Fourier transform, and that of the first non-DC bin (perhaps with some factor depending on the windowing). The DC (0Hz) bin just reflects whether the balance of the signal is positive or negative during the analysis period, and its square is not necessarily going to be useful or related to the rest of the spectrum.  The next bin is the lowest separable frequency component (e.g. 43Hz approx in a 1024-point FFT).

Running this plugin myself, the results do look OK.  There is not supposed to be any feedback from one processing block to the next such as might cause a value to keep increasing in the absence of any input.  My first response to the sort of small values you're seeing would be to suggest soundcard converter noise, but a bug is possible (I just haven't seen it yet).

You're using ADAPT_ALL_SAFE when loading the plugin, which means the host SDK is going to do the FFT for you.  Does it make any difference whether you build the host SDK with FFTW support or the built-in FFT?  (It shouldn't, but it's worth a try.)  The option for this is somewhat hidden; I don't especially want distributors using it because it changes the effective license of the SDK, but if you read near the top of src/vamp-hostsdk/PluginInputDomainAdapter.cpp you'll see that adding -DHAVE_FFTW3 to the Makefile should be enough to build it with FFTW instead of the built-in FFT.  (It will run faster then, too.)


Chris

167

Plugin Development / Re: coding...

« on: June 29, 2009, 22:01:26 »

It looks like you wanted something more like

const VampPluginDescriptor *vampGetPluginDescriptor(unsigned int version, unsigned int index)
{
  if (version < 1) return 0;
  if (index == 0) return vocalRangeAnalyzerPlugin.getDescriptor();
  else return 0;
}

Note that it only returns a plugin descriptor when called with index 0.

The principle of this function, generally speaking, is that it allows the plugin library to contain many different plugins, identified with different index values.  The host calls this function, repeatedly with index values incrementing from 0, and with each call it gets back a new plugin descriptor.  When it gets back a null descriptor (or 0 -- same thing), then it stops.

So, with a function as you quoted it, the host will keep calling this function forever, getting a new (identical) descriptor object each time -- because the function returns a new object regardless of the value of the index parameter.

Hope this helps!


Chris

168

Plugin Development / Re: coding...

« on: June 25, 2009, 15:33:29 »

Does SV crash as soon as you start it up (when your DLL is installed), or does it crash when you try to run the plugin?

Either way, I'm afraid the most likely thing is a bug in the plugin code.

If it crashes when you start SV, then the crash might be in the plugin's constructor function or in the plugin lookup code (vampGetPluginDescriptor -- are you remembering to return NULL when called with an index greater than the number of plugins in the library?)

If it crashes when you run the plugin, then the most likely thing would be a bug in initialize() or process().

Perhaps you might try running it in a debugger?

Again, I'd also suggest using vamp-simple-host as an alternative test host.  You could even use vamp-simple-host in a debugger...


Chris

169

Host Development / Re: problems with windows hostsdk msvc binaries

« on: June 25, 2009, 15:30:40 »

Hm, that's unfortunate.  I have to admit that these particular libraries have not been well tested.

I don't know the certain answer to your question, but I think it's unlikely that they would have been a Unicode build since support for Unicode builds was only recently added to the SDK in Subversion.  I think.  (Are you building a released version in Unicode mode?)


Chris

170

Host Forum: Sonic Visualiser / Re: geting Sonic Visualiseer to use a specified codec

« on: June 15, 2009, 15:47:20 »

David,

I'm afraid there's no way to add another decoder to SV without writing code and rebuilding.  It doesn't use any of the typical streamer systems with plugins.


Chris

171

Host Forum: Sonic Visualiser / Re: Align File Timelines issue

« on: June 15, 2009, 15:45:27 »

Miranda,

The align timelines feature is completely "unsupervised" -- all it does is feed the audio data to an alignment plugin based on the MATCH alignment method, which aligns the files automatically.  It isn't possible to help it along by inserting bar lines yourself; it will always make its own judgment about how the audio data align.  I think (although I may have misunderstood) that this may be the cause of your confusion/complaint.

(As a matter of interest, SV doesn't actually stretch or squash the audio when alignment is in effect, either -- it always plays one file at a time when the files are aligned, and just keeps track of whereabouts in the other file would correspond to the current play position so that it can switch to the "correct" point when you change the current pane.)

I agree, it would be nice to have a method that does what you describe -- taking a set of bar line positions for two separate recordings and adjusting the audio to suit.  But I'm afraid that SV can't currently do that.


Chris

172

Host Development / Re: Hosting the vamp-example-plugins

« on: June 15, 2009, 15:29:05 »

Well, the code looks OK to me at first glance -- although I obviously don't know what aae->getBuffers() will return -- hopefully, the current processing block.

When you say "the first two values keep increasing over time", do you mean the first two values in each returned column?  i.e. features[0][0].values[0] and features[0][0].values[1] ?  If so, I can't suggest any reason for that -- perhaps some example output might make things clearer?


Chris

173

Host Forum: Sonic Visualiser / Re: Illegal Instruction in Jaunty

« on: May 21, 2009, 09:32:39 »

I see.  I'm afraid there's no way you can use that particular build of SV -- you would either need to get it from a different distro repository (but I don't know of one for Ubuntu) or build it from source code (which is hard to do).

Or you could try downloading one of the older versions from the SourceForge downloads page -- I wouldn't normally suggest that since there are sound reasons why they've been superseded (bugs, etc) but you might find one that works and that could be used as a last resort.

There is no good reason why this binary was compiled with SSE2 support, as it doesn't benefit from it at all -- it's purely an oversight on my part.  I'd like to do another release soon, and I'll endeavour to avoid this problem next time.


Chris

174

Getting and Using Vamp Plugins / Re: Strange results from qm-vamp-plugins:qm-tempotracker:tempo

« on: May 14, 2009, 15:20:59 »

Hm, puzzling one.

Part of this is easy to explain -- the tempo tracker is indeed supposed to return a result only when the tempo changes, as documented, but the current release has a bug that makes it return a value on every process call whether it has changed or not.  This has been fixed for a while in the code repository and will be fixed in the next release (not too far off I expect).

The discrepancy in tempo and beat timings is harder to explain, and I'm not sure I have the requisite knowhow to completely understand what caused this.  I believe that there's no intrinsic built-in guarantee that the tempo and beat timings will match up with one another, because the tempo is an underlying estimate that covers a relatively lengthy period while beats may be fitted to track local changes somewhat.  Also, both tempo and beat locations have a limited resolution essentially based on the internal frame size -- as I understand it, 115 and 117 are actually rounded versions of two immediately neighbouring values at the internal resolution (so this may be a simple off-by-one error internally, or it may be something subtler that is not technically a code error at all).

It may be helpful if you could link to audio data to go with your results (I realise this is not always possible).

If I get any more information on this, I'll add it!


Chris

175

Host Forum: Sonic Visualiser / Re: Illegal Instruction in Jaunty

« on: May 14, 2009, 14:50:27 »

Hmm.  Is this an older CPU that might not have SSE2 support, I wonder?  I can imagine that the binary might have ended up with a dependency on SSE2.


Chris

176

Host Forum: Sonic Visualiser / Re: SV 1.5 compilation does not recognize pulseaudio and portaudio

« on: May 14, 2009, 14:49:36 »

Mark,

When you run qmake and then make, you should see, among all of the other output, a series of lines starting "Project MESSAGE:" and printing out some details of packages that have been found (or not found).  These are printed every time the top-level Makefile generates a Makefile for one of Sonic Visualiser's sub-projects.  The exact set of packages mentioned will depend on the sub-project (e.g. the audioio directory sub-project will call for a lot of audio I/O packages).

Anyway, at some point, and probably at several points, you should see a line saying either

Project MESSAGE: Including PulseAudio support for audio playback

or

Project MESSAGE: WARNING: PulseAudio audio playback support will not be included

If you are seeing the latter, that suggests that the PulseAudio pkg-config definition could not be found.  What do you get if you run

Code: [Select]

$ pkg-config --modversion libpulse

from the command line?


Chris


Chris

177

Host Forum: Sonic Visualiser / Re: Spectrograms

« on: May 01, 2009, 12:40:45 »

Correction: a cent is a hundredth of a semitone.

As David says, a spectrogram is a time/frequency representation with (in this case) time on the x axis, frequency on the y axis, and the strength of a particular frequency component expressed as colour or intensity.

It's computed as a series of short-time Fourier transforms, each one covering a single column (one horizontal unit on the time scale), which calculate the frequencies at which sinusoidal component waves would have to be present in order to sum to the original signal.  The vertical (frequency) resolution depends on the frame size for the Fourier transform (a longer frame gives better frequency resolution), and the horizontal resolution depends on the frame size and amount by which analysis frames overlap (a longer frame gives worse time resolution).

So, you can read directly from the spectrogram (with some very substantial caveats to do with resolution limitations) the frequency of a component of the signal.  If your music consisted of simple sine tones, there would be (roughly, with the same caveats) a single horizontal line for each note whose height told you directly what the frequency of the note was, and therefore what musical pitch it was at (there is a relationship between musical-note and frequency such that ascending by one octave results in a doubling of the frequency).

Musical tones have more than one "partial" frequency -- they consist of more than one frequency component -- usually at closely related frequency intervals such as integer multiples of the lowest, "fundamental" frequency of the note.  These will show up in your spectrogram as a stack of horizontal lines, waving about in correspondence with any pitch variation or vibrato, with the lowest line usually giving the fundamental frequency and usually corresponding to the note's perceived pitch, and the structure of higher partials having some relationship to the timbral quality of the instrument.  Because these structures can be quite complex, it's not always straightforward (indeed not always possible) to read off the actual performed pitch, especially in polyphonic music.

Percussive sounds are often also visible in the spectrogram, usually as fuzzy columns -- they generally consist of noise that is dispersed across broad frequency ranges without a regular structure.


Chris

178

Host Forum: Sonic Visualiser / Re: Unable to install Sonic Visualiser in Ubuntu 9.04

« on: April 30, 2009, 15:57:53 »

I've updated the Sonic Visualiser download page with links to newly built .deb packages (1.5cc-2) that I believe should install on both Ubuntu 8.10 and 9.04.

Note that the software build is unchanged, so if you have a 1.5cc-1 deb installed successfully already, there is no reason to upgrade it.


Chris

179

Host Forum: Sonic Visualiser / Re: Exporting image file from spectrum

« on: April 10, 2009, 17:25:46 »

Hmm, I see what you mean.  I'm pretty sure that exporting images from the spectrum layer is something that has simply never been implemented (as the spectrum layer is rather different in structure from all the others).  I'm sorry about that!

It may be worth your time to file a bug report or feature request (depending on how you perceive this omission!) on the SourceForge trackers for the project?


Chris

180

Getting and Using Vamp Plugins / Re: MFCC batch process

« on: April 09, 2009, 21:46:12 »

KFCC,

This sounds like exactly the kind of task that Sonic Annotator (http://omras2.org/SonicAnnotator) was intended for.  It runs one or more plugins against any number of audio files and writes out the results to text files or RDF.


Chris