Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga
Subject: Re: Multiple Serial Ports (Re: vt100 v2.9)
Message-ID: <7161@batcomputer.tn.cornell.edu>
Date: 11 Jan 89 15:50:15 GMT
References: <8812150227.AA09671@postgres.Berkeley.EDU> <14049@oberon.USC.EDU> <147@ziggy.UUCP> <3256@sugar.uu.net> <149@ziggy.UUCP>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 29

In article <149@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes:
>In article <3256@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes:
[...]
>>Plus, I still need MIDI and my stuff is already ready for it from a dumb 
>>port -- the default in the machine is one, after all, and the smart board
>>will probably need a precision clock and internal specific intelligence
>>for MIDI -- sort of like a multiport version of the Roland MPU-401.  The
>>trouble is, too, it's more expensive plus the programming model is totally
>>different.

>that's a good point about midi timing.  it would be relatively easy to add
>a mode to the board which caused it to recognize blobs of midi stuff and
>append a timestamp to them.

That still leaves the problem that the programming model is different.
More serial ports for MIDI won't do much good if no programs support
them.  And no programs will support them if every serial port behaves
differently.

I would really like to see some of this hidden by the device driver.  If
we had a serial.device with a MIDI mode, which would timestamp incoming
events (and possibly send out events on a schedule), then manufacturers
of add-on serial ports could reproduce this functionality in their device
drivers using whatever hardware capabilities their board has.  And MIDI
software writers would have a standard device that did all the things
they need.

-Dan Riley (dsr@lns61.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell U.