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 } Read current time. 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************ with Ada.Real_Time; use Ada.Real_Time; with Ada.Text_Io; -- with Ada.Standard; procedure TestTime is -- ---------------------------------------------------------- -- GET THE STARTING TIME, LOOP, GET THE END TIME, SUBSTRACT -- ---------------------------------------------------------- Time_Start : Ada.Real_Time.Time; Time_End : Ada.Real_Time.Time; Time_Difference : Ada.Real_Time.Time_Span; Time_Duration : Standard.Duration; begin Time_Start := Ada.Real_Time.Clock; for I in 1..1 loop delay 60.00; end loop; Time_End := Ada.Real_Time.Clock; Time_Difference := Time_End - Time_Start; Time_Duration := Ada.Real_Time.To_Duration(Time_Difference); Ada.Text_Io.Put("Time Difference: "); Ada.Text_Io.Put(Duration'Image(Time_Duration)); 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. As a side note, our team feels very strongly about this project and its 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, or would like more information, please send us an email: [log in to unmask] Musisis: Performance Sequencer Jesse A Farmer: CEO S.O.S. Designs Science of Sound: a Centre for Future Music Systems