|
 |
> Only problem is that first I'd have to find out what the necessary API
> calls are. This is highly likely to be quite intractibly difficult.
It's not *that* hard to use the Windows wave API to repeatedly get a buffer
full of samples, there are plenty of tutorials around and of course the
reference information from MS:
http://msdn.microsoft.com/en-us/library/aa909811.aspx
I managed two functions that easily fit on a single page to choose and open
a device for recording. However I switched to using ASIO drivers as the
performance was much better. No idea how difficult it is to use the ASIO
driver directly as someone had helpfully written a very simple-to-use .net
wrapper for it :-)
> That way I only have to worry about WAV. (This is more complicated than it
> sounds!)
I thought WAV was quite easy to decode, isn't the data just stored
byte-by-byte after some header?
> The thing that seems to throw WinAmp is that most drumbeats are fairly
> complicated, with double beats, fills and breaks, and so on.
Yeh, I can see how you would easily get an output was a multiple of the
actual BPM. But even with that information you could figure out the exact
BPM yourself (or fix your software to automatically multiply the BPM to be
in a certain range).
> Really, the human brain is far, far better at beat detection than any
> computer. Hell, I can even tap out the beat during a break where there is
> no audible beat at all! The computer has no hope of coping with that.
Depends how you wrote the program, for example if it couldn't find any beat
within a reasonable certainty it would continue on with the previous
estimate.
> It then becomes a question of statistics. Just how accurately can you
> decide where the beats are, assuming all the tap signals contain a certain
> amount of jitter?
That's easy, the hard bit is figuring out if the person missed a tap, or
pressed one too many times. This would give quite a large error (as opposed
to simply pressing all the taps half a second out).
Post a reply to this message
|
|
