MIDI & MCL2.0b1

[Joe Chung <joe@media-lab.media.mit.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
      from MCL2.0b1?

   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)
		 1)

      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
      error?

   Thanks for your help.

   Dale Skrien   djskrien@colby.edu


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