Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!xanth!nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!rpi!sun.soe.clarkson.edu!batcomputer!cornell!rochester!daemon
From: miller@ACORN.CS.ROCHESTER.EDU
Newsgroups: comp.sys.mac.programmer
Subject: Re: Wish-List: Decent MIDI support for the Macintosh
Message-ID: <1989Jan12.200513.24156@cs.rochester.edu>
Date: 13 Jan 89 01:05:13 GMT
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 36

From: Brad Miller <miller@CS.ROCHESTER.EDU>

    Date: 12 Jan 89 05:06:26 GMT
    From: beard@ux1.lbl.gov (Patrick C Beard)


    In article <1989Jan11.124632.27532@cs.rochester.edu> miller@ACORN.CS.ROCHESTER.EDU writes:
    >
    >But of course, what you REALLY want is to allow >1 application to
    >simultaneously access the MIDI bus, eh? I know I'd like to generate MIDI
    >events with one program in the background that Performer can capture while
    >running in the foreground, or vice-versa. Right now, it requires >1 mac!
    >----
    >Brad Miller		U. Rochester Comp Sci Dept.
    >miller@cs.rochester.edu {...allegra!rochester!miller}

    The obvious solution:  two MIDI interfaces, one connected to the printer
    port, one connected to the modem port.  One application services one, and
    the other application the other.  For example, for one application, 
    a sequencer let's say, to record the output of the other, an algorithmic
    composing machine, just connect a MIDI out from one interface to the MIDI
    in of the other.  That way everything works quite nicely under MultiFinder.

    Patrick Beard
    Berkeley Systems, Berkeley CA

Alas, some of us already use both ports to service our existing MIDI setup;
we need our 32 channels! (or, at least, 2 active keyboards providing
simultaneous input).

Also >1 doesn't mean =2, so you are still stuck when that third progam comes
along.

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}