In a MIDI file, an event's time is specified as a delta time, i.e., relative to the previous event's time. And the tempo can change at any time. To compute an event's absolute time, you have to use the current tempo value.

(In a file with multiple tracks, merge them before computing the times.)

External devices do not know what the sender's tempo is, unless it is sending MIDI click messages.

Are we talking about representing notes in a UI as it relates to time? Or I/O play back of notes to instrument destinations?

Well i am thinking of how the actual tracks rendered and played up with BPM changes, "if the note distances precalculated before playup "at the specific ***BPMS*** when there is more then one***.

So i guess its an I/O question about, if the note timedistaces are rendered/changed realtime, or if they precalculated before playup.
Bascily is there BPM changes in the realtime "playup messagestream" and note distances recalculated on the fly, or are the list of BPM changes used before hand playup to calculate the time distances(pauses.

Some of the comments here seem to be over-thinking things, making things seem more complicated than they are.

Talking about midi files....

The PPQ and initial tempo settings are quite incidental, they merely set a base, and would usually be appropriate to the piece of music. The midi file contains the tick count for each event, and this is fixed, and does not change, and is not subject to 'recalculation' - it is merely the relative spacing of the events.

The playing software would always know what the next event is, and it would wait until the next event is due, and then implement it. It would to this by comparing the tick value in the midi file, with the actual real time as determined by the device clock. This comparison will require some sort of calculation, as we are comparing two quite different numbers, ticks and microsecs. Exactly how each piece of software handles this comparison will be up to that piece of software, different systems may do it differently, but the calculation will take into account the actual tempo at that point in time, PPQ, etc, and if need be change the 'value' of each tick to a quantity of microsecs. So the ticks in the midi file do not change, but what each tick is really worth does.

As has been said, there are midi files that may change the tempo any number of times during playback. The effect of this change should be immediately heard, as this change is often used for dramatic effect in the music.

The playing of a midi file never involves the sending of any timing info to external devices. Timing is the responsibility of the playing/controlling device, which sends On/Off etc data out and expects that it will be impemented immed. The sort of 'synchronisation' referred to is more likely relevant to playing various instruments in a real time (live) situation where certain devices may have a live 'player' and other devices may be semi automatic (running a program) and you need to ensure everything is on the same clock.

Geoff

Thanks for all kind answers, but i am still not sure i get it. My sequenser use "PPQ and BPM" to calculate "the waitstate" between notes "the timing of each note".
And of course if BPM change, the note distance change, but i have programmed these "wait/paus" between notes as "prerendered/precaluclated" before playup "dependent on the BPM and PPQ.

But i think Geoff says that most/all sequensers using ticklength "multiplying with PPQ on the fly" during playup?

For example my sequenser could not handle, you changing BPM while playup, but a player using a REALTIME calculated ticklength * PPQ would just recalculate it to new ticklength using the new BPM and start multiply the new ticklength with PPQ in realtime? While i have all waitstates stored in an array before playup so that is not possible.
Maybe my approach storing waitstates give more exact timings, but a loss in flexibility during playup.

Of course a standard midiplayer will not let you reset any BPM at all, but i guess a midi sequenser allow for it at least in principle?
But for me it actually raise alot of questions because it seem like tempo is hardwired to the Metronome, but then Tempo must be global for all tracks. So temp can't be different beat for all tracks, somekind of polyrhytmic metronome would not be possible unless you state if before hand? Well of course the metonome could be but there is only one clockbeat common for all tracks or?

Well it all gets weird, i have been thinking about allowing different BPM for different tracks, having them local on each track.

Maybe i am overcomplicating things, but i find it all confusing.

JT

See How to correctly convert MIDI ticks to milliseconds?

Hello Clemens!

Well according to your link it seem i do it correctly "and the note times are precomputed before playup" not on the fly.
==============================
First, you have to merge all tracks, to ensure that the tempo change events are processed properly. (This is probably easier if you convert delta times to absolute tick values first; otherwise, you'd have to recompute the delta times whenever an event is inserted between events of another track.)

Then you have to compute, for each event, the relative time to the last event, like in the following pseudocode. It is important that the computation must use relative times because the tempo could have changed at any time:
===============================

But the above approach mean you can not change BPM while playup, and that is fine i guess.


I must say have had thoughts of allowing different BPM's/timedivisions on differerent tracks, to make polyrhytmic music and metronome easy to implement.

Cheers and merry christmas to all, midi boys and girls

It does not matter whether you compute the times all at once or individually, on demand. The important point is that the computation must be done relative to the time of the previous event.

What BPM(s) you're using in your program does not need to be related in any way with the tempo stored in the MIDI file.