[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MIDI & MCL2.0b1
- To: djskrien@COLBY.EDU
- Subject: MIDI & MCL2.0b1
- From: Joe Chung <email@example.com>
- Date: Thu, 6 Jun 91 12:20:30 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: Dale J. Skrien's message of Thu, 6 Jun 91 08:58:00 -0400 <9106061258.AA08042@host0.COLBY.EDU>
Date: Thu, 6 Jun 91 08:58:00 -0400
From: djskrien@COLBY.EDU (Dale J. Skrien)
Dear Joe, Could you help us with the following problems? Or
is it more appropriate to send them to info-mcl or bug-mcl?
Thanks. Dale Skrien and Jon Hallstrom.
I have found two problems with MCL2.0b1 that I hope you can
help us with. Maybe these aren't bugs, but I can't figure
out any other way around them.
1. I need to use the MIDI Manager and so I load the MIDI.lisp
file from the Interfaces directory. However, the trap
call for snddispversion is commented out with the statement
that it is not in ROM. How does one access snddispversion
2. As the MIDI Manager documentation says, if I am to use
an input port, I need to create a readhook function to pass
to the input port as a pointer (as in #_midisetreadhook).
The readhook function is supposed to have the following form:
function readhook (buffer: midipacketptr;
refcon: longint): integer;
So I entered the following code in MCL2.0b1:
(defpascal my-readhook (:ptr buffer :long refcon :word)
which just ignores the data and returns the value 1 (or
$midiMorePacket). I then executed the command
(#_midisetreadhook *input-port-refun* my-readhook)
where *input-port-refun* was the refnum of my input port previously
created. Then I sent out a few midipackets from my output port
to my input port and promptly got a system bomb. Am I using
defpascal wrong or is there something else causing the system
Thanks for your help.
Dale Skrien email@example.com
1. MCL doesn't let you call traps that are not in the rom. I have some code
which does the right thing (I think). I'll send it to you!
2. Readhooks are complicated. Since they are callbacks at the
interrupt level, you can't defpascal them, thus your crahses. Doing
your readhook in LIsp is probably a bad idea since a readhook typically
does something small like copying the data from the packet & returning.
The best thing to do is to write your readhook in LAP (Lisp assembly).
I've done a fairly complete implementation of all of this stuff, but
have been a bit too busy to make it distributable. I'm not so busy
now, so I'll try to get it out in a few days. I'll let people know
where they can find it!
- Joe Chung