| Path: hjuxa!rutgers!apple!oxford
From: oxford@Apple.COM (Wil Oxford)
Newsgroups: rec.music.synth
Subject: NAMM gear review (long)
Keywords: NAMM, new stuff
Message-ID: <476@internal.Apple.COM>
Date: 25 Jan 89 01:42:45 GMT
Organization: Apple Computer Inc., Cupertino, CA
Lines: 284
I just got back from the Anaheim NAMM show and thought you netlanders out
there would like to know about a couple of the neater things I saw there
as well as an answer to your requests for MIDI support from our end....
[sections removed]
--- SOFTWARE ---
This was the show for all of the Mac software houses (I didn't see
anything much worth talking about on the other machines other than the
Atari, which I will get to later) to show new sequencer packages. There
were new sequencers from at least three different companies which were up
and running (very impressively) in Anaheim. But perhaps of most interest
to the rec.music.synth crowd was our (Apple's) first music software
product. The net will have to forgive me for blowing our own horn, but I
think we blew away the software side of the show with our announcement of
the MIDI management tools for the Macintosh. Several (I'm not sure if
legality will allow me to say who) prominent performers spent a large
amount of time hanging around our booth raving wildly about how great it
was to have Apple finally interested in the musical applications of their
machines, which was a great encouragement for those of us musicians in
the company who have been working for the last six months on musical
things. You can't imagine how difficult it has been to read the postings
from people like Mr. Lisper and not to be able to reply with something
like "...just hang in there for a few more months, we've been working on
the very thing you are asking about for four months now..." Well Bjorn
(and I hope I spelled it correctly), we have answered your requests with
a set of tools which not only will allow you to send MIDI data streams
from one application to another under MultiFinder transparently to the
application, BUT in addition, allows you to run the separate applications
simultaneously under MultiFinder AND also takes care of the really hairy
problem of how to make sure that the different applications all share a
common timing environment. And best of all, it's free.
The Macintosh MIDI tools are distributed as a set of files which include
an INIT and a serial port MIDI driver which go into your system folder
and a stand- alone application called "PatchBay" which can be anywhere on
your disk. The way it works is simple: A boot time, the MIDI manager
INIT gets loaded into memory. Any MIDI application which starts up
registers itself with the MIDI manger and lets it know how many data
input ports, data output ports, and whether it has timing input and/or
output ports. When you start up the application "Patchbay", you are
presented with a window in which you see the icons of all of the MIDI
apps which are currently "signed in" and small icon representations of
their input, output and timing ports. Connecting the output of one MIDI
application to the input of another is as simple as clicking on the
desired output icon and dragging a virtual wire (rubber-banded, of
course) to the desired input port. You can have as many output wires
coming out of a port as you want and if more than one MIDI output data
streams is connected to a single input, the data streams are correctly
merged. Connecting to the outside world (ie., the serial port) is
exactly the same as connecting to any MIDI application. In addition, all
non-standard MIDI messages (such as non-terminated system exclusives and
running status) are correctly expanded and terminated to give you good,
clean MIDI everywhere. MIDI timecodes (all versions) are supported as
well. "But," you say, "Suppose I want to run two sequencers at once,
with one that does tempo mapping feeding into another that doesn't
understand the concept; which then feeds into a module which thins out
continuous controller information." The answer to that is "So connect
them together and watch it work." If you take the time port output of one
module and wire it (just like the data port) to the time input ports of
all of the other modules, it will guarantee that all of the connected
applications remain in perfect sync. As a small added bonus, we also
make sure that nobody needs to worry about how their application gets
time-stamped data, since all data packets are time-stamped and everybody
gets timing information from the master clock. So now you don't have to
worry about MIDI applications stomping on the Sound Manager or
vice-versa. As of two days ago, most Mac developers had either started
porting their application over to the environment or was in the process
of getting on our beta release distribution list. We will be shipping
the final version of the tools in less than a month, so it's up to the
software consumers out there to hound the software houses to send out
their updates when they finish the port. Opcode and Resonate took one or
two days to port over beta versions of their latest patch-
editor/librarian and sequencer respectively. Oh well, end of story on
the MIDI Manager. I'm sorry if it got long, it's just that so many of
you had posted about this and it's been really tough to stay quiet about
it for so long. Oh yeah, we support everything from the Mac Plus on up
to the SE/30.
regards,
William V. Oxford, Ph.D.,
System Extension Sound Group,
Apple Computer, Inc.
|
| Article 2485 of comp.sys.mac.programmer:
Path: sousa!shlump.nac.dec.com!decuac!haven!rutgers!usc!apple!well!cbm
From: cbm@well.UUCP (Chris Muir)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MAC MIDI tools.
Keywords: MIDI
Message-ID: <13171@well.UUCP>
Date: 16 Aug 89 20:39:19 GMT
References: <2384@cbnewsc.ATT.COM> <89Aug14.190143edt.10865@ephemeral.ai.toronto.edu>
Reply-To: cbm@well.UUCP (Chris Muir)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 50
In message <89Aug14.190143edt.10865@ephemeral.ai.toronto.edu>
dudek@ai.toronto.edu (Gregory Dudek) writes:
> In lieu of actually getting the MIDI tools, I wonder if somebody
>with the information might want to give us some idea
>to what the details of using the package are like, for a programmers
>point of view. In particular, what kind of calls do you
>make to do the MIDI I/O? Is it easy to convert an existing MIDI
>application that uses a raw SCC interface to the new package?
I've just converted an application that was using the MacTutor (Kirk
Austin) MIDI drivers to run under the MidiManager. The hardest part
for me was that the MidiManager really wants to run at interrupt time,
and all my code assumed that I was going to be polling the driver from
my main event loop. This means that I had to play games to find my
globals and that I couldn't move memory, etc. This is all standard
driver/interrupt stuff, but I had never done it before. Basically the
calls to the MidiManager are pretty simple. A call to Initialize, a
call to "SignIn" your application, calls to add and subtract virtual
ports, calls to find out about other applications ports and connect
and connect to them, a call to write a packet, etc.
Data comes and goes in MIDIPackets:
MIDIPacket = packed record
flags: BYTE; { what type of packet }
len: BYTE; { length of packet including 6 byte header }
tStamp: LONGINT; { in local time }
data: packed array[0..250] of BYTE;
end;
MIDIPacketPtr = ^MIDIPacket;
When you add an input port you pass the address of a "readHook", which
is called at interrupt level when midi packets arrive. The MidiManager
only reports completed packets. It also "completes" any packets sent
with running status.
You may write data to output ports at interrupt time or from the main
event loop.
The MidiManager comes with source for a few simple applications, some
in Pascal, some in C.
I'd be glad to answer any questions, if I can.
--
_______________________________________________________________________________
Chris Muir | "There is no language in our lungs
{hplabs,pacbell,ucbvax,apple} | to tell the world just how we feel"
!well!cbm | - A. Partridge
|
| Article 9030 of comp.sys.mac.programmer
Path: shlump.nac.dec.com!decuac!haven!purdue!iuvax!silver!viking
From: viking@silver.bacs.indiana.edu (Jon W. Backstrom)
Newsgroups: rec.music.synth,comp.sys.mac.programmer
Subject: MIDI Management Tools...first impressions (long)
Keywords: MIDI Manager, impressions, bugs
Message-ID: <25132@iuvax.cs.indiana.edu>
Date: 29 Aug 89 08:23:44 GMT
Reply-To: viking@silver.bacs.indiana.edu (Jon W. Backstrom)
Followup-To: comp.sys.mac.programmer
Organization: Indiana University, Bloomington
Lines: 147
Xref: shlump.nac.dec.com rec.music.synth:9046 comp.sys.mac.programmer:9030
After playing with the MIDI Management Tools (version 1.1), I would
like to offer some initial impressions and pose a few questions about
the behavior of the "MIDI Manager", the "Apple MIDI Driver", and a few
of the demonstration programs.
Two files make up the core of the MIDI Management Tools: an INIT named
"MIDI Manager", containing the MIDI Manager code and the "Apple MIDI
Driver" file, containing interface code for the hardware itself. When
an application signs in, the MIDI Manager loads MIDI Drivers that are
present in the System Folder and disposes of them when the application
signs out.
The Patchbay
------------
An application called "Patchbay" is at the heart of using the MIDI
Manager. Everything runs under MultiFinder (ideally) and Patchbay is
used to configure the connections between software modules and the
MIDI input and output ports. (If you can't use MultiFinder, there is
a Patchbay DA that you can install.)
To actually *do* something, run "Patchbay" and then double-click on
the MIDI Driver icon. A dialog then appears that lets you set which
port(s) you want to use, the MIDI interface type (0.5 MHz, 1 MHz, and
2 MHz), the time code (none, beats, 24-25-30 fps, or 30 drop), and
whether you want to use time code output, filter the time code, or use
application sync. Finally, there is an "All Notes Off" button to
silence runaway MIDI sound modules.
(There seems to be a problem with "All Notes Off" button in the Apple
MIDI driver dialog, however...see below.)
There are four sample applications that are supplied with the MIDI
Management Tools: MIDIArp (an arpeggiator), HourGlass (a time code
stopwatch, of sorts), SquidCakes (a simple MIDI event recorder), and
SimpleKey (a monophonic software keyboard).
By launching one of these applications (with Patchbay active) an icon
will appear in the Patchbay, allowing the user to drag "patch cords"
connecting the software modules to the actual MIDI hardware I/O. To
use MIDIArp, for example, one would connect the MIDI IN to the input
of the software module and the MIDI OUT to the module's output. Then
simply hold some keys down on your keyboard and listen to things start
happening!
For added fun, you can then launch SimpleKey and patch the output to
the MIDIArp input, thereby *merging* the two inputs (one input from
the software tool -- a single note -- and the other being whatever
notes you are playing on your keyboard). You can also sync one module
to another using the clock icons. This is nifty stuff!
Patch settings can be saved, so if you do something fun like merge the
inputs from the MIDI IN and SimpleKey to the input of Squidcakes (a
simple MIDI event recorder), and then patch the output of Squidcakes
to MIDIArp, and *then* patch the output of MIDIArp to the MIDI OUT...
you can save the whole patch for future recall. (Who named these
applications, anyway?) :-)
One complaint I have about Patchbay is that when two modules are
connected straight across the bay, but at an angle, the connections
are visually crossed. For example:
(Please forgive the text approximations)
Straight across...no problems...
MIDI > ----------------------------------------- > MIDIArp
Driver < ----------------------------------------- <
Angled across...visual crossing of 'patchcords'...
MIDI > ------------------+ +-- < SimpleKey
Driver < ------------------|-+ (Merged /
| | Input) |
| | \
+-|-----------------+-- > MIDIArp
+-------------------- <
When you get a lot of merged inputs and cross-connections, it gets
harder to figure out what's going on. I would suggest that Apple
should use a non-crossing visualization scheme for showing patchcord
connections across the patchbay.
Angled across...*no* visual crossing of 'patchcords'...why not?
MIDI > --------------------+ +-- < SimpleKey
Driver < ------------------+ | (Merged /
| | Input) |
| | \
| +-----------------+-- > MIDIArp
+---------------------- <
Sample Applications
-------------------
There are lots of apologies for the quality of the sample applications
in the "About" information, and it's easy to see why. SimpleKey, for
example, has a few places on the keyboard where two keys will play the
same note. There's nothing really much you can say, however, since
these samples are meant to show possibilities...not to showcase the
best possible MIDI applications.
*Warnings!*
-----------
I was able to hang the system when I did MIDI input while accessing
the disk from another non-MIDI program. I was using a really complex
input/output configuration with several applications in the Patchbay.
(I was just testing the limits.)
Also, when made some abrupt exits from MIDI applications, I was
*unable* to use my modem port from a terminal program. By running
everything again and closing all applications nicely, I was able to
restore the operation of the modem port. (Strange stuff, but it seems
really important to close the MIDI Manager software properly.)
Finally, the "All Notes Off" button, from the MIDI Driver Settings
dialog (you get there by double-clicking the Driver icon in Patchbay),
seems to send an all notes off message (B0 7B 00), followed by 128
individual note off messages (80 nn 40 ... nn being 0-127), for *every
MIDI channel*! (1-16)
My Roland D-50 kept getting a "MIDI Communication Error" when I used
the All Notes Off button, until I turned it's OMNI mode off. You
might want to check the output from this command, but I think it's
bogus. I tried looping the MIDI OUT to MIDI in and using SquidCakes
to record the MIDI message being send, but I got strange results
(which I'm sure are due to the slowness of the application).
Does "All Notes Off" work? When I captured the MIDI events, I found that
sometimes the initial Notes Off message was missed and I got spurious
events at the end of each "burst". I wonder if this is what caused
the error for the D-50? Are 128 Note Off messages for *each* MIDI
channel *really* necessary, or is Apple trying to cover synths that
don't respond to an All Notes Off message (Bn 7B 00)?
My initial impression of the MIDI Management Tools is very favorable,
however, and I'm excited about the future!
-------------------------------------------------------------------------------
Jon W. Backstrom "Yah sure...we gonna have fun, you bet!"
Institute for Digital Arts
P.O. Box 176 Internet: viking@silver.bacs.indiana.edu
Bloomington, IN 47402-0176 UUCP: {ames,rutgers,att}!iuvax!silver!viking
-------------------------------------------------------------------------------
|