Music has become cheap and plentiful on the Macintosh, and many applications are now making "casual" use of music. With the QuickTime Music Architecture, or QTMA, including music in your application has never been simpler. Its API is straightforward and easy to use, and you don't need intimate knowledge of MIDI protocols or channel and voice numberings. Nor do you need an external MIDI device; QTMA can play music directly out of the Macintosh's built-in speakers. And QTMA is widely available -- it's on every Macintosh that has QuickTime 2.0 (or later) installed.
The QuickTime Music Architecture is perfect for adding a little bit of music to your application. It has a set of well-supported high-level calls for playing musical notes and sequences, it deals with MIDI protocols so that your application doesn't have to, and it handles timing for entire tunes. With QTMA, you can specify musical instruments independent of device, and play music either directly out of built-in speakers or through a MIDI synthesizer.
QTMA first became available with QuickTime 2.0 and offers some new features in QuickTime 2.1, which should be available through APDA by the time you read this. The code in this article is written for version 2.1; minor changes will be required for 2.0. (Before making use of the QuickTime 2.1 features, your code should call Gestalt with the gestaltQuickTimeVersion selector and check the version number returned.)
This article shows how your application can use QTMA to play individual notes, sequences of notes composed on the fly, or prescored sequences, and how to read input from external MIDI devices. This issue's CD contains all the sample code and a THINK C project to build and run it. We'll start with a look at QTMA in relation to other ways of supporting music on the Macintosh; then we'll get down to business and play some music with QTMA.
Writing a serial driver to send MIDI output to an Apple MIDI adapter or to any third-party MIDI adapter isn't that complicated if you enjoy writing low-level code to access hardware registers on the SCC serial chip. I say this in all seriousness: that kind of code really is fun to write! But it's not the best way to do things, because changes in the OS and hardware can render your work useless. And writing the low-level serial code for MIDI input has additional complexities, primarily because of the interrupt timings in many parts of the Mac OS.
The MIDI Manager is a slightly better tool to use for MIDI input and output. Unfortunately, Apple's support for this product has been less than consistent, and the MIDI Manager itself has some inherent performance limitations, though these are less critical on faster hardware (68030 processor or better).
Both OMS and FMS are quite appropriate for professional music scoring and editing products. Among the facilities that these extensions provide is a "studio configuration"; this lets the user describe to the system the various MIDI devices attached to the computer so that different applications can access them.
All of these options have drawbacks for making casual use of music: you have to access an external MIDI device, which most users don't have, and you have to use MIDI protocols to talk to that device. QTMA frees you from both of these constraints. It also frees you from needing to know a lot about MIDI itself; if you want to know anyway, check out the information in "A MIDI Primer."
Because MIDI cables can carry signals in only one direction, synthesizers have separate connectors for MIDI input and MIDI output. (This differs from modem cables, which carry signals in both directions.)
MIDI is a serial protocol running at 31250 baud, 8 data bits, 1 stop bit, no parity. The command structure for a MIDI stream is simple: each byte is either a status byte or a data byte.
A status byte establishes a mode for interpreting the data bytes that follow it. The high bit is set, and the next three bits indicate the type of status byte. The low four bits are typically used to specify a MIDI channel. Thus MIDI can address up to 16 unique channels, each of which may play a different musical instrument sound. Later extensions to MIDI let you address more channels through the use of escape codes and bank switching.
The most common status message is the Play Note message, which has a value of 0x90 plus the MIDI channel number. Each note is defined by a pitch and velocity. The pitch is an integer from 0 to 127, where 60 is musical middle C (61 is C sharp, 59 is B, 72 is the C above middle C, and so on). The velocity is an integer from 0 to 127 that describes how loud to play the note; 64 is average loudness, 127 is very loud, 1 is nearly inaudible, and 0 means to stop playing the note.
So, to play a C-major chord on MIDI channel 0, you send the seven bytes 0x90 0x3C 0x40 0x40 0x40 0x43 0x40 to begin the sound. After a suitable interval, you send 0x90 0x3C 0x00 0x40 0x00 0x43 0x00 to silence it.
All of this is exactly the sort of stuff you don't need to know if you use the QuickTime Music Architecture for your music-playing needs. But you just can't know too many useless facts, right?
Listing 1. Note-related data structures
struct NoteRequest { NoteRequestInfo info; // * in post-QuickTime 2.0 only ToneDescription tone; }; struct NoteRequestInfo { UInt8 flags; UInt8 reserved; short polyphony; Fixed typicalPolyphony; }; struct ToneDescription { OSType synthesizerType; Str31 synthesizerName; Str31 instrumentName; long instrumentNumber; long gmNumber; };The next two fields specify the probable polyphony that the note channel will be used for. Polyphony means, literally, many sounds. A polyphony of 5 means that five notes can be playing simultaneously. The polyphony field enables QTMA to make sure that the allocated note channel can play all the notes you'll need. The typicalPolyphony field is a fixed-point number that should be set to the average number of voices the note channel will play; it may be whole or fractional. Some music components use this field to adjust the mixing level for a good volume.
The ToneDescription structure is used throughout QTMA to specify a musical instrument sound in a device-independent fashion. This structure's synthesizerType and synthesizerName fields can request a particular synthesizer to play notes on. Usually, they're set to 0, meaning "choose the best General MIDI synthesizer." The gmNumber field indicates the General MIDI (GM) instrument or drum kit sound, which may be any of 135 such sounds that are supported by many synthesizer manufacturers. (All these sounds are available on a General MIDI Sound Module.) The GM instruments are numbered 1 through 128, and the seven drum kits are numbered 16385 and higher. A complete list of instrument and drum kit numbers is provided in Table 1. For synthesizers that accept sounds outside the GM library, you can use the instrumentName and instrumentNumber fields to specify some other sound.
Listing 2. Playing notes with the note allocator component
void PlaySomeNotes(void) { NoteAllocator na; NoteChannel nc; NoteRequest nr; ComponentResult thisError; long t, i; na = 0; nc = 0; // * Open up the note allocator. na = OpenDefaultComponent(kNoteAllocatorType, 0); if (!na) goto goHome; // * Fill out a NoteRequest using NAStuffToneDescription to help, // * and allocate a NoteChannel. nr.info.flags = 0; nr.info.reserved = 0; nr.info.polyphony = 2; // simultaneous tones nr.info.typicalPolyphony = 0x00010000; // usually just one note thisError = NAStuffToneDescription(na, 1, &nr.tone); // 1 is piano thisError = NANewNoteChannel(na, &nr, &nc); if (thisError || !nc) goto goHome; // If we've gotten this far, OK to play some musical notes. // Lovely. NAPlayNote(na, nc, 60, 80); // middle C at velocity 80 Delay(40, &t); // delay 2/3 of a second NAPlayNote(na, nc, 60, 0); // middle C at velocity 0: end note Delay(40, &t); // delay 2/3 of a second // * Obligatory do-loop of rising tones for (i = 60; i <= 84; i++) { NAPlayNote(na, nc, i, 80); // pitch i at velocity 80 NAPlayNote(na, nc, i+7, 80); // pitch i+7 (musical fifth) at // velocity 80 Delay(10, &t); // delay 1/6 of a second NAPlayNote(na, nc, i, 0); // pitch i at velocity 0: end note NAPlayNote(na, nc, i+7, 0); // pitch i+7 at velocity 0: // end note } goHome: if (nc) NADisposeNoteChannel(na, nc); if (na) CloseComponent(na); }
i = 0; while (!Button()) { long j, v; for (j = i % 13; j < 128; j+=13) { v = j < 64 ? j * 2 : (127 - j) * 2; NAPlayNote(na, nc, j, v); } Delay(13, &t); for (j = i % 13; j < 128; j+=13) NAPlayNote(na, nc, j, 0); i++; }This snappy little melody was discovered by psychologist Roger Shepard in the 1960s.
After allocating the note channel with NANewNoteChannel, we call NAPlayNote to play each note. Notice the last two parameters to NAPlayNote:
ComponentResult NAPlayNote(NoteAllocator na, NoteChannel nc, long pitch, long velocity);The value of the pitch parameter is an integer from 1 to 127, where 60 is middle C, 61 is C sharp, and 59 is C flat, or B. Similarly, 69 is concert A, and is played at a nominal audio frequency of 440 Hz. The velocity parameter's value is also an integer from 1 to 127, or 0. A velocity of 1 corresponds to just barely touching the musical keyboard, and 127 indicates that the key was struck as hard as possible. Different velocities produce tones of different volumes from the synthesizer. A velocity of 0 means the key was released; the note stops or fades out, as appropriate to the kind of sound being played. Here we stop the notes after delaying an appropriate amount of time with a call to the Delay routine.
Finally, being well behaved, we dispose of the note channel and close the note allocator component.
Listing 3. Using the instrument picker
void PickThenPlaySomeNotes(void) { ... // * declarations and initialization // * Open up the note allocator. ... // * Fill out a NoteRequest using NAStuffToneDescription to help, // * call NAPickInstrument, and allocate a NoteChannel. nr.info.flags = 0; nr.info.reserved = 0; nr.info.polyphony = 2; // * simultaneous tones nr.info.typicalPolyphony = 0x00010000; thisError = NAStuffToneDescription(na, 1, &nr.tone); // 1 is piano thisError = NAPickInstrument(na, nil, "\pPick An Instrument:", &nr.tone, 0, 0, nil, nil); if (thisError) goto goHome; thisError = NANewNoteChannel(na, &nr, &nc); if (thisError || !nc) goto goHome; // Play some musical notes. ... // Obligatory do-loop of rising tones ... goHome: ... // Dispose of the NoteChannel and close the component. }
As we've already seen, the NAPlayNote routine has parameters for specifying pitch and velocity, the latter determining the volume of the note; changes in these parameter values can affect the expressiveness of your music. You can also add expressiveness to whatever notes are being played by using QTMA's controllers. A controller is a parameter that's set independently of the notes being played, with a call to the NASetController routine:
ComponentResult NASetController(NoteAllocator na, NoteChannel nc, long controllerNumber, long controllerValue);Two simple controllers are the pitch bend controller and the volume controller. The pitch bend controller alters the frequency of any notes being played. It's like the whammy-bar on an electric guitar, which tightens or loosens all the strings simultaneously. The volume controller affects the sound of all notes similarly to the way key velocity affects the sound of individual notes.
Let's look at some source code that uses the pitch bend controller (Listing 4). This routine plays a major-fifth interval for a half second, "bends" it up by three semitones, holds it a half second, and then bends it back down to its original pitch.
Listing 4. Using the pitch bend controller
void PlaySomeBentNotes(void) { ... // declarations and initialization // Open up the note allocator. ... // Fill out a NoteRequest using NAStuffToneDescription to help, and // allocate a NoteChannel. ... // If we've gotten this far, OK to play some musical notes. Lovely. NAPlayNote(na, nc, 60, 80); // middle C at velocity 80 NAPlayNote(na, nc, 67, 60); // G at velocity 60 Delay(30, &t); // Loop through differing pitch bendings. for (i = 0; i <= 0x0300; i+=10) { // bend 3 semitones NASetController(na, nc, kControllerPitchBend, i); Delay(1, &t); } Delay(30, &t); for (i = 0x0300; i >= 0; i-=10) { // bend back to normal NASetController(na, nc, kControllerPitchBend, i); Delay(1, &t); } Delay(30, &t); NAPlayNote(na, nc, 60, 0); // middle C off NAPlayNote(na, nc, 67, 0); // G off goHome: ... // Dispose of the NoteChannel and close the component. }Most QuickTime controller values are 16-bit signed fixed-point numbers (where the lower eight bits are fractional) and have a range of 0 to 127, with a default value of 0. However, the pitch bend controller has a range of -127 to 127, and the volume controller has a default value of 127, or maximum volume.
The pan controller has a slightly different definition from the other controllers. "Pan" refers to the position of the sound in the stereo field. Most synthesizers have audio output for left and right; on such synthesizers, the pan value is interpreted as follows: The default pan position (usually centered) is specified by a value of 0 to the pan controller. To position the sound arbitrarily, values between 1 (0x0100) and 2 (0x0200) are used to range between left and right, respectively. For synthesizers with n outputs, values between 1 and n are used to pan between each adjacent pair of outputs. Note that the built-in synthesizer doesn't currently support panning.
In the tune header, each note request event has the structure shown in Figure 2. (It's actually a general event, of the note request subtype.) Thus the first word is 0xFnnn0017, where nnn is the part number, and the last word is 0xC0010017. The part number is referred to later on by note events in the tune sequence. For example, given a header than contains a note request event specifying part 3, subsequent note events that specify part 3 will play in a note channel allocated according to that NoteRequest.
_StuffGeneralEvent(w1, w2, part, subtype, length);The _StuffGeneralEvent macro fills in the head and tail long words of a particular type of general event -- in our case, a note request event. Its arguments are, in order: the head and tail long words; the part number; the event subtype (kGeneralEventNoteRequest for a note request event); and the length in long words of the entire event, counting the head and tail. Note that the first two arguments are the head and tail themselves, not pointers -- the macro expands to a direct assignment of these arguments.
Listing 5. BuildTuneHeader
#define kNoteRequestHeaderEventLength \ (sizeof(NoteRequest) /sizeof(long) + 2) // long words #define our_header_length \ ((2 * kNoteRequestHeaderEventLength + 1)) * sizeof(long) // bytes unsigned long *BuildTuneHeader(void) { unsigned long *header, *w, *w2; NoteRequest *nr; NoteAllocator na; // just for the NAStuffToneDescription call ComponentResult thisError; header = 0; na = 0; // Open up the note allocator. na = OpenDefaultComponent(kNoteAllocatorType, 0); if (!na) goto goHome; // Allocate space for the tune header, rather inflexibly. header = (unsigned long *) NewPtrClear(our_header_length); if (!header) goto goHome; w = header; // Stuff request for piano polyphony 4. w2 = w + kNoteRequestHeaderEventLength - 1; // last long word of // note request event _StuffGeneralEvent(*w, *w2, 1, kGeneralEventNoteRequest, kNoteRequestHeaderEventLength); nr = (NoteRequest *)(w + 1); nr->info.flags = 0; nr->info.reserved = 0; nr->info.polyphony = 4; // simultaneous tones nr->info.typicalPolyphony = 0x00010000; // 1 is piano thisError = NAStuffToneDescription(na, 1, &nr->tone); w += kNoteRequestHeaderEventLength; // Stuff request for violin polyphony 3. w2 = w + kNoteRequestHeaderEventLength - 1; // last long word of // note request event _StuffGeneralEvent(*w, *w2, 2, kGeneralEventNoteRequest, kNoteRequestHeaderEventLength); nr = (NoteRequest *)(w + 1); nr->info.flags = 0; nr->info.reserved = 0; nr->info.polyphony = 3; // simultaneous tones nr->info.typicalPolyphony = 0x00010000; // violin thisError = NAStuffToneDescription(na, 41, &nr->tone); w += kNoteRequestHeaderEventLength; *w++ = 0x60000000; // end-of-sequence marker goHome: if (na) CloseComponent(na); return header; }BuildTuneSequence (Listing 6) uses the _StuffNoteEvent and _StuffRestEvent macros.
_StuffNoteEvent(w, part, pitch, volume, duration);The _StuffNoteEvent macro fills in a note event. Its arguments are, in order: the long word to stuff; the part number; the pitch (where, as usual, 60 is middle C); the volume (velocity); and the duration (usually specified in 600ths of a second). The pitch must be between 32 and 95, and the part number must be less than 32. For values outside these ranges, a fixed-point pitch value, or a very long duration, use _StuffXNoteEvent.
_StuffXNoteEvent(w1, w2, part, pitch, volume, duration);The _StuffXNoteEvent macro is for extended note events. It's identical to _StuffNoteEvent except that it provides larger ranges for pitch, part, and duration, and the event itself takes two long words.
_StuffRestEvent(w, restDuration);The _StuffRestEvent macro fills in a rest event. It takes two arguments: the long word to stuff and the duration of the rest.
Listing 6. BuildTuneSequence
#define kNoteDuration 240 // in 600ths of a second #define kRestDuration 300 // in 600ths -- tempo will be 120 bpm #define our_sequence_length (22 * sizeof(long)) // bytes #define our_sequence_duration (9 * kRestDuration) // 600ths unsigned long *BuildTuneSequence(void) { unsigned long *sequence, *w; // Allocate space for the tune sequence, rather inflexibly. sequence = (unsigned long *) NewPtrClear(our_sequence_length); if (!sequence) goto goHome; w = sequence; _StuffNoteEvent(*w++, 1, 60, 100, kNoteDuration); // piano C _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 2, 60, 100, kNoteDuration); // violin C _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 1, 63, 100, kNoteDuration); // piano _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 2, 64, 100, kNoteDuration); // violin _StuffRestEvent(*w++, kRestDuration); // Make the 5th and 6th notes much softer, just for fun. _StuffNoteEvent(*w++, 1, 67, 60, kNoteDuration); // piano _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 2, 66, 60, kNoteDuration); // violin _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 1, 72, 100, kNoteDuration); // piano _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 2, 73, 100, kNoteDuration); // violin _StuffRestEvent(*w++, kRestDuration); _StuffNoteEvent(*w++, 1, 60, 100, kNoteDuration); // piano _StuffNoteEvent(*w++, 1, 67, 100, kNoteDuration); // piano _StuffNoteEvent(*w++, 2, 63, 100, kNoteDuration); // violin _StuffNoteEvent(*w++, 2, 72, 100, kNoteDuration); // violin _StuffRestEvent(*w++, kRestDuration); *w++ = 0x60000000; // end-of-sequence marker goHome: return sequence; }It's important to understand that the duration of a sequence equals the total durations of all the rest events. The durations within the note events don't contribute to the duration of the sequence! If two note events occur in a row, each with a duration of say 100, they'll both start at the same time, not 100 time units apart. If the next event is an end-of-sequence marker, the notes will immediately be stopped, having played for zero time units. If, however, a rest event is placed between the note events and the end marker, both notes will sound for the duration of the rest event, up to 100 time units.
Using the tune player to play a tune without application intervention is straightforward, as illustrated in Listing 7. After building the tune with BuildTuneHeader and BuildTuneSequence, this routine opens up a connection to the tune player component, calls TuneSetHeader with a pointer to the header information, and then calls TuneQueue with a pointer to the sequence data. All the details of playback are taken care of by the tune player. The tune will stop playing when it reaches the end or when the tune player component is closed.
Listing 7. Playing a tune with the tune player component
void BuildSequenceAndPlay(void) { unsigned long *header, *sequence; TunePlayer tp; TuneStatus ts; ComponentResult thisError; tp = 0; header = BuildTuneHeader(); sequence = BuildTuneSequence(); if (!header || !sequence) goto goHome; tp = OpenDefaultComponent(kTunePlayerType, 0); if (!tp) goto goHome; thisError = TuneSetHeader(tp, header); thisError = TuneQueue(tp, sequence, 0x00010000, 0, 0x7FFFFFFF, 0, 0, 0); // Wait until the sequence finishes playing or the user clicks // the mouse. spin: thisError = TuneGetStatus(tp, &ts); if (ts.queueTime && !Button()) goto spin; // I use gotos primarily to shock the children. goHome: if (tp) CloseComponent(tp); if (header) DisposePtr((Ptr) header); if (sequence) DisposePtr((Ptr) sequence); }
Listing 8. Creating a QuickTime music track
void BuildMusicMovie(void) { ComponentResult result; StandardFileReply reply; short resRefNum; Movie mo; Track tr; Media me; unsigned long *tune, *header; MusicDescription **mdH, *md; StandardPutFile("\pMusic movie file name:", "\pMovie File", &reply); if (!reply.sfGood) goto goHome; EnterMovies(); // Create the movie, track, and media. result = CreateMovieFile(&reply.sfFile, 'TVOD', smCurrentScript, createMovieFileDeleteCurFile, &resRefNum, &mo); if (result) goto goHome; tr = NewMovieTrack(mo, 0, 0, 256); me = NewTrackMedia(tr, MusicMediaType, 600, nil, 0); // Create a music sample description. header = BuildTuneHeader(); mdH = (MusicDescription **) NewHandleClear(sizeof(MusicDescription) - 4 + our_header_length); if (!mdH) goto goHome; md = *mdH; md->descSize = GetHandleSize((Handle) mdH); md->dataFormat = kMusicComponentType; BlockMove(header, md->headerData, our_header_length); DisposePtr((Ptr) header); // Get a tune, add it to the media, and then finish up. tune = BuildTuneSequence(); result = BeginMediaEdits(me); result = AddMediaSample(me, (Handle) &tune, 0, our_sequence_length, our_sequence_duration, (SampleDescriptionHandle) mdH, 1, 0, nil); result = EndMediaEdits(me); result = InsertMediaIntoTrack(tr, 0, 0, our_sequence_duration, (1L<<16)); result = OpenMovieFile(&reply.sfFile, &resRefNum, fsRdWrPerm); result = AddMovieResource(mo, resRefNum, 0, 0); result = CloseMovieFile(resRefNum); DisposePtr((Ptr) tune); DisposeMovie(mo); goHome: ExitMovies(); }
The conversion to a QuickTime movie can happen in several ways. Because the conversion is implemented in a QuickTime 'eat ' component, it very often will happen automatically. Any application that uses the StandardGetFile routine to open a movie can also open 'Midi' files transparently, and can transparently paste Clipboard contents of type 'Midi' into a movie that's shown with the standard movie controller. To explicitly convert a file or handle into a movie, an application can use the Movie Toolbox routines ConvertFileToMovieFile and PasteHandleIntoMovie, respectively.
For those of you who are hard-core MIDI heads, the following two MIDI system-exclusive messages, new in QuickTime 2.1, may be useful for more precise control of the MIDI import process. (Note that QuickTime data is divided into media samples. Within video tracks, each video frame is considered one sample; in music tracks, each sample may contain several seconds worth of musical information.)
The default MIDI input is whichever MIDI port the user has chosen for a General MIDI device from the QuickTime Music control panel, shown in Figure 5. (The default MIDI input can also be specified with the NASetDefaultMIDIInput call in the note allocator, but this call should be made only by music-configuration software, such as the control panel.)
pascal ComponentResult NAUseDefaultMIDIInput(NoteAllocator na, MusicMIDIReadHookUPP readHook, long refCon, unsigned long flags);
The readHook routine is defined as follows:
typedef pascal ComponentResult (*MusicMIDIReadHookProcPtr) (MusicMIDIPacket *mp, long myRefCon);
When the readHook routine is called, it's passed its refCon (installed with the routine) and a pointer to the MIDI packet. The MIDI packet structure is simply a list of bytes of a MIDI message, preceded by a length:
struct MusicMIDIPacket { unsigned short length; unsigned long reserved; UInt8 data[249]; };
The length field is the number of bytes in the MIDI message. (If you're familiar with the MIDI Manager definition of a MIDI packet or with OMS's packet, note that their length field is different from this one: Theirs is the length of both the header and the packet data, so the minimum length would be 6; but in QuickTime's packets, the length field is only the number of bytes of MIDI data actually in the data array.)
In QuickTime 2.0, the reserved field must be set to 0, but in QuickTime 2.1, this field takes on some additional meanings (as reserved fields occasionally do). When an application is using the default MIDI input, it may occasionally lose the use of that input, such as when another application tries to use it, or if the instrument picker dialog box comes to the front. If the use of the input is lost, the reserved field will have the value kMusicPacketPortLost = 1, and the length field will be 0: no MIDI data. When the port is once again available, the readHook routine will receive a packet with the reserved field set to kMusicPacketPortFound = 2, also with no data.
The data array in the MIDI packet contains a raw MIDI message that your readHook routine will have to parse. Our example code parses only the MIDI messages for note-on events and note-off events; other messages, such as pitch-bend controls, are simply ignored.
The note-on event message has three bytes, 9c pp vv (in hexadecimal), where c is the MIDI channel that the musical keyboard is transmitting on, pp is a MIDI pitch from 0 to 127 (60 is middle C), and vv is the velocity with which the key was struck, from 1 to 127. If the velocity is 0, the message signifies a note-off event. Some devices, however, use a separate message type for note-off events; it has the form 8c pp vv, where c and pp are the channel and pitch, and vv is the velocity with which the key was released. Nobody in the world pays attention to the release velocity, so in our example we won't either. When an 8c message is received, we'll just set the velocity to 0 and pretend it was a 9c message.
Listing 9 shows a readHook routine and the routine that installs it. The main routine, UseMIDIInput, allocates a note channel and then calls NAUseDefaultMIDIInput, specifying a readHook routine that parses note-on or note-off event messages. These messages are expanded into a chord that's played on the note channel. Any packet that isn't of that type -- that is, doesn't contain three bytes or start with 0x8n or 0x9n -- is ignored.
Listing 9. Parsing MIDI messages in the readHook routine
pascal ComponentResult AReadHook(MusicMIDIPacket *mp, long refCon) { MIDIInputExample *mie; Boolean major; short status, pitch, vel; mie = (MIDIInputExample *)refCon; if (mp->reserved == kMusicPacketPortLost) // port gone? make // channel quiet NASetNoteChannelVolume(mie->na, mie->nc, 0); else if (mp->reserved == kMusicPacketPortFound) // port back? // raise volume NASetNoteChannelVolume(mie->na, mie->nc, 0x00010000); else if (mp->length == 3) { status = mp->data[0] & 0xF0; pitch = mp->data[1]; vel = mp->data[2]; switch (status) { case 0x80: vel = 0; // Falls into case 0x90. case 0x90: major = pitch % 5 == 0; NAPlayNote(mie->na, mie->nc, pitch, vel); NAPlayNote(mie->na, mie->nc, pitch+3+major, vel); NAPlayNote(mie->na, mie->nc, pitch+7, vel); break; } } return noErr; } void UseMIDIInput(void) { ComponentResult result; MIDIInputExample mie; NoteRequest nr; mie.na = OpenDefaultComponent(kNoteAllocatorType, 0); if (!mie.na) goto goHome; nr.polyphony = 2; nr.typicalPolyphony = 0x00010000; result = NAStuffToneDescription(mie.na, 1, &nr.tone);// piano result = NANewNoteChannel(mie.na, &nr, &mie.nc); result = NAUseDefaultMIDIInput(mie.na, AReadHookUPP, (long) &mie, 0) while (!Button()); result = NALoseDefaultMIDIInput(mie.na); goHome: if (mie.na) CloseComponent(mie.na); // disposes of NoteChannel, too }
DAVID VAN BRINK lives in a tiny experimental habitat overlooking the Denny's parking lot in Santa Cruz, California. He experiences life at 14,400 bits per second. See http://www.srm.com for more information.*
Thanks to our technical reviewers Peter Hoddie, Duncan Kennedy, Jim Nitchals, Jim Reekes, and Kent Sandvik.*