JavaScript Sequencer MIDI file timing resolution (PPQN)

Question

I read a lot about MIDI resolution and studied some codes like Tone.js and heartbeat. But I don't understand why there are different Pulses Per Quarter Note (PPQN) values and what the effect it has on playing notes. When I have 960 PPQN so this means 1 quarter note has 960 ticks, 1 eight note 480 ticks, ect. And if I understand it correctly, the delta time is just a relative value.

What I don't understand right is, what should the PPQN when I play notes in JavScript, and when I set the PPQN why it should have this value? For example I use the WebAudio API for playing notes:

function nextNote() {
  var quarterBeat = 60.0/tempo;
  nextNoteDuration = nextNoteDuration + (quarterBeat/32);
  currentNote++;
}

This way I can play different notes durations. Now when I read the MIDI file, should I just compare the delta time and convert it to my sequencers current playback? For example when I read a MIDI file with this values:

Tempo = 120
PQN = 960
4 Quarter Notes

I read the MIDI file, save the notes in an array (assume the delta time is for each note a 1/4)

duration = [quarterNote, quarterNote, quarterNote, quarterNote]

And play the notes:

while (nextNoteDuration < audioContext.currentTime) {
  if (duration[i] %32 == 0) playNote(currentNote, nextNoteDuration);
  nextNote();
  i++;
}

Should I use PPQN only when exporting a MIDI file? If so, in relation to what should I set the PPQN? I hope someone can explain this to me in more detail.

Answer 1

PPQ is about resolution. More specifically about time resolution.

what should (be?) the PPQN when I play notes in JavScript, and when I set the PPQN why it should have this value?

When your program plays notes, it may use whatever time units you want or need, for instance milliseconds, nanoseconds, movie frames, ticks. Absolute wall clock or relative times. It depends on your sequencer capabilities and your software features. It is only required to choose a PPQ value when storing MIDI sequences as MIDI files. Of course you need to be able to convert time units when reading/storing MIDI files.

Now when I read the MIDI file, should I just compare the delta time and convert it to my sequencers current playback?

Of course, if internally your music events use a different time representation, then you need to be able to translate the delta times from the MIDI file to your internal representation.

You are only asking about PPQ, but this value is found only once, at the MIDI file header. The tempo events in contrast may occur multiple times along the file, and it affects to the translation of the next delta times into wall clock times until the next tempo event. If your sequencer/player allows the user to change/add tempo events, it would be a good idea to use relative units instead of wall clock units for internal time representation (or both).

Should I use PPQN only when exporting a MIDI file? If so, in relation to what should I set the PPQN?

Yes, you need to choose a suitable value for PPQ when you export a MIDI file. If your internal time units are relative (as most sequencers do) then use your internal unit resolution for PPQ. If you convert from wall clock units to delta times, then you need to choose a resolution which your translation loses less details (by quantization). Higher values are better in this sense. Rosegarden stores MIDI files always with 960 PPQ. In contrast, Steinberg's Cubase used 480. I remember using Cakewalk a long time ago having only 120 PPQ, but later versions allowed this value to be changed as a configuration setting. In general you need to accommodate not only all music figures shorter than quarter, including subdivisions like triplets, etc. but you also need to take into account effects like swing that are based on fine time adjustments.

Answer 2

In a standard MIDI file, there’s information in the file header about “ticks per quarter note”, a.k.a. “parts per quarter” (or “PPQ”). For the purpose of this discussion, we’ll consider “beat” and “quarter note” to be synonymous, so you can think of a “tick” as a fraction of a beat. The PPQ is stated in the last word of information (the last two bytes) of the header chunk that appears at the beginning of the file. The PPQ could be a low number such as 24 or 96, which is often sufficient resolution for simple music, or it could be a larger number such as 480 for higher resolution, or even something like 500 or 1000 if one prefers to refer to time in milliseconds.

What the PPQ means in terms of absolute time depends on the designated tempo. By default, the time signature is 4/4 and the tempo is 120 beats per minute. That can be changed, however, by a “meta event” that specifies a different tempo. (You can read about the Set Tempo meta event message in the file format description document.) The tempo is expressed as a 24-bit number that designates microseconds per quarter-note. That’s kind of upside-down from the way we normally express tempo, but it has some advantages. So, for example, a tempo of 100 bpm would be 600000 microseconds per quarter note, so the MIDI meta event for expressing that would be FF 51 03 09 27 C0 (the last three bytes are the Hex for 600000). The meta event would be preceded by a delta time, just like any other MIDI message in the file, so a change of tempo can occur anywhere in the music.

Delta times are always expressed as a variable-length quantity, the format of which is explained in the document. For example, if the PPQ is 480 (standard in most MIDI sequencing software), a delta time of a dotted quarter note (720 ticks) would be expressed by the two bytes 85 50 (hexadecimal).

So, bearing all that in mind, there is a correspondence between delta times expressed in terms of ticks and note values as we think of them in human terms. The relationship depends on the PPQ specified in the header chunk. For example, if the PPQ is 96 (hex 60), then a note middle C on MIDI channel 10 with a velocity of 127 lasting a dotted quarter note (1.5 beats) would be expressed as 00 99 3C 7F // delta time 0 ticks, 153 60 127 90 99 3C 00 // delta time 144 ticks, 153 60 0