Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!gatech!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.music
Subject: Re: Need help With MIDI interface S/W Ideas.
Keywords: Keyboard to IBM via MIDI.
Message-ID: <287@bbxsda.UUCP>
Date: 23 Oct 89 18:05:47 GMT
References: <2211@servax0.essex.ac.uk>
Reply-To: scott@bbxsda.UUCP (Scott Amspoker)
Organization: Basis International,  Albuquerque, NM
Lines: 54

In article <2211@servax0.essex.ac.uk> chena1@ese.UUCP (Chengodan A) writes:
>Hi,
>	I have got more problems to solve with MIDI.
>I'm trying to interface an IBM-AT with a keyboard
>via MIDI. Now I`m not sure the actual DATA structure 
>I need to use on READING THE MIDI MESSAGES; especially
>the timing information of each MIDI MESSAGES 
>[...]

Here are a couple of suggestions based on what I have done
with my own software:

Use one of the programmable interval timers on your PC.  They
can be set to interrupt at ranges from 2 microseconds to 
many milliseconds.  Make your timer interrupt handle increment
a tick counter in memory.  This will be your "clock".  I use
a Yamaha C1 which has an additional timer just for music
applications.

Your midi receive interrupt handler should remember the current
clock upon receiving a status byte (or implied running status).
When the entire midi message had been recieved it is then
stuffed (along with the clock value) into a quick and dirty
circular queue (don't spend too much time in the interrupt routine).
A higher level routine may retrieve these time-stamped messages at
its leasure and place them into a more complex and permanent data
structure.  (Be sure to disable interrupts when setting/retrieving
the clock value as well as when accessing the circular queue).
My recieve interrupt handler is also responsible for echoing
incoming MIDI messages to the appropriate output port.

There are several ways to handle playback of MIDI data.  It depends
on how you chose to represent your "tracks" in memory.  If absolute
timing accuracy is important (as it is for me) than you can prepare
a "dispatch" queue containing data indicating time delays between the
MIDI messages.  Your clock tick interrupt may then take the
responsibility of dispatching the data precisely on schedule (including
the timely dispatch of MIDI sync messages).  Once again, keep it
simple.  Don't spend too much time in an interrupt handler.  Your
higher level logic can take all the time it wants preparing output
data, updating the screen, etc. as long as it doesn't allow the dispatch
queue to become empty.  The actual MIDI output ports are also
interrupt driven.  If the port is busy then place output data
in a queue so that the output interrupt handler can take care of it
when it's ready.

This is a rather oversimplified description of one of *many* ways
of doing things.  I hope it gave you some ideas.

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott