```Hi.  This is my first post to the list.

I am working with a team designing a midi sequencer.  The problem we are
encountering, is timing.  Because we want high reliability, and a steady,
fast timer, we have chosen ada as the language to code this in.  We are
hoping this is not in error, but our tests so far are not promising.

Let me explain what is necessary.  We have a list of events.  Each event
has a time, given in Bars, Beats, and Ticks.  There are 480 ticks in a
beat, and usually 4 beats in a bar.  What is important, is how fast this
translates to in realtime.  Music tempos are given in beats per
minute.  The fastest tempo we hope to support, is 300bpm.  140bpm is
probabaly the tempo that will be used the most.  To figure out how many
seconds long 1 tick is at a given tempo, the following formula is used.
( 1 / ( BPM / 60 ) ) / PPQ
PPQ is pulses per quarter note, or ticks.  We ideally want to use 480, but
240, or 120 will work also, if necessary.  Many commercial programs use
480, and some use 960 or 1920.

We believe the best way to time the playback of these events, is to have a
timer running as an independant process, looping.  Each iteration of the
loop would take 1 tick, and after each iteration, a location in memory
would be incremented, starting with 0, and counting up to 479.  This
location could then be monitored by other parts of the program, without
effecting the timing process.

Using 140bpm and 480 ppq, one tick is
0.000892857142857142857142857142857143 seconds long.
Now how many of those digits are signifigant?  Well, a comparable tempo,
141, would be 0.00088652482269503546099290780141844 seconds long per
tick.  Difference = 0.000006332320162107396149949341 seconds long
Which essentially means we need 1-2 microsecond resolution.  This probably
can't be done.

So with the same tempos, using 120 ppq, we get,
0.00357142857142857142857142857142857    140
0.00354609929078014184397163120567376    141
0.0000253292806484295845997973657548126  difference
25 microseconds, which is much more doable.

In any case, we need high accuracy, as far as I can detirmine.  The bare
minimum we can have is 96 ticks per beat.  Even this seems to require
rather high resolution timing.

In order to test the timing possible on a given system, we contructed a
test program which does the following:
Reads the current time, and stores it
Loop 17,400 times {
Wait 0.00344827586206896551724137931034483 seconds
}
Subtract current time from time read at beginning of program.
Display difference.

What this simulates is timing at 145 bpm with a 120 ppq.  With 145 beats in
a minute, and 120 ticks in a beat, this program's loop should take exactly
60 seconds to execute, or reasonably close to that.  Our source code follows:

*********begin code************

procedure TestTime is

-- ----------------------------------------------------------
--  GET THE STARTING TIME, LOOP, GET THE END TIME, SUBSTRACT
-- ----------------------------------------------------------

Time_Duration   : Standard.Duration;

begin

for I in 1..1 loop
delay 60.00;
end loop;
Time_Difference := Time_End - Time_Start;

delay 30.0;

end TestTime;
**********end code**************

Our results:  Running on a pent 233mhz
92.672597596
90.974294742
88.223668684
88.582477917
89.054762903
89.219054124
88.801019125

Results on an Athlon 1ghz were comparable.  Both systems running Win98se.

Why is this so incredibly off?  iterating a for loop 17,400 times with the
delay statment set at 0 yielded a time of only .47 or so seconds.  One
iteration of the for loop, with the delay at 0 takes only .0004 some
seconds max.

musical merits.  The design is such that it is incredibly unique, and
unlike any other product currently available, and is intended to fill a
niche that is known to exist, but no solution has been developed for.  As
you can see, this is quite a challenging project, and we have several other
componets of this program that present equally great challenges, such as a
macro-lanaguage.

This project is being developed with the intentions of it eventually
running on Windows, Mac, and Linux systems.  At this point in time, all of
the initial design is complete; object lists, and such, as well as detailed
descriptions of all parts of the program exist.  GUI design is in mid
design stages, with may of the bitmaps as well as general layouts complete.

We are looking for one or two programmers (preferably with ada and/or
musical application and/or realtime system experience.  Please note that
the use of ada is contigent upon the feasibility of its realtime
implementation on Windows systems.  Unfortunetly, this project offers no
financial compensation initially.  This is intened to be a commercial
product however, and development team members can expect to receive equal
distributions of the profit from this project.  This project was not
undertaken with the expectation of attaining wealth, but rather creating a
new tool that, if sucessful, will quite literally revolutionize the
electronic music field.  Working on this project is certainly not a
full-time obligation.  All team members currently have other
responsibilites.  If you feel you would be interested in working with us,