Development Topics > Plugin Development

Sampling rates, input domain and sonification

<< < (2/3) > >>

cannam:

--- Quote from: justin on July 12, 2012, 16:42:20 ---Nice. I've had a look - any specific reason for using Cross's implementation?

--- End quote ---

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

justin:
Can't argue with that :)

Justin

justin:

--- Quote from: cannam on July 12, 2012, 09:21:36 ---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.

--- End quote ---

Sorry, last question for the day...

I've been experimenting with setting the step and block size as a function of the inputSampleRate, and on the way I've encountered some weird behaviour from SV. Imagine that in getPreferredBlockSize() I return a value X (X can be a function of inputSample rate or just a fixed number). To ensure the user hasn't changed the block size, in initialise() I run a simple check: if (blockSize != X) return false; 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. Curiously, if in getPreferredBlockSize() I return a value X, but in initialise() I check for a *different* value Y, then I get the desired error, and if through the interface I change X to Y, the plugin runs as expected. The problem seems to be when the preferred blockSize and the value I'm checking against in initialise() are the same value. To clarify, here's the code of a simple test I ran:


--- Code: ---size_t
MelodyExtraction::getPreferredBlockSize() const
{
return 2048;
}

bool
MelodyExtraction::initialise(size_t channels, size_t stepSize, size_t blockSize)
{
    if (channels < getMinChannelCount() ||
channels > getMaxChannelCount()) return false;

    if (blockSize != 2048) return false;

    // Real initialisation work goes here!

    return true;
}

--- End code ---

In this example, if through the user interface I change the blockSize from 2048 to something else, the plugin still runs ???.
I'm most probably doing something wrong, but I can't figure out what.

Thanks!

cannam:

--- Quote from: justin on July 12, 2012, 19:32:39 ---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.

--- End quote ---

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

justin:
that explains it. I was running different tests for about an hour to make sure this was actually happening before posting on the forum. At least I know I'm not crazy :)

j

Navigation

[0] Message Index

[#] Next page

[*] Previous page