![[The MFP-03 MIDI Filer]](filer.jpg)
(This is an abstract of my paper „A Method for Playback of MIDI Files with Minimal Waste of Memory and Minimal Initial Delay“, presented on the Anniversary Scientific Session at Air Force Academy „G. Benkovski“, Dolna Mitropolia, May ’96)
This method applies to standard microcomputer architecture — IBM® PC/AT™ and MS-DOS® operating system. Four interrupts are used: time interrupt, received data interrupt and transmit data interrupts for each of the two MIDI output ports. Four FIFO queues are utilised: playback event queue, input event queue and two output port data queues.
Each track of the MIDI file is copied as a separate file onto a virtual (RAM) disk. Then, delta-times of the next events from each track are compared. The event with minimal delta-time is enqueued for playback. This repeats until the playback event queue fills up or all tracks end. In the latter case, the playback is finished.
The input MIDI port generates received data interrupts. Received data are grouped together into events, which are enqueued onto the input event queue.
Upon timer interrupt, a check is made whether it’s time to playback the next event from the playback event queue, and if so, its data are enqueued onto the appropriate output port data queue. The played events are merged with the events from the input event queue.
When the MIDI port ACIA is ready to transmit, it generates an interrupt, upon which the waiting data from the output data queue are transmitted through the output MIDI port. The transmit data interrupt allows for the main playback function to enqueue more data instead of waiting 0.32 ms for each byte to be transmitted. Thus, the playback event queue is never empty before the actual end of the song, which ensures smooth playback without „stuttering“.
Thus, to playback a file, memory is wasted only for file buffers (512 bytes per track), and for the queues (11.4 KB more). The size of the played file is limited only by the size of the virtual (RAM) disk used for track storage. No additional memory is wasted to form linked lists of events, pointers to measures etc, as is the case with „normal“ sequencers.
The pause between songs is equal to the time necessary to copy all tracks to the virtual disk (about 0.8 s per disk track), plus the time needed to initially fill up the playback event queue (about 1 s). This equals to about 3.5 s per average MIDI file. The method permits using of standard high-level library functions for buffered file access, (for instance, getc for the C language).
Using several synchronisation levels of pseudo-parallel processes allows for a high degree of computing power utilisation.
A schematic representation of this playback method is shown below:
Timer interrupt Transmit data interrupt
| |
Main program --> Playback event queue --> | --> Data queue --> | Port 0
|
|
MIDI input--> | --> Input event queue --> | --> Data queue --> | Port 1
| |
Received data interrupt Transmit data interrupt
This paper was reported on October 10 at the annual „Telecom’97“ conference, International House of Scientists, St. Constantine (Drouzhba) resort, near Varna. The main points from it are outlined below:
As mentioned in the project description, the filer is capable of recovering the tempo map when recording with external MIDI clock synchronisation. This is something I’ve missed in all commercial sequencers, both computer programs and dedicated devices. The main working principles follow.
When the received data interrupt handler gets a MIDI clock message, its delay from the previous one is measured using the Programmable Interval Timer (8254) counter 2 (the one that normally controls the PC speaker). The measuring accuracy is about 1 µs. The system timer (counter 0), which drives the timer interrupt line (IRQ 0), is then initialised to a countdown value 5 times smaller than the measured interval (120 ticks / 24 MIDI clocks per beat = 5). This is the fine adjustment, and in fact behaves much like an AFC (Automatic Frequency Control).
If there are more or less than 5 system timer ticks elapsed since the last MIDI clock, the tick count is decremented or incremented during the next timer interrupt. This is the rough adjustment, and is similar to an APC (Automatic Phase Control).
Since most sequencers and players don’t actually insert MIDI clock messages in the middle of others, as the MIDI specification permits, there are always a number of „fake“ MIDI clock bytes after most longer System Exclusive messages. To avoid errors, adjustments are disabled until all of the „fake“ clock messages are received.
During the measurement of the interval between MIDI clock messages, it is averaged down to the time signature denominator (most often a quarter or eighth note). This average value is sent to the main recording function, which compares it with the current value. If the difference is greater than a threshold (usually 2%), a new Tempo event is placed at the time of the last change, using the last value. Tests show that if a piece has constant tempo, only one Tempo event is then created.
This method preserves all the timing information with musical meaning: both the real starting positions and durations of notes through the measure, and the tempo changes during the performance. Thus, it combines the advantages of both MIDI clock and MIDI Time Code synchronisation (except that is still can’t be used for tape recorders). The only musical information lost during recording are time signature changes, but the Time Signature Universal Real-Time System Exclusive Message (defined 1991) is still very rarely implemented so we can’t rely on it.
Now, the so-called „synchronised over-play“ could be used to transfer songs from devices which don’t support Standard MIDI Files or don’t use floppy disks at all much more successfully than ever before!
Copyright © 1998-2001 Luchezar Iliev Georgiev. All Rights Reserved.