How to calculate the BPM (with a stopwatch and a calculator) if you know the duration of a bar (in seconds); and why 96 PPQ is proper.

  • Thread starter Thread starter 909 County Fair
  • Start date Start date
909 County Fair

909 County Fair

Member
I wanted to store this info here (again).
It's computational advice and explanation about exactly what the title says.

galc.png

stopwatch-interface.gif

240 (which is a musical constant) divided by 3.18 seconds = 75.4716981132 BPM, see.
qq_20190426203502.png


Some of us musicians know of this technique, perhaps used in some DAW programs:

240 (mathematical constant) / duration of a measure (in seconds) = BPM (which can be halved or doubled as needed)

This works if you have a selection which is known to be or assumed to be the exact duration of a measure (or two, or half).
This also works for users manually if using a stopwatch and starting on the downbeat and stopping at exactly the next downbeat (which is also the complete end of a measure).

Some people call measures "bars" and visa-versa.

Some BPM's match conventional timing grids rather easily, without peculiar decimal fractions; they convert well to mathematical whole numbers. For example:

240 / 7s = 34.2857142857 BPM (mathematically related to 68.5714285714 BPM)

240 / 6s = 40 BPM (mathematically related to 80 BPM);
240 / 5s = 48 BPM (mathematically related to 96 BPM);
240 / 4s = 60 BPM (mathematically related to 120 BPM);
240 / 3s = 80 BPM (mathematically related to 160 BPM);
240 / 2s = 120 BPM;... (240 / 1s = 240 BPM)... see...

Algebraically, you can use 240 (constant) divided by the BPM to yield the duration of a solitary measure also.

Some popular BPM's:

Jungle/Drum-N-Bass/Dubstep Classics = 70 BPM or 140 BPM...

240 / 70 BPM = 3.42857142857 seconds = 1 measure
240 / 140 BPM = 1.71428571429 seconds = 1 measure

Lately, the "embers" subgenre(s) favor 160 BPM...

Check above, it's 80 BPM x2, thus also...

240 / 160 BPM = 1.5 seconds = 1 measure (gridmatches 3 seconds)
240 / 3 seconds = 80 BPM = 1/2 of 160 BPM (etc)....

Even if using fractions, some of them work out sorta easily.
For example, one of my favorites is 75 BPM:

240 (the constant) divided by 75 BPM = 3.2 seconds = 1 measure;
However...

Notice that 3.2 seconds is easy to read if you subdivide your measures musically into 32nd notes, 16th notes, 8th notes, etc...

3.2 seconds divided by 32 = 0.1 seconds = one 32nd note
3.2 seconds divided by 16 = 0.2 seconds = one 16th note
3.2 seconds divided by 8 = 0.4 seconds = one 8th note
3.2 seconds divided by 4 = 0.8 seconds = one quarter note
3.2 seconds (one measure) div by 2 = one half note
3.2 seconds div by 1 = one whole note
3.2 seconds * 2 = one breve rest duration = (two whole measures) = 6.4 seconds

3.2 seconds divided by 64 = 0.05 seconds = one 64th note.

To get dotted notes, take the duration of a note and multiply it times 1.5 (150% of original value).

To get triplets, take the duration of a note and divide it by 3.

3.2s divided by 3 = 1.0666666666 seconds
3.2s divided by 6 = 0.533333333333 seconds
3.2s divided by 12 = 0.26666666666 seconds
3.2s divided by 24 = 0.133333333333 seconds
3.2s divided by 48 = 0.066666666666 seconds
3.2s divided by 96 = 0.033333333333 seconds
3.2s / by 192 = 0.016666666666 seconds

Those are all VERY musically valuable. Works for Waltz and Dubstep.

That's how you can essentially logically work out your timing grid.
That's your available quantization grid for subsections involving triplets at whichever speed you need.

Of course, before that, was the essential logical timing and quantization grid for sections or subsections in Common Time (4/4 Compatible).

It's NOT overkill. In certain musical genres, the breakbeat and edit resolution is literally at up to about 192 subdivisions.

At more than that, you might as well start measuring PPQ (pulses per quarter note) and recalculate what you're trying to do.

Last but not least, most Hi-res PPQ values are highly irrelevant except for matching MIDI events to SMPTE or linear time at miniscule clock "ticks". Most MIDI hardware works at 96 PPQ; it's been that way for several decades. Some even runs at 48 PPQ without problems. 96 PPQ is maximally compatible.

If your system is working your MIDI rig at anything in triple or quadruple digits of PPQ, you're just wasting CPU power and making the system brutalise itself despite lack of both computational and musical relevance.

Remember, PPQ = pulses per quarter note.
So, at 96 PPQ, one measure (Common Time) has 384 pulses total.
Because 96 PPQ * 4 = 384 pulses in 1 measure (in 1 bar).

So, if you have 384 of them, then...
384 div 64 (64th notes) = 6 pulses per 64th note.

But most people don't compose nor perform with 64th notes.
But even if you do, 1/3 of 6 pulses is 2 pulses, so you can still do 64th note triplets and be synchronized just fine.
at 2 pulses per note, one is for MIDI NOTE ON, and the other is for MIDI NOTE OFF (or velocity both times).

That would use up the resolution, but that's all that's needed, so nothing is lost either. That's right at the efficiency.

If at that tiny note level you need differentiation between legato and staccato, consider that to be at the 32nd note level instead or play differently or use a different BPM.

Remember, we were talking about 64th notes!!!!

IMPORTANT: But most people are really only using quarters, eighths, sixteenths, and 32nds!!! Even and especially within classical notation, it's frowned upon to be using tiny little note durations for most musical styles.

Of course, drum-n-bass, jungle, drill-n-bass, drumcore, surf, etcetera might still be really fast, so that's why I was explaining all of this. You likely *WON'T* need triple nor quadruple digits of PPQ (unless you need to sync to SMPTE time code for film or something like that).

Your system doesn't need to measure any durations of time below or between that. That's typically in spite of your BPM, unless you *really* need NON-QUANTISED and precisely exact recording/playback.

But if that's the case, then turn off MIDI and just record as audio to WAV @ 44 kHz or 48 kHz and use the stability of that protocol.

Anybody not fighting their own system buffers will notice fewer CPU hiccups, buffer underruns, xruns, or glitches if they/you just release the pressure and scale back down to 96 PPQ, which has been stable for the longest time, culturally, technologically, musically. If it's still not precise enough, scale up gradually and not too much and stop where it sounds fine.

If your hardware is at 48 PPQ, and can't go any higher, just double the BPM wherever it helps, most likely within that hardware.

Remember, even with FSK (frequency shift keying) for MIDI synchronization, that's pretty good and musically most people can't hear nor witness the microscopic variations or tolerances of the notes.

It might be more of an aesthetic relevance for continuous controller messages, even maybe for some kinds of pitchbend... but at least now you know a proper mathematical set of references.

Sincerely, 909 County Fair
The "LAW" (Linux Audio Workstation) Enforcement.

P.S. = https://www.bing.com/images/search?q="96 PPQ" "MIDI" "drum machine" "sequencer"&qs=n&form=QBIR&sp=-1&lq=0&pq="96 ppq" "midi" "drum machine" "sequencer"
 
Last edited:
Back
Top