oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/25/88)
Sigh, Inside Mac Vol. 5 documents the new sound manager. This includes a section on the MIDI pipeline. It allows for very sophisticated sharing of the MIDI port. Not only can multiple programs transmit different messages without collisions, then can also set up to listen to different messages, or listen to the same messages, or even filter or transform messages before other programs see them. This new code is present in all macintoshes running any version of the system software later than version 5 (i.e., newer than a year old.) The documentation in Inside Mac Vol 5. is sketchy, and for the moment, only the "modem" port (port A) is handled. We need to lobby our developers to use it, and if it is buggy, lobby Apple to fix it, since it is much closer to what we want than what we have been using.
czei@neutron.eng.ohio-state.edu (Michael S. Czeiszperger) (12/28/88)
In article <27248@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >We need to lobby our developers to use it, and if it is buggy, lobby Apple >to fix it, since it is much closer to what we want than what we have been >using. I've never tried to use the routines, but the are reputed not to work. My source is an Apple employee on the Performing Arts Network's Midi Development Forum, so I'm pretty sure this is an accurate assessment. I've also communicated with David Ziccarelli on the MIDI forum, and he said after a year of work on OvalTunes, he still has no idea how the Sound Manager is supposed to work! It sounds like the Sound Manager + MIDI won't be up to stuff until system 7.0 or beyond. -=- Michael S. Czeiszperger | "milihelen: The amount of beauty required to launch Systems Analyst | a single ship." The Ohio State University | 2015 Neil Ave, Columbus, OH 43210 ARPA:czei@icarus.eng.ohio-state.edu PAN:CZEI (614) 292-0161
rich@sendai.ann-arbor.mi.us (K. Richard Magill) (01/07/89)
In article <27248@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Sigh, Inside Mac Vol. 5 documents the new sound manager. This includes a >section on the MIDI pipeline. It allows for very sophisticated sharing of >the MIDI port. Show me where. All I see is a coupla pieces to fit into the sound manager pipeline to translate MIDI to sound manager and vice verse. Nothing about reading from a port. >The documentation in Inside Mac Vol 5. is sketchy, and for the moment, >only the "modem" port (port A) is handled. I agree that it's sketchy. I don't see anything about ports. Can you give me a reference? T-173 and V-475 imply this, but V-496 - 500 strongly imply that these pieces can only translate, NOT actually transmit. DISCLAIMER: I haven't actually played with the damn thing as the documentation implies to me that I must write my own drivers. -- rich.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/08/89)
Time for me to apologize. The new sound manager documentation I just recieved from Apple says that the current midi drivers built in to the current sound manager mostly provide a way to translate sound calls by Mac programs to play out the MIDI port. It specifically says that using these drivers to do input from a keyboard is probably a waste of time because they aren't good enough yet. There are MIDI drives in the current System File, it is just that they are so primitive that Apple doesn't want to talk about them much. I still think the architecture is a good ones: pipelines of filter procedures that communicate by passing messages, actually pascal records, from one to the next, and routines to insert and remove pipeline stages. It seems like this structure would be good for getting, say, editr/librarians and sequencers, and the Mac's sound output itself, all going under MIDI in a unified environment. Unfortunately, it isn't here yet.
beard@ux1.lbl.gov (Patrick C Beard) (01/09/89)
In article <27412@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: > >I still think the architecture is a good ones: pipelines of filter >procedures that communicate by passing messages, actually pascal records, >from one to the next, and routines to insert and remove pipeline stages. >It seems like this structure would be good for getting, say, >editr/librarians and sequencers ... I agree and how about the same for a voice synthesizer like MacinTalk? Wouldn't it be nice if there were support for that in the sound manager? Then one could truly mix speech, sound, and music. Just a thought. Patrick Beard Lawrence Berkeley Laboratory
nick@lfcs.ed.ac.uk (Nick Rothwell) (01/09/89)
In article <27412@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Time for me to apologize. The new sound manager documentation I just >recieved from Apple says that the current midi drivers built in to the >current sound manager mostly provide a way to translate sound calls by >Mac programs to play out the MIDI port. It specifically says that >using these drivers to do input from a keyboard is probably a waste of >time because they aren't good enough yet. Shame. I really do wish that Apple would get their act together Re: MIDI, before the dreadful Atari ST takes over the entire MIDI/Studio world (too late here in the UK, by the way...). David, you mentioned "pressuring" MIDI software developers to conform to the correct MIDI driving routines (before realising that there aren't any..). One very important guideline which makes things much more bearable is this: If you're sent to the background by MultiFinder, relinquish and reset the serial ports. I know that the Kurzweil MIDIscope does this. Perhaps Performer does as well, I will investigate. This at least allows several MIDI applications to be switched between, without things going seriously nonfunctional. As an aside: how do I do this myself? I've been programming MIDI applications in LSC, completely oblivious to MultiFinder (aware-bits = 0x0000). How do I make my application MultiFinder-aware? Do I have to pay out mucho-$$$ to Apple for the MultiFinder developer's kit? Anybody got a few old bus tickets with the details (events, etc.) scribbled down? Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
miller@ACORN.CS.ROCHESTER.EDU (01/12/89)
From: Brad Miller <miller@CS.ROCHESTER.EDU> Date: 9 Jan 89 13:49:45 GMT From: nick@lfcs.ed.ac.uk (Nick Rothwell) David, you mentioned "pressuring" MIDI software developers to conform to the correct MIDI driving routines (before realising that there aren't any..). One very important guideline which makes things much more bearable is this: If you're sent to the background by MultiFinder, relinquish and reset the serial ports. I know that the Kurzweil MIDIscope does this. Perhaps Performer does as well, I will investigate. This at least allows several MIDI applications to be switched between, without things going seriously nonfunctional. 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}
beard@ux1.lbl.gov (Patrick C Beard) (01/12/89)
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
miller@ACORN.CS.ROCHESTER.EDU (01/13/89)
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}