Mail Archives: djgpp/1997/01/26/17:52:20
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 <this number is entered at run-time>, 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 <although i tend to
doubt it>..
anyhow, thanks for listening.
joseph devlin
- Raw text -