Questions have been asked regarding the need for such accurate timing for
playback of midi events.
When you consider 120 ticks per beat, quite often there are not 120 events
occuring in that time period.  What a ppq value serves to do is offer a
resolution of playback.  To capture what is known as 'feel', the more
possible slots in a division of time you have, the more accurate to the
true performance you will be.

You may ask, how accurate is the human ear in hearing such timings?  Given
a series of notes, that approxamates a known 'feel' template, such as
various styles of jazz, the human error can detect a few tick values of
error at 480 PPQ.  The human ear, in certain settings can easily detect
errors of 1-2 milliseconds.  Given a series of events spaced over an
interval, situations can arise, where a trained musician can discern a
'falibility' in the feel of a playback.  This, in essence, is a detection
of tens of microseconds errors.

The speed of midi hardware is 31.25 (+/- 1%) Kbaud, asynchronous, with a
start bit, 8 data bits (D0 to D7), and a stop bit. This makes a total of 10
bits for a period of 320 microseconds per serial byte.  However, the speed
of the hardware is IRRELEVANT for programming concerns.  As I mentioned, a
situation in which an event takes place on every possible tick is unlikely.

 >"It's supposed to be about music. "Ticks" be d*mned! Where are
 >the definitions of Whole_Note, Half_Note, Quarter_Note, etc.? Base these
 >on "Ticks per measure", then forget about ticks. "

Obviously you have no knowledge of how midi works.  Durations of notes are
specified in the events themselves.  Furthermore a 'quarter' note is not a
pure duration in actual music.  There are infinitely many possible
durations that a quarter note will assume, often as music specifies,
staccato, or legato.  You do not 'define' note values, except when you are
allowing the user to create notes via a graphical editor.

 >"Define the pitches using
 >something akin to do, di, re, ri, mi, fa, etc., and you will be able to
 >change the key just as easily."

I hope this was a joke.  Pitches are defined using numbers in the note
message, which makes transposition effortless.  But that is not a concern
right now, timing is.

 >"If something is supposed to happen at a 5KHz or 200 mic, rate, how many
 >mics of random jitter does it take to produce significant noise energy
 >in the range of human hearing? If you are trying to produce two
 >sequences at 5 and 5.01 KHz, so the beat is down at 10 Hz, you need to
 >generate one of them at 200 mics and the other at 199.6 mics. If your
 >clock resolution is 2 mics, then you'll get one at 200 and the other at
 >198, for frequencies of 5Khz and 5.05 KHz, giving a nice 50Hz beat.
 >That applies to direct control of a waveform. I too am surprised that
 >Midi, which is control of a device that generates a waveform, has such
 >tight timing requirements.

Midi does not control or generate a waveform in any way.  Midi simply
relays instructions for synthesizers to do various operations.
What we are attemping to do with this program is generate extrememly
accurate or 'steady' timing.  Musicians have long favored dedicated
hardware sequencers for their timing, which is based off a crystal
osc.  Next, they have favored Mac, because their timing differences are
AUDIBLE.  I personally can tell what system a particular sequence was
recorded off of.  Having both mac and win systems, I have A/B'd this and
could quite easily hear the timing differences in the playback of the same
file.
We are sacrificing PPQ (using likely 120 instead of 480 or 960) to achieve
a Rock Steady playback.

Again, we are looking for ways to achieve this.  We are open to suggestions
of course, and we have been trying out some ideas of our own.  This kind of
timing can be done; to what degree of accuracy is the question.  I welcome
anyone else's take on this.

Thanks for your time, if you have read this far.
-Jesse Farmer.