Calculating midi ticks per bar

[Ap0C552]

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]

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]

Thanks!

[fmr]

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.

[mystran]

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.

[fmr]

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.

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

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.

[mystran]

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.

[jussi_neuraldsp]

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]

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

[engineer]

nobody cared in the last 35 years of MIDI's history

hm, I know a large number of musicians who refuse to work with MIDI at all because of all the timing and granularity issues when using setups with higher numbers of simultaneous notes.

The problem was lowered by USB, alltough we have an additional unpredictable latency.
http://www.96khz.org/oldpages/enhancedm ... ission.htm
http://www.96khz.org/oldpages/limitsofm ... larity.htm

The point is that this is one of the reasons no 1 why people turned over to the PCs, where the is no bottle neck between sequencer and synthesizer.