Calculating midi ticks per bar

DSP, Plug-in and Host development discussion.
Ap0C552
KVRist
154 posts since 15 Feb, 2012

Post Sun Apr 21, 2019 10:10 am

I am trying to understand how I can take a midi resolution and convert it to ticks per bar. I am not sure if my understanding is correct.

As I understand it, midi resolution is measured in pulses per quarter note, or ticks per quarter note. So if I have a midi resolution of 100, it means there are 100 ticks per quarter note.

Now, using a specific time signature, I want to determine how many ticks are in a bar...

So if I had 4/4 time signature, that would mean 4 beats per bar, and each beat is a quarter note. Therefore if I had a midi resolution, it would mean 400 ticks per bar.

What about 3/2 time signature? In this case it is three half notes per bar.

This would be equivalent to 6/4 time signature if we deal with quarter notes, so...

PPQ * quarter_notes_per_bar = 600 ticks per bar.

Is my understand of midi resolution correct here?

dmbaer
KVRian
1261 posts since 11 Nov, 2009 from Northern CA

Re: Calculating midi ticks per bar

Post Sun Apr 21, 2019 12:42 pm

You understand correctly. One minor point, though: default DAW/host resolution will normally be divisible by 12, if not 24 or even 48. With 100, you would have to fudge on the placement of even quarter-note triplets.

Ap0C552
KVRist
154 posts since 15 Feb, 2012

Re: Calculating midi ticks per bar

Post Mon Apr 22, 2019 4:51 am

Thanks!

User avatar
fmr
KVRAF
8690 posts since 16 Mar, 2003 from Porto - Portugal

Re: Calculating midi ticks per bar

Post Mon Apr 22, 2019 5:29 am

dmbaer wrote:
Sun Apr 21, 2019 12:42 pm
You understand correctly. One minor point, though: default DAW/host resolution will normally be divisible by 12, if not 24 or even 48. With 100, you would have to fudge on the placement of even quarter-note triplets.
When I started (many years ago) 480 PPQN was a kind of standard. American sequencers all used that resolution. Steinberg Cubase, don't know why, used a lower resolution (384 PPAN, if I'm not mistaken). Then Emagic launched Logic, and doubled the resolution, to 960 PPQN.

From my experience, I would say that 480 PPQN is kind of the minimum acceptable resolution, and in some circumstances 960 PPQN is even better. Of course, that depends on the kind of music you do, if it's quantized or not, and if you use very fast tempos with very small musical figures (like 32ths or 64ths).

480 PPQN will mean that a 64th note will only have 30 pulses (ticks), which is very low if you want to precisely place it, or define its duration.

100 PPQN (which I'm not aware that any sequencer uses) will definitely NOT be enough.
Fernando (FMR)

mystran
KVRAF
5278 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Calculating midi ticks per bar

Post Mon Apr 22, 2019 6:19 am

fmr wrote:
Mon Apr 22, 2019 5:29 am
dmbaer wrote:
Sun Apr 21, 2019 12:42 pm
You understand correctly. One minor point, though: default DAW/host resolution will normally be divisible by 12, if not 24 or even 48. With 100, you would have to fudge on the placement of even quarter-note triplets.
When I started (many years ago) 480 PPQN was a kind of standard. American sequencers all used that resolution. Steinberg Cubase, don't know why, used a lower resolution (384 PPAN, if I'm not mistaken). Then Emagic launched Logic, and doubled the resolution, to 960 PPQN.
The 384 value factors into 3*2^7, where as any of the resolutions ending in 0 have a factor of 5 thrown in (eg. 480 is 3*5*2^5=96*5). If you want to divide notes in half (rather than in parts of 5) then having more powers of two could be nice... but really it probably doesn't make a whole lot of difference.

That said, at 480 PPQ if your tempo is 120BPM, then one tick is about 1.04ms long in terms of real-time. If you drop the tempo down to half, then at 60BPM we have a tick of 2.08ms. One can argue whether or not this is "sufficient" but really it's not THAT bad.

Curiously enough, FLStudio still defaults to 96 (even though you can choose from a number of values with the maximum of 960). While you do occasionally notice the quantisation if you keep the default and try to fine-tune things, even this is quite workable for a whole lot of quantised dance music. :)
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

User avatar
fmr
KVRAF
8690 posts since 16 Mar, 2003 from Porto - Portugal

Re: Calculating midi ticks per bar

Post Mon Apr 22, 2019 6:37 am

mystran wrote:
Mon Apr 22, 2019 6:19 am
fmr wrote:
Mon Apr 22, 2019 5:29 am
dmbaer wrote:
Sun Apr 21, 2019 12:42 pm
You understand correctly. One minor point, though: default DAW/host resolution will normally be divisible by 12, if not 24 or even 48. With 100, you would have to fudge on the placement of even quarter-note triplets.
When I started (many years ago) 480 PPQN was a kind of standard. American sequencers all used that resolution. Steinberg Cubase, don't know why, used a lower resolution (384 PPAN, if I'm not mistaken). Then Emagic launched Logic, and doubled the resolution, to 960 PPQN.
The 384 value factors into 3*2^7, where as any of the resolutions ending in 0 have a factor of 5 thrown in (eg. 480 is 3*5*2^5=96*5). If you want to divide notes in half (rather than in parts of 5) then having more powers of two could be nice... but really it probably doesn't make a whole lot of difference.
Well, I stated from memory. I may be wrong, though (it was like 30 years ago, more or less). Anyway, now Cubase also uses the base resolution of 480 PPQN.
mystran wrote:
Mon Apr 22, 2019 6:19 am
That said, at 480 PPQ if your tempo is 120BPM, then one tick is about 1.04ms long in terms of real-time. If you drop the tempo down to half, then at 60BPM we have a tick of 2.08ms. One can argue whether or not this is "sufficient" but really it's not THAT bad.
480 PPQN was always enough for me :shrug:
mystran wrote:
Mon Apr 22, 2019 6:19 am
Curiously enough, FLStudio still defaults to 96 (even though you can choose from a number of values with a maximum of 960). While you do occasionally notice the quantization if you keep the default and try to fine-tune things, even this is quite workable for a whole lot of quantised dance music. :)
I'm not that familiar with FL Studio, but I think its user base mainly uses the mouse to input notes. So, the music is quantized since the very beginning. For music recorded through MIDI in real-time, 96 PPQN would change it significantly. That's where 960 PPQN comes handy.
Fernando (FMR)

mystran
KVRAF
5278 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Calculating midi ticks per bar

Post Mon Apr 22, 2019 7:07 am

fmr wrote:
Mon Apr 22, 2019 6:37 am
I'm not that familiar with FL Studio, but I think its user base mainly uses the mouse to input notes. So, the music is quantized since the very beginning. For music recorded through MIDI in real-time, 96 PPQN would change it significantly. That's where 960 PPQN comes handy.
Well, with 96 PPQ you can run into resolution limitation even doing things like fine-tuning the length of notes for your basic psy-bass. It really seems a little silly to keep such a low default, but like... Image-Line is sometimes kinda weird. :)
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

jussi_neuraldsp
KVRer
2 posts since 24 Oct, 2018

Re: Calculating midi ticks per bar

Post Tue Apr 23, 2019 2:10 am

mystran wrote:
Mon Apr 22, 2019 6:19 am

That said, at 480 PPQ if your tempo is 120BPM, then one tick is about 1.04ms long in terms of real-time. If you drop the tempo down to half, then at 60BPM we have a tick of 2.08ms. One can argue whether or not this is "sufficient" but really it's not THAT bad.

Curiously enough, FLStudio still defaults to 96 (even though you can choose from a number of values with the maximum of 960). While you do occasionally notice the quantisation if you keep the default and try to fine-tune things, even this is quite workable for a whole lot of quantised dance music. :)
If you want to have sample accurate MIDI events the PPQ value must be much higher. I'm using 96000 PPQ in my products. That will provide sample accurate MIDI at 96K sampling rate and at 60 BPM.

Benutzername
KVRist
316 posts since 23 Jan, 2008 from Hamburg, Germany

Re: Calculating midi ticks per bar

Post Wed Apr 24, 2019 3:33 am

Remember that we are working with MIDI here. If you use a real MIDI cable somewhere in the chain then a complex chord with some controller changes will already put you several ms off - the first note will be off just a tiny bit but the last note will already be off by a lot. Additionally you'll never know in which order the MIDI data is processed by the receiving device so the latency pattern may even change with every loop.

So we are talking about several ms here, not a few samples (and nobody cared in the last 35 years of MIDI's history BTW). I'd say that 480ppq is more than good enough for almost all real world applications. If you really need sample accurate timing then this is way beyond the scope of MIDI/PPQ and the implementation needs a completely different approach anyway (sample offsets, ramps, curves etc).

Return to “DSP and Plug-in Development”