Hosting the vamp-example-plugins

[Hitmuri]

Hi,

i don't know if it is the right section but i have a problem using the vamp-example power spectrum plugin in an application that i am writing.
i load it and use it that way (it's temporary code )  :

Code:

        loader = PluginLoader::getInstance();
        key = loader->composePluginKey(pluginName, pluginID);
        plugin = loader->loadPlugin(key, sampleRate, PluginLoader::ADAPT_ALL_SAFE);
        outputs = plugin->getOutputDescriptors();
        RealTime rt;
        RealTime adjustment = RealTime::zeroTime;
        if(!plugin->initialise(2, 64, 128))
        {
                cout<<"Error initializing analysis"<<endl;
        }

Code:

        RealTime rt;
        Plugin::FeatureSet features=plugin->process((float**)(aae->getBuffers()),rt);
        for (unsigned int j = 0; j < features[0][0].values.size(); ++j)
            //here i get the values

this way i get the values of the spectrum, but the first two values keep increasing over time, and don't seem to be related to the spectrum.

Am i doing something wrong ?

thanks

florent

[cannam]

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

[Hitmuri]

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.

Yes actually it's the buffer (jack_default_audio_sample_t[2][128]) from the jack process.

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

yes exactly

If so, I can't suggest any reason for that -- perhaps some example output might make things clearer?

Ok if i don't play any sound (i.e the buffer is empty), the values are 0 0 and they don't change.
When some changes occur in the buffer (a sound is played), the values are really strange at first (45.0 / 345.0 / 11.0)
then they go back to a very little value when the sound stops and start increasing if i don't play any sound :

1 2.70579e-13
0 1.10692e-12
0 7.10114e-12
1 1.7577e-12
0 2.41869e-11
1 6.04672e-11
...


Any ideas ?

Thanks for your answer

Florent

[Hitmuri]

Hi,

do you have any idea on that particular problem ?
I really don't understand why it doesn't work .

Florent

[cannam]

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

[Hitmuri]

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

no problem
thanks for answering

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

ok so i should ignore this first value ?

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

Ok thanks, i'll try that.

Florent