From: jdevlin AT WPI DOT EDU (joseph devlin) Newsgroups: comp.os.msdos.djgpp Subject: MIDI/Interrupts/Timing? Date: 23 Jan 1997 22:32:32 GMT Organization: Worcester Polytechnic Institute Lines: 72 Message-ID: <5c8ou0$8ln$1@bigboote.WPI.EDU> NNTP-Posting-Host: bigwpi.wpi.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp hello! im trying to write some midi software, using djgpp on a 386/40 machine with 4mb of ram. I have an MPU-401 midi interface, and thanks to allegro, i have some simple code for putting it into uart mode and writing data to whatever port it is located at. the thing is, since this is midi software, timing is a huge issue. I wish for my program to send out midi clocks so that it will be synchronized with external midi devices, acting as the master clock. in case you dont understand, that means that for every quarter note, 24 midi clock bytes must be sent. at least this was my understanding. so, the rate at which midi clock bytes are sent is dependent upon the tempo at which playback occurs. here is what i have been experimenting with: i create a timer, whihc occurs 102 times every second. every tick of this timer, a midi clock byte is sent out of the mpu port. every sixth tick of this clock, a flag is set. if all goes well, this should represent the highest possible tempo at which the software will run, or 255. the flag is a message to a polling loop in the main function, which sits around waiting for the flag to occur. This represents the minimum resolution over which a user will have control, that is, sixteenth notes; if 24 ticks represents a quarter note, then six ticks represents a sixteenth note. every sixth tick, a function called workload is called. it was supposed to be a test of what sort of limits the system would have at various tempos. what it does is loops a certain number of times , and during each iteration, it also sends out a midi clock. once the loop has finished, a message stating that it had finished and which sixteenth note had just been completed is printed. it then goes back to wait on the flag. the idea is that, if the workload function is able to complete the given number of sends for each tick, and print out finished results consecutively without skipping a segment, then it is able to handle that many transmissions at that tempo. anyhow, i have found that the performance is horrible. i assume it is because i am lacking the requisite skills or concept to build a device of such complexity, or maybe just because my computer is pretty poor. I tend to doubt this, though, because i have used windows midi software at such high speeds without problems. what im trying to figure out is if there is a way to tighten all of these timing issues. is there a way to avoid using a timer interrupt, or to avoid calling the handler at such a high rate? is there a way to speed up port communications? is there a way to synchronize two timers, one at the very high rate of 102 ticks per second, and another at the considerably lower rate of 17 ticks per second, such that the slower is called every sixth tick of the faster? is there a way to do away with the faster timer alltgether .. anyhow, thanks for listening. joseph devlin