I found this:

http://www.all8.com/tools/bpm.htm

That's quite nice, but a cursory inspection of the JavaScript code 
reveals how it works: In effect, the first keypress starts a timer. The 
displayed BPM is simply the time elapsed between the first and most 
recent keypress divided by the total number of presses.

In other words, if the first keypress is slightly out of time, it throws 
the whole measurement off. Given that it usually takes a few moments to 
get into the rhythm, the *first* keypress is the one *least likely* to 
be precisely in time.

Now I'm wondering if I can come up with something a little more 
accurate. (Although, obviously, accuracy is ultimately determined by how 
good your coordination and sense of rhythm are!)



I had a play with this yesterday. I took my rock and roll collection and 
measured the speed of 34 tracks.

Of course, BPM is slightly subjective in that it varies according to 
what you deem a "beat" to be. For example, taking a waltz such as Hey 
Paula, if you count the 1/2/3/4 beats you get approximately 75 BPM. If 
you count the 1/2/3 beats inbetween as well, you get about 240 BPM. 
(Roughly 3x faster - shockingly enough.)

Even for songs in 4/4 time (i.e., the vast majority of the tracks), you 
usually have a choice of several BPM ratings, all multiples of 2 of each 
other. I took my timings based on the speed of the "slow" steps you'd 
most "naturall" dance to the music.

Using this measurement, I got speeds of around about 70 - 80 BPM for 
most tracks. A few were as slow as 65 BPM, a couple were in the 90 to 95 
BPM range.

And just *one* track registered at a frankly silly 135 BPM. (!!)

Arguably all those values ought to be multiplied by 2, since the "fast" 
dance steps are twice the speed of the "slow" ones, and more closely 
match the most obvious drum beats. That gives us most tracks being 
somewhere between 120 BPM and 180 BPM, with one outlier at 270 BPM.

The outlier was Lonnie Donegan singing Cumberland Gap, by the way. I 
literally can't move my feet that fast. I bet Debbie can...

Post a reply to this message

> Now I'm wondering if I can come up with something a little more accurate. 
> (Although, obviously, accuracy is ultimately determined by how good your 
> coordination and sense of rhythm are!)

Oh, I thought this was going to be about how you wrote a Haskell program to 
read from the line-in on your sound card in real time and display the BPM to 
insance accuracy... ;-)

Post a reply to this message

scott wrote:
>> Now I'm wondering if I can come up with something a little more 
>> accurate. (Although, obviously, accuracy is ultimately determined by 
>> how good your coordination and sense of rhythm are!)
> 
> Oh, I thought this was going to be about how you wrote a Haskell program 
> to read from the line-in on your sound card in real time and display the 
> BPM to insance accuracy... ;-)

Now come on, WHY would I do that?



...the sound is after all coming *from* my PC. ;-) The logical thing to 
do with be to decode the Vorbis files back into WAV files and analyse 
the resulting spectrum. Although this is far, far less trivial than 
you'd imagine. (E.g., WinAmp can't reliably decide what the beat rate is 
either, mainly because it can't "hear" the beats reliably.)

I was going to sit and write some elaborate Haskell thing using a GTK 
front-end. But seeing how easy it is to do this with JavaScript and 
HTML, it's quite obvious that this is the best way to proceed.

Post a reply to this message

> ...the sound is after all coming *from* my PC. ;-)

Oh I mistakenly thought I read somewhere that you had your collection on 
real CDs.  Anyway, the difference is just one parameter in an API call.

> The logical thing to do with be to decode the Vorbis files back into WAV 
> files and analyse the resulting spectrum.

Would be more flexible to just read the mixed output from the soundcard, 
that way your program would calculate the BPM of whatever music your 
computer happened to be playing.  You wouldn't have to worry about decoding 
various formats either then.

> Although this is far, far less trivial than you'd imagine. (E.g., WinAmp 
> can't reliably decide what the beat rate is either, mainly because it 
> can't "hear" the beats reliably.)

Yeh I guess you'd need a good algorithm for detecting beats - presumably 
some kind of autocorrelation function on certain parts of the spectrum, easy 
to do both in one shot with FFTs), seems right up your street :-)

Post a reply to this message

scott wrote:
>> ...the sound is after all coming *from* my PC. ;-)
> 
> Oh I mistakenly thought I read somewhere that you had your collection on 
> real CDs.

I did. Right before I transcoded them...

>> The logical thing to do with be to decode the Vorbis files back into 
>> WAV files and analyse the resulting spectrum.
> 
> Would be more flexible to just read the mixed output from the soundcard, 
> that way your program would calculate the BPM of whatever music your 
> computer happened to be playing.

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.

> You wouldn't have to worry about decoding various formats either then.

It's easy enough to decode Vorbis (or just use the original rip files). 
That way I only have to worry about WAV. (This is more complicated than 
it sounds!)

>> Although this is far, far less trivial than you'd imagine. (E.g., 
>> WinAmp can't reliably decide what the beat rate is either, mainly 
>> because it can't "hear" the beats reliably.)
> 
> Yeh I guess you'd need a good algorithm for detecting beats - presumably 
> some kind of autocorrelation function on certain parts of the spectrum, 
> easy to do both in one shot with FFTs), seems right up your street :-)

The thing that seems to throw WinAmp is that most drumbeats are fairly 
complicated, with double beats, fills and breaks, and so on.

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.

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?

Post a reply to this message

> 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

scott wrote:
>> 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

O RLY?

Is this the same Windows API that takes a dozen API calls just to open a 
plain ordinary window on screen and put a button in 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?

Yeah. The hard part is figuring out where the header ends.

(It's a RIFF file, which is an extension of the old Amiga IFF format. Or 
rather, it's IFF but with all the 4-byte quantities written the wrong 
way around.)

> Yeh, I can see how you would easily get an output was a multiple of the 
> actual BPM.

Actually, BPM is an inherantly ambiguous measurement anyway, since it 
varies according to what you consider to be a "beat".

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

That would mean that unusually fast or slow tracks would get measured 
wrong. But hey... ;-)

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

I'm thinking you could probably do this by looking at the taps and 
rejecting any which vastly deviate from the others. But we'll see...

Initial testing indicates that I can tap with a standard deviation of 
around about 20 ms, which isn't too bad. Interestingly, the SD is much 
lower for fast tracks than slow ones. In all cases, I'm getting about +- 
5% jitter.

Post a reply to this message

scott wrote:
>> 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,

Hey, at least he didn't say it's obviously impossible. :-)

> I thought WAV was quite easy to decode, isn't the data just stored 
> byte-by-byte after some header?

Yes. But the headers tell you important stuff like sample size and samples 
per second and such.

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message

Invisible wrote:

> Now I'm wondering if I can come up with something a little more 
> accurate. (Although, obviously, accuracy is ultimately determined by how 
> good your coordination and sense of rhythm are!)

See attached. Press any key rhythmically to send "taps". The reset 
button... uh... resets the stats.

It works by recording the amount of time between consecutive taps. As it 
happens, taking the arithmetic mean of these numbers produces an 
identical result to just taking the duration between first and last tap 
and dividing by the number of taps. However, by storing the actual 
times, I can also take the standard deviation.

(There's probably some way to compute the SD incrimentally. But, as it 
happens, even after several hundred taps, there's no noticable problem 
recomputing all the stats from scratch. Firefox uses about 0.5% CPU 
while doing this. Which is impressive for a trivial scripting language. 
I guess computers are just really, really fast these days!)

In my experiments, the error is always about +/- 4% or so. For fast 
tracks there's less timing jitter, but greater timing precision is 
required to get an accurate BPM reading, so the error is still about 4%. 
(The "error" I'm quoting is just the size of one standard deviation. 
ASSUMING A NORMAL DISTRIBUTION, this equates to 68% certainty.)

My next idea is to try generating a series of perfectly-spaced beats and 
optimise for the best possible fit to all the taps...

Post a reply to this message

Attachments:
Download 'us-ascii' (4 KB)

> Hey, at least he didn't say it's obviously impossible. :-)

No - just ludicrously difficult. ;-)

>> I thought WAV was quite easy to decode, isn't the data just stored 
>> byte-by-byte after some header?
> 
> Yes. But the headers tell you important stuff like sample size and 
> samples per second and such.

I might be mistaken, but I think it also specifies byte-order and 
whether the samples are signed or unsigned - pretty damned important 
info, that! ;-)

Still, I would also guess that, say, CDex is going to write identical 
WAV files for every track ripped. So I can probably just go measure how 
many bytes the header is, and skip that...

Post a reply to this message

>> Hey, at least he didn't say it's obviously impossible. :-)
>
> No - just ludicrously difficult. ;-)

Funny how it took me about 30 mins of research and coding to come up with a 
working program, when previously I didn't know a single thing about it.  It 
didn't require any skills beyond being able to set up a struct and calling 
windows API functions.  In my book ludicrously difficult is when I think and 
work on something for *weeks* or *months* and cannot get anywhere close to a 
working program.

> Still, I would also guess that, say, CDex is going to write identical WAV 
> files for every track ripped. So I can probably just go measure how many 
> bytes the header is, and skip that...

IIRC that's exactly what I did at some point previously.  I guessed/knew the 
samples were in 16bit stereo format, so just took 4 bytes at a time from the 
file and experimented with the order until the result wasn't white noise!

Post a reply to this message

> See attached. Press any key rhythmically to send "taps". The reset 
> button... uh... resets the stats.

If I press buttons too fast I get a negative maximum BPM :-)

Post a reply to this message

>>> Hey, at least he didn't say it's obviously impossible. :-)
>>
>> No - just ludicrously difficult. ;-)
> 
> Funny how it took me about 30 mins of research and coding to come up 
> with a working program, when previously I didn't know a single thing 
> about it.  It didn't require any skills beyond being able to set up a 
> struct and calling windows API functions.

So I'm guessing you know an awful lot more about C than I do.

>> Still, I would also guess that, say, CDex is going to write identical 
>> WAV files for every track ripped. So I can probably just go measure 
>> how many bytes the header is, and skip that...
> 
> IIRC that's exactly what I did at some point previously.  I guessed/knew 
> the samples were in 16bit stereo format, so just took 4 bytes at a time 
> from the file and experimented with the order until the result wasn't 
> white noise!

I suppose you could just open the file in a hex editor and look for the 
chunk names.

Oh, wait - you'd need a hex editor to do that...

Post a reply to this message

scott wrote:
>> See attached. Press any key rhythmically to send "taps". The reset 
>> button... uh... resets the stats.
> 
> If I press buttons too fast I get a negative maximum BPM :-)

Really? That's impressive. You're a special guy! :-D

No, the minimum and maximum values are derived by taking the mean and 
adding/subtracting the SD. If the SD is sufficiently large, it should be 
possible to make the minimum value negative. (I.e., if the error ratio 
is greater than 100%.) Not sure how you'd make the maximum go negative, 
but it's probably possible somehow...

Post a reply to this message

>> Funny how it took me about 30 mins of research and coding to come up with 
>> a working program, when previously I didn't know a single thing about it. 
>> It didn't require any skills beyond being able to set up a struct and 
>> calling windows API functions.
>
> So I'm guessing you know an awful lot more about C than I do.

What's C got to do with it?  You can call DLL functions from lots of 
different languages.  So long as your language allows you to set up a block 
of data with the common data types it shouldn't be at all tricky.

Post a reply to this message

scott wrote:
>>> Funny how it took me about 30 mins of research and coding to come up 
>>> with a working program, when previously I didn't know a single thing 
>>> about it. It didn't require any skills beyond being able to set up a 
>>> struct and calling windows API functions.
>>
>> So I'm guessing you know an awful lot more about C than I do.
> 
> What's C got to do with it?  You can call DLL functions from lots of 
> different languages. 

Sure. So long as you have the necessary magic numbers for the specific 
functions you want to access, and you know how to do the pointer 
manipulation to make it happen. It's not exactly trivial though.

(Unless, of course, you're working with a language which actually has 
built-in support for calling DLLs. Then presumably it *is* trivial.)

> So long as your language allows you to set up a 
> block of data with the common data types it shouldn't be at all tricky.

Heh, right.

I still think recording a few keypresses and doing some statistics on 
them is way, way simpler.

Post a reply to this message

> No, the minimum and maximum values are derived by taking the mean and 
> adding/subtracting the SD. If the SD is sufficiently large, it should be 
> possible to make the minimum value negative. (I.e., if the error ratio is 
> greater than 100%.) Not sure how you'd make the maximum go negative, but 
> it's probably possible somehow...

How are you calculating the maximum BPM?  I guess you are calculating some 
minimum beat time using the mean and SD and then inverting it?  Maybe the 
minimum beat time is negative if the SD is too big compared to the mean?

Post a reply to this message

scott wrote:
>> No, the minimum and maximum values are derived by taking the mean and 
>> adding/subtracting the SD. If the SD is sufficiently large, it should 
>> be possible to make the minimum value negative. (I.e., if the error 
>> ratio is greater than 100%.) Not sure how you'd make the maximum go 
>> negative, but it's probably possible somehow...
> 
> How are you calculating the maximum BPM?  I guess you are calculating 
> some minimum beat time using the mean and SD and then inverting it?  
> Maybe the minimum beat time is negative if the SD is too big compared to 
> the mean?

Minimum = mean - SD
Maximum = mean + SD

(But remember that it takes the mean and SD over the beat period, and 
then takes the reciprocol of that to compute the BPM value.)

So, yes, as I asserted, if SD > mean than one of the figures comes out 
negative.

Post a reply to this message

> I still think recording a few keypresses and doing some statistics on 
> them is way, way simpler.

Since when do you take the simpler solution? :-)

Post a reply to this message

scott wrote:
>> I still think recording a few keypresses and doing some statistics on 
>> them is way, way simpler.
> 
> Since when do you take the simpler solution? :-)

What you trying to say? :-P

Post a reply to this message

>>> I still think recording a few keypresses and doing some statistics on 
>>> them is way, way simpler.
>> 
>> Since when do you take the simpler solution? :-)
> 
> What you trying to say? :-P

That you often seem up for a challenge :-D

Post a reply to this message

>> What you trying to say? :-P
> 
> That you often seem up for a challenge :-D

I enjoy challenges that I have some hope of beating. Trying to do 
something impossible isn't a challenge, it's a guaranteed defeat. Losing 
isn't fun.

Post a reply to this message

On 6/7/2010 9:50 AM, Darren New wrote:

>
> Hey, at least he didn't say it's obviously impossible. :-)
>

LOL

-- 
~Mike

Post a reply to this message

On 6/8/2010 1:51 AM, scott wrote:

> Funny how it took me about 30 mins of research and coding to come up
> with a working program, when previously I didn't know a single thing
> about it. It didn't require any skills beyond being able to set up a
> struct and calling windows API functions. In my book ludicrously
> difficult is when I think and work on something for *weeks* or *months*
> and cannot get anywhere close to a working program.

Nah, somewhat difficult is dealing with OLE objects on the clipboard, 
but that's mainly because of the special memory allocator requirements, 
serialization and marshaling requirements.

Rather difficult is writing an Dispatch interface with no framework.

Ludicrously difficult is programming in machine code for a processor 
that doesn't yet exist's micro-ops. ;)

-- 
~Mike

Post a reply to this message

On 6/8/2010 3:03 AM, Invisible wrote:

> Oh, wait - you'd need a hex editor to do that...

I hear there's a nice one coming out ... some time. Written by a member 
of this newsgroup, too!


-- 
~Mike

Post a reply to this message

>> Oh, wait - you'd need a hex editor to do that...
> 
> I hear there's a nice one coming out ... some time. Written by a member 
> of this newsgroup, too!

Yeah, there is. Just as soon as I finish writing it. :-P

Post a reply to this message

> Ludicrously difficult is programming in machine code for a processor 
> that doesn't yet exist's micro-ops. ;)

That depends on how complex the processor is, now doesn't it? ;-)

Post a reply to this message

On 6/8/2010 3:31 AM, Invisible wrote:
>
> (Unless, of course, you're working with a language which actually has
> built-in support for calling DLLs. Then presumably it *is* trivial.)
>

Any language that uses the pascal calling convention or allows the use 
of the pascal calling convention has built in support for calling at 
least the system DLL's (results may vary with others, especially C++ 
dlls that use name mangling and thiscall calling convention. But, if you 
can emit machine code, you're golden. ;) Just load ECX or RCX with the 
target's address push the arguments on the stack (in the proper order) 
and you're golden. ;)

>> So long as your language allows you to set up a block of data with the
>> common data types it shouldn't be at all tricky.
>
> Heh, right.
>
> I still think recording a few keypresses and doing some statistics on
> them is way, way simpler.


-- 
~Mike

Post a reply to this message

>> (Unless, of course, you're working with a language which actually has
>> built-in support for calling DLLs. Then presumably it *is* trivial.)
> 
> Any language that uses the pascal calling convention or allows the use 
> of the pascal calling convention has built in support for calling at 
> least the system DLL's.

Dude, that's like saying...

> But, if you can emit machine code, you're golden. ;)

...oh god.

Hey, you know there are people who solved the Project Euler problems 
using only assembly, right? :-P

Post a reply to this message

On 6/8/2010 7:41 AM, Invisible wrote:

> Hey, you know there are people who solved the Project Euler problems
> using only assembly, right? :-P

I'm sure there are... Say! That sounds like a really fun challenge!

-- 
~Mike

Post a reply to this message

On 6/8/2010 7:29 AM, Invisible wrote:
>>> Oh, wait - you'd need a hex editor to do that...
>>
>> I hear there's a nice one coming out ... some time. Written by a
>> member of this newsgroup, too!
>
> Yeah, there is. Just as soon as I finish writing it. :-P

You're writing one, to? Et tu, Andy?

-- 
~Mike

Post a reply to this message

On 6/8/2010 7:30 AM, Invisible wrote:
>> Ludicrously difficult is programming in machine code for a processor
>> that doesn't yet exist's micro-ops. ;)
>
> That depends on how complex the processor is, now doesn't it? ;-)

I suppose, but it makes debugging a royal PITA either way ;)

-- 
~Mike

Post a reply to this message

>>>> Oh, wait - you'd need a hex editor to do that...
>>>
>>> I hear there's a nice one coming out ... some time. Written by a
>>> member of this newsgroup, too!
>>
>> Yeah, there is. Just as soon as I finish writing it. :-P
> 
> You're writing one, to? Et tu, Andy?

I had a go at writing one, and eventually gave up.

Post a reply to this message

>>> Ludicrously difficult is programming in machine code for a processor
>>> that doesn't yet exist's micro-ops. ;)
>>
>> That depends on how complex the processor is, now doesn't it? ;-)
> 
> I suppose, but it makes debugging a royal PITA either way ;)

Again, depends how complex. ;-)

Post a reply to this message

On 6/8/2010 8:16 AM, Invisible wrote:

> Again, depends how complex. ;-)

OK, How about this one. Coding x86 Machine Language with no assembler. 
That's difficult ;)

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:
> On 6/8/2010 8:16 AM, Invisible wrote:
> 
>> Again, depends how complex. ;-)
> 
> OK, How about this one. Coding x86 Machine Language with no assembler. 
> That's difficult ;)

Hell yes. But that's because the x86 system has become ridiculously 
over-complicated with decades' worth of backwards-compatibility crap. 
(E.g., real-mode exists, even though most desktops spend less than 0.01% 
percent of their time running in this mode.)

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> On 6/8/2010 8:16 AM, Invisible wrote:
>
> > Again, depends how complex. ;-)
>
> OK, How about this one. Coding x86 Machine Language with no assembler.
> That's difficult ;)

At least you only need 3 keys on your keyboard ;-)

http://homepages.strath.ac.uk/~cjbs17/computing/binary.html

Post a reply to this message

Invisible wrote:

> That's quite nice, but a cursory inspection of the JavaScript code 
> reveals how it works: In effect, the first keypress starts a timer. The 
> displayed BPM is simply the time elapsed between the first and most 
> recent keypress divided by the total number of presses.
> 
> Now I'm wondering if I can come up with something a little more 
> accurate. (Although, obviously, accuracy is ultimately determined by how 
> good your coordination and sense of rhythm are!)

Take a look at the attachments.

The first one shows the normal prediction method - take the duration of 
time between the first and last tap, divide by the number of taps. This 
gives you the beat period (i.e., seconds/beat). The BPM figure is just 
the reciprocol of this (with some conversion of units).

As you can see, if you compare the predicted beat times to the actual 
taps entered, there's quite a lot of error. But, more seriously, the 
error shows a pronounced linear trend. In other words, the BPM figure is 
wrong, causing the taps and the prediction to gradually change their 
phase relationship.

Now take a look at the second attachment. This is produced using a 
propper linear regression. (Simple least squares, apparently.) Here the 
algorithm has quite rightly detected that the first few taps are 
horribly out of time, while the remaining ones fit neatly onto a regular 
beat grid at 129.98 BPM (verses the 131.72 BPM detected by the other 
method).

I notice there's still a slight linear trend to the errors, so maybe the 
true BPM figure is actually lower still.

What the first method is doing is basically setting the prediction error 
of the first and last tap to exactly zero, and linearly interpolating 
between. This works horribly if the first and/or last taps are 
particularly out of time. It's basically using 2 data points to detect 
the right BPM figure.

On the other hand, I'm not sure, but I'd guess that *least squares* 
linear regression probably assigns a large penalty to points with large 
errors. In other words, out-of-time points are especially significant. 
Obviously what *I* want is for out-of-time points to be especially 
*insignificant*. I want to maximise the number of points with low 
errors, not minimise the total error size.

Also, I have no idea how to compute a confidence value for the 
regression predictions, other than by using the statistics of the tap 
time-deltas as an estimate...

Post a reply to this message

Attachments:
Download 'bpm1.png' (25 KB) Download 'bpm2.png' (21 KB)

Preview of image 'bpm1.png'

Preview of image 'bpm2.png'

Invisible wrote:
> Now take a look at the second attachment. This is produced using a 
> propper linear regression. (Simple least squares, apparently.)

In solomn truth, both the simple and fancy algorithms tend to produce 
very similar results, given the same data. Regression fit produces 
smaller error values by getting the phase alignment correct, but they 
both report roughly the same BPM reading.

Also, they are both equally perplexed by missing / additional beat 
signals, so I need to go figure that out...

Post a reply to this message

> Also, they are both equally perplexed by missing / additional beat 
> signals, so I need to go figure that out...

With your array of times-between-beats, calculate the mean and sd of the 
whole array, then remove any entries that are outside of the mean +/- N*sd 
before you do your BPM calculation.  You can choose N based on the results, 
but I guess around 1 should work.

Post a reply to this message

scott wrote:
>> Also, they are both equally perplexed by missing / additional beat 
>> signals, so I need to go figure that out...
> 
> With your array of times-between-beats, calculate the mean and sd of the 
> whole array, then remove any entries that are outside of the mean +/- 
> N*sd before you do your BPM calculation.  You can choose N based on the 
> results, but I guess around 1 should work.

Yes, that's more or less my plan. I just haven't coded it yet.

Post a reply to this message

I had expected the taps to be approximately correct, but jittered either 
side of the correct points by a roughly normal distribution. However, 
this is not what I observe.

Take a look at the first attachment. There's an obvious U-shapred trend 
in the error graph, and I have no idea why. It appears very, very 
frequently though. But aside from that, the errors look much more like a 
random walk than a normal distrubition. The timing error in each tap 
appears to be highly correlated with its neighbors.

The second attachment shows a similar pattern (although the U-shapred 
trend is now inverted). Note the difference in tempo between the two 
examples.

I hypothesize that what actually happens is that my tapping is actually 
running off an internal mental clock, which is being adjusted by a 
feedback loop that keeps it reasonably in-phase with the actual 
drumbeat. Hence the random-walk variations.

Of course, it's possible that the music I'm tapping to actually contains 
subtle tempo variations. Or that some of these patterns are prediction 
errors. I think what I need to do is perform a tapping experiment with a 
timing source of known tempo, so I can get genuine error measurements. 
(Currently it's tricky to reperate human tapping errors from computer 
prediction errors.)

Post a reply to this message

Attachments:
Download 'bpm1.png' (14 KB) Download 'bpm2.png' (16 KB)

Preview of image 'bpm1.png'

Preview of image 'bpm2.png'

Invisible wrote:

> I think what I need to do is perform a tapping experiment with a 
> timing source of known tempo, so I can get genuine error measurements. 

Heh, this is more difficult than you'd imagine.

I wrote a small program that basically does

   Get wall time.
   Save wall time to file.
   Print something to stdout.
   Wait X seconds.
   Repeat.

The amount of time is computed from the requested BPM. Only trouble is, 
when I analysed the resulting data, I discovered that the program is 
ticking too slowly. (E.g., I request 135 BPM, but I get 128 BPM.)

So then I tried having a thread that just does

   Send signal.
   Wait X seconds.
   Repeat.

and another thread that waits to receive a signal, and then does all the 
other stuff. But noooo, the timing accuracy has increased, but it's 
still ticking too slowly.

Thing is, what I want to do isn't "wait until X seconds from now", it's 
"wait until time X". But there isn't a function to do that. If there 
was, I could take the wall time now, compute the correct time for all 
future clock ticks, and schedule the thread to run at those times. But 
there isn't.

So I started digging through the library source code. Oh, this is fun: 
Internally the "wait X seconds" function is implemented using a "wait 
until time X" function. But it's private, so I can't call it. Thanks, 
guys...

Next plan: Write out a WAV file containing sonic pulses with the correct 
timing. Because, let's face it, there isn't much that can go wrong here.

Post a reply to this message

On 6/9/2010 5:18 AM, Invisible wrote:


> I hypothesize that what actually happens is that my tapping is actually
> running off an internal mental clock, which is being adjusted by a
> feedback loop that keeps it reasonably in-phase with the actual
> drumbeat. Hence the random-walk variations.

Am I the only one who thought PLL when I read this?


-- 
~Mike

Post a reply to this message

>> I hypothesize that what actually happens is that my tapping is actually
>> running off an internal mental clock, which is being adjusted by a
>> feedback loop that keeps it reasonably in-phase with the actual
>> drumbeat. Hence the random-walk variations.
> 
> Am I the only one who thought PLL when I read this?

No, that's pretty much what I was thinking when I wrote it...

Post a reply to this message

> and another thread that waits to receive a signal, and then does all the 
> other stuff. But noooo, the timing accuracy has increased, but it's still 
> ticking too slowly.

If you can call API functions, call QueryPerformanceCounter from 
Kernel32.dll.  It is pretty much the ultimate in terms of useful timing 
accuracy and resolution under windows.  It only takes one parameter (a 
pointer to a 64-bit signed integer) so should be easy to set up if you don't 
have the header.

Post a reply to this message

>>> I hypothesize that what actually happens is that my tapping is actually
>>> running off an internal mental clock, which is being adjusted by a
>>> feedback loop that keeps it reasonably in-phase with the actual
>>> drumbeat. Hence the random-walk variations.
>>
>> Am I the only one who thought PLL when I read this?
>
> No, that's pretty much what I was thinking when I wrote it...

I also thought about it when I suggested to write code to find the BPM 
automatically.

Post a reply to this message

scott wrote:
>> and another thread that waits to receive a signal, and then does all 
>> the other stuff. But noooo, the timing accuracy has increased, but 
>> it's still ticking too slowly.
> 
> If you can call API functions, call QueryPerformanceCounter from 
> Kernel32.dll.  It is pretty much the ultimate in terms of useful timing 
> accuracy and resolution under windows.  It only takes one parameter (a 
> pointer to a 64-bit signed integer) so should be easy to set up if you 
> don't have the header.

http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx

"Retrieves the current value of the high-resolution performance counter."

 From what little documentation there is, it seems this allows me to 
measure wall-time, really accurately. Which isn't the problem - the 
problem is scheduling a thread to run when I actually want it to run.

Post a reply to this message

Mike Raiford wrote:

> Ludicrously difficult is programming in machine code for a processor 
> that doesn't yet exist's micro-ops. ;)

If it makes you feel any better...

http://en.wikipedia.org/wiki/6502#Bugs_and_quirks

Note also that the 6502 doesn't have any microcode. It just uses a PLA 
as the control matrix - much like the processor that I'm designing. ;-)

Post a reply to this message

>> Ludicrously difficult is programming in machine code for a processor that 
>> doesn't yet exist's micro-ops. ;)
>
> If it makes you feel any better...
>
> http://en.wikipedia.org/wiki/6502#Bugs_and_quirks
>
> Note also that the 6502 doesn't have any microcode. It just uses a PLA as 
> the control matrix - much like the processor that I'm designing. ;-)

FWIW when Acorn designed the original ARM processor, one person designed and 
simulated it on a 6502 before starting actual hardware design.  IIRC it only 
took a very small number of people in total (like 5 or 6) to design the 
hardware implementation.

According to wikipedia over 10 billion ARM cores have been built, I bet they 
never imagined that when they were sat at their 6502's designing it back in 
the 80s :-)

Post a reply to this message