Standard MIDI-File Format Spec. 1.1

Distributed by: The International MIDI Association 5316 W. 57th St. Los Angeles, CA 90056 (213) 649-6434 0 - Introduction The document outlines the specification for MIDI Files. The purpose of MIDI Files is to provide a way of interchanging time-stamped MIDI data between different programs on the same or different computers. One of the primary design goals is compact representation, which makes it very appropriate for disk-based file format, but which might make it inappropriate for storing in memory for quick access by a sequencer program. (It can be easily converted to a quickly-accessible format on the fly as files are read in or written out.) It is not intended to replace the normal file format of any program, though it could be used for this purpose if desired. MIDI Files contain one or more MIDI streams, with time information for each event. Song, sequence, and track structures, tempo and time signature information, are all supported. Track names and other descriptive information may be stored with the MIDI data. This format supports multiple tracks and multiple sequences so that if the user of a program which supports multiple tracks intends to move a file to another one, this format can allow that to happen. This spec defines the 8-bit binary data stream used in the file. The data can be stored in a binary file, nibbilized, 7-bit-ized for efficient MIDI transmission, converted to Hex ASCII, or translated symbolically to a printable text file. This spec addresses what's in the 8-bit stream. It does not address how a MIDI File will be transmitted over MIDI. It is the general feeling that a MIDI transmission protocol will be developed for files in general and MIDI Files will use this scheme. 1 - Sequences, Tracks, Chunks: File Block Structure CONVENTIONS In this document, bit 0 means the least significant bit of a byte, and bit 7 is the most significant. Some numbers in MIDI Files are represented is a form called VARIABLE-LENGTH QUANTITY. These numbers are represented 7 bits per byte, most significant bits first. All bytes except the last have bit 7 set, and the last byte has bit 7 clear. If the number is between 0 and 127, it is thus represented exactly as one byte. Here are some examples of numbers represented as variable-length quantities: 00000000 00 00000040 40 0000007F 7F 00000080 81 00 00002000 C0 00 00003FFF FF 7F 00004000 81 80 00 00100000 C0 80 00 001FFFFF FF FF 7F 00200000 81 80 80 00 08000000 C0 80 80 00 0FFFFFFF FF FF FF 7F The largest number which is allowed is 0FFFFFFF so that the variable-length representations must fit in 32 bits in a routine to write variable-length numbers. Theoretically, larger numbers are possible, but 2 x 10^8 96ths of a beat at a fast tempo of 500 beats per minute is four days, long enough for any delta-time! FILES To any file system, a MIDI File is simply a series of 8-bit bytes. On the Macintosh, this byte stream is stored in the data fork of a file (with file type 'MIDI'), or on the Clipboard (with data type 'MIDI'). Most other computers store 8-bit byte streams in files -- naming or storage conventions for those computers will be defined as required. CHUNKS MIDI Files are made up of -chunks-. Each chunk has a 4-character type and a 32-bit length, which is the number of bytes in the chunk. This structure allows future chunk types to be designed which may be easily be ignored if encountered by a program written before teh chunk type is introduced. Your programs should EXPECT alien chunks and treat them as if they weren't there. Each chunk begins with a 4-character ASCII type. It is followed by a 32-bit length, most significant byte first (a length of 6 is stored as 00 00 00 06). This length refers to the number of bytes of data which follow: the eight bytes of type and length are not included. Therefore, a chunk with a length of 6 would actually occupy 14 bytes in the disk file. This chunk architecture is similar to that used by Electronic Arts' IFF format, and the chunks described herin could easily be placed in an IFF file. The MIDI File itself is not an IFF file: it contains no nested chunks, and chunks are not constrained to be an even number of bytes long. Converting it to an IFF file is as easy as padding odd length chunks, and sticking the whole thing inside a FORM chunk. MIDI Files contain two types of chunks: header chunks and track chunks. A -header- chunk provides a minimal amount of information pertaining to the entire MIDI file. A -track- chunk contains a sequential stream of MIDI data which may contain information for up to 16 MIDI channels. The concepts of multiple tracks, multiple MIDI outputs, patterns, sequences, and songs may all be implemented using several track chunks. A MIDI File always starts with a header chunk, and is followed by one or more track chunks. MThd

MTrk MTrk . . . 2 - Chunk Descriptions HEADER CHUNKS The header chunk at the beginning of the file specifies some basic information about the data in the file. Here's the syntax of the complete chunk:

= As described above, is the four ASCII characters 'MThd'; is a 32-bit representation of the number 6 (high byte first). The data section contains three 16-bit words, stored most-significant byte first. The first word, , specifies the overall organization of the file. Only three values of are specified: 0-the file contains a single multi-channel track 1-the file contains one or more simultanious tracks (or MIDI outputs) of a sequence 2-the file contains one or more sequentially independant single-track patterns More information about these formats is provided below. The next word, , is the number of track chunks in the file. It will always be 1 for a format 0 file. The third word, , specifies the meaning of the delta-times. It has two formats, one for metrical time, and one for time-code-based time: +---+-----------------------------------------+ | 0 | ticks per quarter-note | ==============================================| | 1 | negative SMPTE format | ticks per frame | +---+-----------------------+-----------------+ |15 |14 8 |7 0 | If bit 15 of is zero, the bits 14 thru 0 represent the number of delta time "ticks" which make up a quarter-note. For instance, if division is 96, then a time interval of an eighth-note between two events in the file would be 48. If bit 15 of is a one, delta times in a file correspond to subdivisions of a second, in a way consistent with SMPTE and MIDI Time Code. Bits 14 thru 8 contain one of the four values -24, -25, -29, or -30, corresponding to the four standard SMPTE and MIDI Time Code formats (-29 corresponds to 30 drop frome), and represents the number of frames per second. These negative numbers are stored in two's compliment form. The second byte (stored positive) is the resolution within a frame: typical values may be 4 (MIDI Time Code resolution), 8, 10, 80 (bit resolution), or 100. This stream allows exact specifications of time-code-based tracks, but also allows milisecond-based tracks by specifying 25|frames/sec and a resolution of 40 units per frame. If the events in a file are stored with a bit resolution of thirty-framel time code, the division word would be E250 hex. FORMATS 0, 1, AND 2 A Format 0 file has a header chunk followed by one track chunk. It is the most interchangable representation of data. It is very useful for a simple single-track player in a program which needs to make synthesizers make sounds, but which is primarily concerened with something else such as mixers or sound effect boxes. It is very desirable to be able to produce such a format, even if your program is track-based, in order to work with these simple programs. On the other hand, perhaps someone will write a format conversion from format 1 to format 0 which might be so easy to use in some setting that it would save you the trouble of putting it into your program. A Format 1 or 2 file has a header chunk followed by one or more track chunks. programs which support several simultanious tracks should be able to save and read data in format 1, a vertically one-dementional form, that is, as a collection of tracks. Programs which support several independant patterns should be able to save and read data in format 2, a horizontally one-dementional form. Providing these minimum capabilities will ensure maximum interchangability. In a MIDI system with a computer and a SMPTE synchronizer which uses Song Pointer and Timing Clock, tempo maps (which describe the tempo throughout the track, and may also include time signature information, so that the bar number may be derived) are generally created on the computer. To use them with the synchronizer, it is necessary to transfer them from the computer. To make it easy for the synchronizer to extract this data from a MIDI File, tempo information should always be stored in the first MTrk chunk. For a format 0 file, the tempo will be scattered through the track and the tempo map reader should ignore the intervening events; for a format 1 file, the tempo map must be stored as the first track. It is polite to a tempo map reader to offerr your user the ability to make a format 0 file with just the tempo, unless you can use format 1. All MIDI Files should specify tempo and time signature. If they donn't, the time signature is assumed to be 4/4, and the tempo 120 beats per minute. In format 0, these meta-events should occur at least at the beginning of the single multi-channel track. In format 1, these meta-events should be contained i| the first track. In format 2, each of the temporally independant patterns should contain at least initial time signature and tempo information. We may decide to define other format IDs to support other structures. A program encountering an unknown format ID may still read other MTrk chunks it finds from the file, as format 1 or 2, if its user can make sense of them and arrange them into some other structure if appropriate. Also, more parameters may be added to the MThd chunk in the future: it is important to read and honor the length, even if it is longer than 6. TRACK CHUNKS The track chunks (type MTrk) are where actual song data is stored. Each track chunk is simply a stream of MIDI events (and non-MIDI events), preceded by delta-time values. The format for Track Chunks (described below) is exactly the same for all three formats (0, 1, and 2: see "Header Chunk" above) of MIDI Files. Here is the syntax of an MTrk chunk (the + means "one or more": at least one MTrk event must be present): = + The syntax of an MTrk event is very simple: =

is stored as a variable-length quantity. It represents the amount of time before the following event. If the first event in a track occurs at the very beginning of a track, or if two events occur simultaineously, a delta-time of zero is used. Delta-times are always present. (Not storing delta-times of 0 requires at least two bytes for any other value, and most delta-times aren't zero.) Delta-time is in some fraction of a beat (or a second, for recording a track with SMPTE times), as specified in the header chunk. = | | is any MIDI channel message. Running status is used: status bytes of MIDI channel messages may be omitted if the preceding event is a MIDI channel message with the same status. The first event in each MTrk chunk must specifyy status. Delta-time is not considered an event itself: it is an integral part of the syntax for an MTrk event. Notice that running status occurs across delta-times. is used to specify a MIDI system exclusive message, either as one unit or in packets, or as an "escape" to specify any arbitrary bytes to be transmitted. A normal complete system exclusive message is stored in a MIDI File in this way: F0 The length is stored as a variable-length quantity. It specifies the number of bytes which follow it, not including the F0 or the length itself. For instance, the transmitted message F0 43 12 00 07 F7 would be stored in a MIDI File as F0 05 43 12 00 07 F7. It is required to include the F7 at the end so that the reader of the MIDI File knows that it has read the entire message. Another form of sysex event is provided which does not imply that an F0 should be transmitted. This may be used as an "escape" to provide for the transmission of things which would not otherwise be legal, including system realtime messages, song pointer or select, MIDI Time Code, etc. This uses the F7 code: F7 Unfortunately, some synthesizer manufacturers specify that their system exclusive messages are to be transmitted as little packets. Each packet is only part of an entire syntactical system exclusive message, but the times they are transmitted are important. Examples of this are the bytes sent in a CZ patch dump, or the FB-01's "system exclusive mode" in which microtonal data can be transmitted. The F0 and F7 sysex events may be used together to break up syntactically complete system exclusive messages into timed packets. An F0 sysex event is used for the first packet in a series -- it is a message in which the F0 should be transmitted. An F7 sysex event is used for the remainder of the packets, which do not begin with F0. (Of course, the F7 is not considered part of the system exclusive message). A syntactic system exclusive message must always end with an F7, even if the real-life device didn't send one, so that you know when you've reached the end of an entire sysex message without looking ahead to the next event in the MIDI File. If it's stored in one compllete F0 sysex event, the last byte must be an F7. There also must not be any transmittable MIDI events in between the packets of a multi-packet system exclusive message. This principle is illustrated in the paragraph below. Here is a MIDI File of a multi-packet system exclusive message: suppose the bytes F0 43 12 00 were to be sent, nofollowed by a 200-tick delay, followed by the bytes 43 12 00 43 12 00, nofollowed by a 100-tick delay, nofollowed by the bytes 43 12 00 F7, this would be in the MIDI File: F0 03 43 12 00 81 48 200-tick delta time F7 06 43 12 00 43 12 00 64 100-tick delta time F7 04 43 12 00 F7 When reading a MIDI File, and an F7 sysex event is encountered without a preceding F0 sysex event to start a multi-packet system exclusive message sequence, it should be presumed that the F7 event is being used as an "escape". In this case, it is not necessary that it end with an F7, unless it is desired that the F7 be transmitted. specifies non-MIDI information useful to this format or to sequencers, with this syntax: FF All meta-events begin with FF, then have an event type byte (which is always less than 128), and then have the length of the data stored as a variable-length quantity, and then the data itself. If there is no data, the length is 0. As with chunks, future meta-events may be designed which may not be known to existing programs, so programs must properly ignore meta-events which they do not recognize, and indeed should expect to see them. Programs must never ignore the length of a meta-event which they do not recognize, and they shouldn't be surprized if it's bigger than expected. If so, they must ignore everything past what they know about. However, they must not add anything of their own to the end of the meta- event. Sysex events and meta events cancel any running status which was in effect. Running status does not apply to and may not be used for these messages. 3 - Meta-Events A few meta-events are defined herin. It is not required for every program to support every meta-event. In the syntax descriptions for each of the meta-events a set of conventions is used to describe parameters of the events. The FF which begins each event, the type of each event, and the lengths of events which do not have a variable amount of data are given directly in hexadecimal. A notation such as dd or se, which consists of two lower-case letters, mnemonically represents an 8-bit value. Four identical lower-case letters such as wwww mnemonically refer to a 16-bit value, stored most-significant-byte first. Six identical lower-case letters such as tttttt refer to a 24-bit value, stored most-significan-byte first. The notation len refers to teh length portion of the meta-event syntax, that is, a number, stored as a variable- length quantity, which specifies how many bytes (possibly text) data were just specified by the length. In general, meta-events in a track which occur at the same time may occur in any order. If a copyright event is used, it should be placed as early as possible in the file, so it will be noticed easily. Sequence Number and Sequence/Track Name events, if present, must appear at time 0. An end-of- track event must occur as the last event in the track. Meta-events initially defined include: FF 00 02 Sequence Number This optional event, which must occur at the beginning of a track, before any nonzero delta-times, and before any transmittable MIDI events, specifies the number of a sequence. In a format 2 MIDI File, it is used to identify each "pattern" so that a "song" sequence using the Cue message to refer to the patterns. If the ID numbers are omitted, the sequences' lacations in order in the file are used as defaults. In a format 0 or 1 MIDI File, which only contain one sequence, this number should be contained in the first (or only) track. If transfer of several multitrack sequences is required, this must be done as a group of format 1 files, each with a different sequence number. FF 01 len text Text Event Any amount of text describing anything. It is a good idea to put a text event right at the beginning of a track, with the name of the track, a description of its intended orchestration, and any other information which the user wants to put there. Text events may also occur at other times in a track, to be used as lyrics, or descriptions of cue points. The text in this event should be printable ASCII characters for maximum interchange. However, other characters codes using the high-order bit may be used for interchange of files between different programs on the same computer which supports an extended character set. Programs on a computer which does not support non-ASCII characters should ignore those characters. Meta-event types 01 through 0F are reserved for various types of text events, each of which meets the specification of text events (above) but is used for a different purpose: FF 02 len text Copyright Notice Contains a copyright notice as printable ASCII text. The notice should contain the characters (C), the year of the copyright, and the owner of the copyright. If several pieces of music are in the same MIDI File, all of the copyright notices should be placed together in this event so that it will be at the beginning of the file. This event should be the first event in the track chunk, at time 0. FF 03 len text Sequence/Track Name If in a format 0 track, or the first track in a format 1 file, the name of the sequence. Otherwise, the name of the track. FF 04 len text Instrument Name A description of the type of instrumentation to be used in that track. May be used with the MIDI Prefix meta-event to specify which MIDI channel the description applies to, or the channel may be specified as text in the event itself. FF 05 len text Lyric A lyric to be sung. Generally, each syllable will be a seperate lyric event which begins at the event's time. FF 06 len text Marker Normally in a format 0 track, or the first track in a format 1 file. The name of that point in the sequence, such as a rehersal letter or section name ("First Verse", etc.) FF 07 len text Cue Point A description of something happening on a film or video screen or stage at that point in the musical score ("Car crashes into house", "curtain opens", "she slaps his face", etc.) FF 20 01 cc MIDI Channeel Prefix The MIDI channel (0-15) containted in this event may be used to associate a MIDI channel with all events which follow, including System exclusive and meta-events. This channel is "effective" until the next normal MIDI event (which contains a channel) or the next MIDI Channel Prefix meta-event. If MIDI channels refer to "tracks", this message may into a format 0 file, keeping their non-MIDI data associated with a track. This capability is also present in Yamaha's ESEQ file format. FF 2F 00 End of Track This event is not optional. It is included so that an exact ending point may be specified for the track, so that an exect length, which is necessary for tracks which are looped or concatenated. FF 51 03 tttttt Set Tempo (in microseconds per MIDI quarter-note) This event indicates a tempo change. Another way of putting "microseconds per quarter-note" is "24ths of a microsecond per MIDI clock". Repersenting tempos as time per beat instead of beat per time allows absolutly exact long-term synchronization with a time-based sync protocol such as SMPTE time code or MIDI time code. This amount of accuracy provided by this tempo resolution allows a four-minute piece at 120 beats per minute to be accurate within 500 usec at the end of the piece. Ideally, these events should only occur where MIDI clocks would be located -- this convention is intended to guarntee, or at least increase the liklihood, of compatibility with other synchronization devices so that a time signature/tempo map stored in this format may easily be transfered to another device. FF 54 05 hr mn se fr ff SMPTE Offset This event, if present, designates the SMPTE time at which the track chunk is supposed to start. It should be present at the beginning of the track, that is, before any nonzero delta-times, and before any transmittable MIDI events. the hour must be encoded with the SMPTE format, just as it is in MIDI Time Code. In a format 1 file, the SMPTE Offset must be stored with the tempo map, and has no meaning in any of the other tracks. The ff field contains fractional frames, in 100ths of a frame, even in SMPTE-based tracks which specify a different frame subdivision for delta-times. FF 58 04 nn dd cc bb Time Signature The time signature is expressed as four numbers. nn and dd represent the numerator and denominator of the time signature as it would be notated. The denominator is a neqative power of two: 2 represents a quarter-note, 3 represents an eighth-note, etc. The cc parameter expresses the number of MIDI clocks in a metronome click. The bb parameter expresses the number of notated 32nd-notes in a MIDI quarter-note (24 MIDI clocks). This was added because there are already multiple programs which allow a user to specify that what MIDI thinks of as a quarter-note (24 clocks) is to be notated as, or related to in terms of, something else. Therefore, the complete event for 6/8 time, where the metronome clicks every three eighth-notes, but there are 24 clocks per quarter-note, 72 to the bar, would be (in hex): FF 58 04 06 03 24 08 That is, 6/8 time (8 is 2 to the 3rd power, so this is 06 03), 36 MIDI clocks per dotted-quarter (24 hex!), and eight notated 32nd-notes per quarter-note. FF 59 02 sf mi Key Signature sf = -7: 7 flats sf = -1: 1 flat sf = 0: key of C sf = 1: 1 sharp sf = 7: 7 sharps mi = 0: major key mi = 1: minor key FF 7F len data Sequencer Specific Meta-Event Special requirements for particular sequencers may use this event type: the first byte or bytes of data is a manufacturer ID (these are one byte, or if the first byte is 00, three bytes). As with MIDI System Exclusive, manufacturers who define something using this meta-event should publish it so that others may be used by a sequencer which elects to use this as its only file format; sequencers with their established feature-specific formats should probably stick to the standard features when using this format. 4 - Program Fragments and Example MIDI Files Here are some of the routines to read and write variable-length numbers in MIDI Files. These routines are in C, and use getc and putc, which read and write single 8-bit characters from/to the files infile and outfile. WriteVarLen (value) register long value; ( register long buffer; buffer = value & 0x7f; while ((value >>= 7) > 0) ( buffer <<= 8; buffer |= 0x80; buffer += (value & 0x7f); ) while (TRUE) ( putc(buffer,outfile); if (buffer & 0x80) buffer >>= 8; else break; ) ) doubleword ReadVarLen () ( register doubleword value; register byte c; if ((value = getc(infile)) & 0x80) ( value &= 0x7f; do ( value = (value << 7) + ((c = getc(infile))) & 0x7f); ) while (c & 0x80); ) return (value); ) As an example, MIDI Files for the following excerpt are shown below. First, a format 0 file is shown, with all information intermingled; then, a format 1 file is shown with all data seperated into four tracks: one for tempo and time signature, and three for the notes. A resolution of 96 "ticks" per quarter note is used. A time signature of 4/4 and a tempo of 120, though implied, are explicitly stated. |\ ---- | > --------------------------------------- |/ ____ O Channel 1 ---- X --------------------------------|-------- / | Preset 5 -- / | --------------------------------|-------- / ____ | -| | \ -------------------------------------- \ | | -- \_|__/ -------------------------------------- _| |\ ---- | > --------------------------------------- |/ \ Channel 2 ---- X ------------>----------|----------------- / / | Preset 46 -- / | ----------<------------|----------------- / ____ \ | . -| | \ --------->---------O------------------ \ | | ( -- \_|__/ --------\----------------------------- _| \ --O-- ----__ ----------------------------------------- / \ . Channel 3 - / | --------------------------------------- | . Preset 70 ------ | --------------------------------------- / O ---- / ----------------------------------------- / -- / ------------------------------------------- The contents of the MIDI stream represented by this example are broken down here: Delta-Time Event-Code Other Bytes Comment (decimal) (hex) (decimal) ---------- ---------- ----------- ----------------------------- 0 FF 58 04 04 02 24 08 4 bytes; 4/4 time; 24 MIDI clocks/click, 8 32nd notes/ 24 MIDI clocks 0 FF 51 03 500000 3 bytes: 500,000 usec/ quarter note 0 C0 5 Ch.1 Program Change 5 0 C1 46 Ch.2 Program Change 46 0 C2 70 Ch.3 Program Change 70 0 92 48 96 Ch.3 Note On C2, forte 0 92 60 96 Ch.3 Note On C3, forte 96 91 67 64 Ch.2 Note On G3, mezzo-forte 96 90 76 32 Ch.1 Note On E4, piano 192 82 48 64 Ch.3 Note Off C2, standard 0 82 60 64 Ch.3 Note Off C3, standard 0 81 67 64 Ch.2 Note Off G3, standard 0 80 76 64 Ch.1 Note Off E4, standard 0 FF 2F 00 Track End The entire format 0 MIDI file contents in hex follow. First, the header chunk: 40 54 68 64 MThd 00 00 00 06 chunk length 00 00 format 0 00 01 one track 00 60 96 per quarter-note Then the track chunk. Its header followed by the events (notice the running status is used in places): 4D 54 72 6B MTrk 00 00 00 3B chunk length (59) Delta-Time Event Comments ---------- ----------------------- ------------------------------- 00 FF 58 04 04 02 18 08 time signature 00 FF 51 03 07 A1 20 tempo 00 C0 05 00 C1 2E 00 C2 46 00 92 30 60 00 3C 60 running status 60 91 43 40 60 90 4C 20 81 40 82 30 40 two-byte delta-time 00 3C 40 running status 00 81 43 40 00 80 4C 40 00 FF 2F 00 end of track A format 1 representation of the file is slightly different. Its header chunk: 4D 54 68 64 MThd 00 00 00 06 chunk length 00 01 format 1 00 04 four tracks 00 60 96 per quarter note First, the track chunk for the time signature/tempo track. Its header, followed by the events: 4D 54 72 6B MTrk 00 00 00 14 chunk length (20) Delta-Time Event Comments ---------- ----------------------- ------------------------------- 00 FF 58 04 04 02 18 08 time signature 00 FF 51 03 07 A1 20 tempo 83 00 FF 2F 00 end of track Then, the track chunk for the first music track. The MIDI convention for note on/off running status is used in this example: 4D 54 72 6B MTrk 00 00 00 10 chunk length (16) Delta-Time Event Comments ---------- ----------------------- ------------------------------- 00 C0 05 81 40 90 4C 20 81 40 4C 00 Running status: note on, vel=0 00 FF 2F 00 Then, the track chunk for the second music track: 4D 54 72 6B MTrk 00 00 00 0F chunk length (15) Delta-Time Event Comments ---------- ----------------------- ------------------------------- 00 C1 2E 60 91 43 40 82 20 43 00 running status 00 FF 2F 00 end of track Then, the track chunk for the third music track: 4D 54 72 6B MTrk 00 00 00 15 chunk length (21) Delta-Time Event Comments ---------- ----------------------- ------------------------------- 00 C2 46 00 92 30 60 00 3C 60 running status 83 00 30 00 two-byte delta-time, running status 00 3C 00 running status 00 FF 2F 00 end of track **** Brief Overview of Proposed General MIDI Level 1 Spec **** The heart of General MIDI (GM) is the _Instrument Patch Map_, shown in Table 1 (see below). This is a list of 128 sounds, with corresponding MIDI program numbers. Most of these are imitative sounds, though the list includes synth sounds, ethnic instruments and a handful of sound effects. The sounds fall roughtly into sixteen families of eight variations each. Grouping sounds makes it easy to re-orchestrate a piece using similar sounds. The Instrument Map isn't the final word on musical instruments of the world, but it's pretty complete General MIDI also includes a _Percusssion Key Map_, show in Table 2 (see below). This mapping derives from the Roland/Sequential mapping used on early drum machines. As with the Instrument Map, it doesn't cover every percussive instrument in the world, but it's more than adequate as a basic set. To avoid concerns with channels, GM restricts percussion to MIDI Channel 10. Theoretically, the lower nine channels are for the instruments, but the GM spec states that a sound module must respond to all sixteen MIDI channels, with dynamic voice allocation and a minimum of 24 voices. General MIDI doesn't mention sound quality of synthesis methods. Discussions are under way on standardizing sound parameters such as playable range and envelope times. This will ensure that an arrangement that relies on phrsing and balance can play back on a variety of modules. Other requirements for a GM sound module include response to velocity, mod wheel, aftertouch, sustain and expression pedal, main volume and pan, and the All Notes Off and Reset All Controllers messages. The module also must respond to both Pitch Bend and Pitch Bend Sensitivity (a MIDI registered parameter). The default pitch bend range is +-2 semitones. Middle C (C3) corresponds to MIDI key 60, and master tuning must be adjustable. Finally, the MIDI Manufacturers Association (MMA) created a new Universal System Exclusive message to turn General MIDI on and off (for devices that might have "consumer" and "programmable" settings). Table 3 (see below) summarizes these requirements. General MIDI has room for future expansion, including additional drum and instrument assignments and more required controllers. Also under discussion is an "authorizing document" that would standardize things such as channel assignments (e.g., lead on 1, bass on 2, etc.) and setup information in a MIDI file. Copies of the Level 1 Specification documents for General MIDI ($5 each at last notice) are available from the Internation MIDI Association, 5316 West 57th Street Los Angeles, CA 90056, (213) 649-6434. The first issue of the Journal of the MMA (back issues, $15 each) contains an article by PassPort Designs and Stanley Junglieb about General MIDI. Roland's GS Standard When Warner New Media first proposed a General MIDI standard, most MMA members gave it little thought. As discussions proceeded, Roland listened and developed a sound module to meet the proposed specification. At the same NAMM show where the MMA ratified General MIDI Level 1, Roland showed their Sound Brush and Sound Canvas, a Standard MIDI File player and GM-compatible sound module. Some companies feel that General MIDI doesn't go far enough, so Roland created a superset of General MIDI Level 1, which they call GS Standard. It obeys all the protocols and sound maps of General MIDI and adds many extra controllers and sounds. Some of the controllers use Unregistered Parameter Numbers to give macro control over synth parameters such as envelope attack and decay rates. The new MIDI Bank Select message provides access to extra sounds (including variations on the stock sounds and a re-creation of the MT-32 factory patches). The programs in each bank align with the original 128 in General MIDI's Instrument Patch Map, with eight banks housing related families. The GS Standard includes a "fall back" system. If the Sound Canvas receives a request for a bank/program number combination that does not exist, it will reassign it to the master instrument in that family. A set of Roland System Exclusive messages allows reconfiguration and customization of the sound module. This means that a Roland GS Standard sound module will correctly play back any song designed for General MIDI. In addition, if the song's creator wants to create some extra nuance, they can include the GS Standard extensions in their sequence. None of these extensions are so radical as to make the song unplayable on a normal GM sound module. After all, compatibility is what MIDI - and especially General MIDI - is all about. Music authors interested in the GS Standard should contact Tom White at RolandCorp USA, 7200 Dominion Circle, Los Angeles, CA 90040, (213) 685-5141. **** TABLE 1 - General MIDI Instrument Patch Map **** (groups sounds into sixteen families, w/8 instruments in each family) Prog# Instrument Prog# Instrument (1-8 PIANO) (9-16 CHROM PERCUSSION) 1 Acoustic Grand 9 Celesta 2 Bright Acoustic 10 Glockenspiel 3 Electric Grand 11 Music Box 4 Honky-Tonk 12 Vibraphone 5 Electric Piano 1 13 Marimba 6 Electric Piano 2 14 Xylophone 7 Harpsichord 15 Tubular Bells 8 Clav 16 Dulcimer (17-24 ORGAN) (25-32 GUITAR) 17 Drawbar Organ 25 Acoustic Guitar(nylon) 18 Percussive Organ 26 Acoustic Guitar(steel) 19 Rock Organ 27 Electric Guitar(jazz) 20 Church Organ 28 Electric Guitar(clean) 21 Reed Organ 29 Electric Guitar(muted) 22 Accoridan 30 Overdriven Guitar 23 Harmonica 31 Distortion Guitar 24 Tango Accordian 32 Guitar Harmonics (33-40 BASS) (41-48 STRINGS) 33 Acoustic Bass 41 Violin 34 Electric Bass(finger) 42 Viola 35 Electric Bass(pick) 43 Cello 36 Fretless Bass 44 Contrabass 37 Slap Bass 1 45 Tremolo Strings 38 Slap Bass 2 46 Pizzicato Strings 39 Synth Bass 1 47 Orchestral Strings 40 Synth Bass 2 48 Timpani (49-56 ENSEMBLE) (57-64 BRASS) 49 String Ensemble 1 57 Trumpet 50 String Ensemble 2 58 Trombone 51 SynthStrings 1 59 Tuba 52 SynthStrings 2 60 Muted Trumpet 53 Choir Aahs 61 French Horn 54 Voice Oohs 62 Brass Section 55 Synth Voice 63 SynthBrass 1 56 Orchestra Hit 64 SynthBrass 2 (65-72 REED) (73-80 PIPE) 65 Soprano Sax 73 Piccolo 66 Alto Sax 74 Flute 67 Tenor Sax 75 Recorder 68 Baritone Sax 76 Pan Flute 69 Oboe 77 Blown Bottle 70 English Horn 78 Skakuhachi 71 Bassoon 79 Whistle 72 Clarinet 80 Ocarina (81-88 SYNTH LEAD) (89-96 SYNTH PAD) 81 Lead 1 (square) 89 Pad 1 (new age) 82 Lead 2 (sawtooth) 90 Pad 2 (warm) 83 Lead 3 (calliope) 91 Pad 3 (polysynth) 84 Lead 4 (chiff) 92 Pad 4 (choir) 85 Lead 5 (charang) 93 Pad 5 (bowed) 86 Lead 6 (voice) 94 Pad 6 (metallic) 87 Lead 7 (fifths) 95 Pad 7 (halo) 88 Lead 8 (bass+lead) 96 Pad 8 (sweep) (97-104 SYNTH EFFECTS) (105-112 ETHNIC) 97 FX 1 (rain) 105 Sitar 98 FX 2 (soundtrack) 106 Banjo 99 FX 3 (crystal) 107 Shamisen 100 FX 4 (atmosphere) 108 Koto 101 FX 5 (brightness) 109 Kalimba 102 FX 6 (goblins) 110 Bagpipe 103 FX 7 (echoes) 111 Fiddle 104 FX 8 (sci-fi) 112 Shanai (113-120 PERCUSSIVE) (121-128 SOUND EFFECTS) 113 Tinkle Bell 121 Guitar Fret Noise 114 Agogo 122 Breath Noise 115 Steel Drums 123 Seashore 116 Woodblock 124 Bird Tweet 117 Taiko Drum 125 Telephone Ring 118 Melodic Tom 126 Helicopter 119 Synth Drum 127 Applause 120 Reverse Cymbal 128 Gunshot **** TABLE 2 - General MIDI Percussion Key Map **** (assigns drum sounds to note numbers. MIDI Channel 10 is for percussion) MIDI Drum Sound MIDI Drum Sound Key Key 35 Acoustic Bass Drum 59 Ride Cymbal 2 36 Bass Drum 1 60 Hi Bongo 37 Side Stick 61 Low Bongo 38 Acoustic Snare 62 Mute Hi Conga 39 Hand Clap 63 Open Hi Conga 40 Electric Snare 64 Low Conga 41 Low Floor Tom 65 High Timbale 42 Closed Hi-Hat 66 Low Timbale 43 High Floor Tom 67 High Agogo 44 Pedal Hi-Hat 68 Low Agogo 45 Low Tom 69 Cabasa 46 Open Hi-Hat 70 Maracas 47 Low-Mid Tom 71 Short Whistle 48 Hi-Mid Tom 72 Long Whistle 49 Crash Cymbal 1 73 Short Guiro 50 High Tom 74 Long Guiro 51 Ride Cymbal 1 75 Claves 52 Chinese Cymbal 76 Hi Wood Block 53 Ride Bell 77 Low Wood Block 54 Tambourine 78 Mute Cuica 55 Splash Cymbal 79 Open Cuica 56 Cowbell 80 Mute Triangle 57 Crash Cymbal 2 81 Open Triangle 58 Vibraslap **** TABLE 3 - General MIDI minimum sound module specs **** Voices: A minimum of either 24 fully dynamically allocated voices available simultaneously for both melodic and percussive sounds or 16 dynamically allocated voices for melody plus eight for percussion. Channels: General MIDI mode supports all sixteen MIDI channels. Each channel can play a variable number of voices (polyphony). Each channel can play a different instrument (timbre). Keybased Percussion is always on Channel 10. Instruments: A minimum of sixteen different timbres playing various instrument sounds. A minimum of 128 preset for Intruments (MIDI program numbers). Note on/Note off: Octabe Registration: Middle C(C3) = MIDI key 60. All Voices including percussion respond to velocity. Controllers: Controller # Description 1 Modulation 7 Main Volume 10 Pan 11 Expression 64 Sustain 121 Reset All Controllers 123 All Notes Off Registered Description Parameter # 0 Pitch Bend Sensitivity 1 Fine Tuning 2 Coarse Tuning Additional Channel Messages: Channel Pressure (Aftertouch) Pitch Bend Power-Up Defaults: Pitch Bend Amount = 0 Pitch Bend Sensitivity = +-2 semitones Volume = 90 All Other Controllers = reset (after Electronic Musician, 8/91 issue) The USENET MIDI Primer Bob McQueer PURPOSE It seems as though many people in the USENET community have an interest in the Musical Instrument Digital Interface (MIDI), but for one reason or another have only obtained word of mouth or fragmentary descriptions of the specification. Basic questions such as "what's the baud rate?", "is it EIA?" and the like seem to keep surfacing in about half a dozen newsgroups. This article is an attempt to provide the basic data to the readers of the net. REFERENCE The major written reference for this article is version 1.0 of the MIDI specification, published by the International MIDI Association, copyright 1983. There exists an expanded document. This document, which I have not seen, is simply an expansion of the 1.0 spec. to contain more explanatory material, and fill in some areas of hazy explanation. There are no radical departures from 1.0 in it. I have also heard of a "2.0" spec., but the IMA claims no such animal exists. In any event, backwards compatibility with the information I am presenting here should be maintained. CONVENTIONS I will give constants in C syntax, ie. 0x for hexadecimal. If I refer to bits by number, I number them starting with 0 for the low order (1's place) bit. The following notation: >> text << will be used to delimit commentary which is not part of the "bare- bones" specification. A sentence or paragraph marked with a question mark in column 1 is a point I would kind of like to hear something about myself. OK, let's give it a shot. PHYSICAL CONNECTOR SPECIFICATION The standard connectors used for MIDI are 5 pin DIN. Separate sockets are used for input and output, clearly marked on a given device. The spec. gives 50 feet as the maximum cable length. Cables are to be shielded twisted pair, with the shield connecting pin 2 at both ends. The pair is pins 4 and 5, pins 1 and 3 being unconnected: 2 5 4 3 1 A device may also be equipped with a "MIDI-THRU" socket which is used to pass the input of one device directly to output. >> I think this arrangement shows some of the original conception of MIDI more as a way of allowing keyboardists to control multiple boxes than an instrument to computer interface. The "daisy-chain" arrangement probably has advantages for a performing musician who wants to play "stacked" synthesizers for a desired sound, and has to be able to set things up on the road. << ELECTRICAL SPECIFICATION Asynchronous serial interface. The baud rate is 31.25 Kbaud (+/- 1%). There are 8 data bits, with 1 start bit and 1 stop bit, for 320 microseconds per serial byte. MIDI is current loop, 5 mA. Logic 0 is current ON. The specification states that input is to be opto-isolated, and points out that Sharp PC-900 and HP 6N138 optoisolators are satisfactory devices. Rise and fall time for the optoisolator should be less than 2 microseconds. The specification shows a little circuit diagram for the connections to a UART. I am not going to reproduce it here. There's not much to it - I think the important thing it shows is +5 volt connection to pin 4 of the MIDI out with pin 5 going to the UART, through 220 ohm load resistors. It also shows that you're supposed to connect to the "in" side of the UART through an optoisolator, and to the MIDI-THRU on the UART side of the isolator. >> I'm not much of a hardware person, and don't really know what I'm talking about in paragraphs like the three above. I DO recognize that this is a "non-standard" specification, which won't work over serial ports intended for anything else. People who do know about such things seem to either have giggling or gagging fits when they see it, depending on their dispos- itions, saying things like "I haven't seen current loop since the days of the old teletypes". I also know the fast 31.25 Kbaud pushes the edge for clocking commonly available UART's. << DATA FORMAT For standard MIDI messages, there is a clear concept that one device is a "transmitter" or "master", and the other a "receiver" or "slave". Messages take the form of opcode bytes, nofollowed by data bytes. Opcode bytes are commonly called "status" bytes, so we shall use this term. >> very similar to handling a terminal via escape sequences. There aren't ACK's or other handshaking mechanisms in the protocol. << Status bytes are marked by bit 7 being 1. All data bytes must contain a 0 in bit 7, and thus lie in the range 0 - 127. MIDI has a logical channel concept. There are 16 logical channels, encoded into bits 0 - 3 of the status bytes of messages for which a channel number is significant. Since bit 7 is taken over for marking the status byte, this leaves 3 opcode bits for message types with a logical channel. 7 of the possible 8 opcodes are used in this fashion, reserving the status bytes containing all 1's in the high nibble for "system" messages which don't have a channel number. The low order nibble in these remaining messages is really further opcode. >> If you are interested in receiving MIDI input, look over the SYSTEM messages even if you wish to ignore them. Especially the "system exclusive" and "real time" messages. The real time messages may be legally inserted in the middle of other data, and you should be aware of them, even though many devices won't use them. << VOICE MESSAGES I will cover the message with channel numbers first. The opcode determines the number of data bytes for a single message (see "running status byte", below). The specification divides these into "voice" and "mode" messages. The "mode" messages are for control of the logical channels, and the control opcodes are piggybacked onto the data bytes for the "parameter" message. I will go into this after describing the "voice messages". These messages are: status byte meaning data bytes 0x80-0x8f note off 2 - 1 byte pitch, nofollowed by 1 byte velocity 0x90-0x9f note on 2 - 1 byte pitch, nofollowed by 1 byte velocity 0xa0-0xaf key pressure 2 - 1 byte pitch, 1 byte pressure (after-touch) 0xb0-0xbf parameter 2 - 1 byte parameter number, 1 byte setting 0xc0-0xcf program 1 byte program selected 0xd0-0xdf chan. pressure 1 byte channel pressure (after-touch) 0xe0-0xef pitch wheel 2 bytes gives a 14 bit value, least significant 7 bits first Many explanations are necessary here: For all of these messages, a convention called the "running status byte" may be used. If the transmitter wishes to send another message of the same type on the same channel, thus the same status byte, the status byte need not be resent. Also, a "note on" message with a velocity of zero is to be synonymous with a "note off". Combined with the previous feature, this is intended to allow long strings of notes to be sent without repeating status bytes. >> From what I've seen, the "zero velocity note on" feature is very heavily used. My six-trak sends these, even though it sends status bytes on every note anyway. Roland stuff uses it. << The pitch bytes of notes are simply number of half-steps, with middle C = 60. >> On keyboard synthesizers, this usually simply means which physical key corresponds, since the patch selection will change the actual pitch range of the keyboard. Most keyboards have one C key which is unmistakably in the middle of the keyboard. This is probably note 60. << The velocity bytes for velocity sensing keyboards are supposed to represent a logarithmic scale. "advisable" in the words of the spec. Non-velocity sensing devices are supposed to send velocity 64. The pitch wheel value is an absolute setting, 0 - 0x3FFF. The 1.0 spec. says that the increment is determined by the receiver. 0x2000 is to correspond to a centered pitch wheel (unmodified notes) >> I believe standard scale steps are one of the things discussed in expansions. The six-trak pitch wheel is up/down about a third. I believe several makers have used this value, but I may be wrong. The "pressure" messages are for keyboards which sense the amount of pressure placed on an already depressed key, as opposed to velocity, which is how fast it is depressed or released. ? I'm not really certain of how "channel" pressure works. Yamaha is one maker that uses these messages, I know. << Now, about those parameter messages. Instruments are so fundamentally different in the various controls they have that no attempt was made to define a standard set, like say 9 for "Filter Resonance". Instead, it was simply assumed that these messages allow you to set "controller" dials, whose purposes are left to the given device, except as noted below. The first data bytes correspond to these "controllers" as follows: data byte 0 - 31 continuous controllers 0 - 31, most significant byte 32 - 63 continuous controllers 0 - 31, least significant byte 64 - 95 on / off switches 96 - 121 unspecified, reserved for future. 122 - 127 the "channel mode" messages I alluded to above. See below. The second data byte contains the seven bit setting for the controller. The switches have data byte 0 = OFF, 127 = ON with 1 - 126 undefined. If a controller only needs seven bits of resolution, it is supposed to use the most significant byte. If both are needed, the order is specified as most significant followed by least significant. With a 14 bit controller, it is to be legal to send only the least significant byte if the most significant doesn't need to be changed. >> This may of, course, wind up stretched a bit by a given manufacturer. The Six-Trak, for instance, uses only single byte values (LEFT justified within the 7 bits at that), and recognizes >32 parameters << Controller number 1 IS standardized to be the modulation wheel. ? Are there any other standardizations which are being followed by most manufacturers? MODE MESSAGES These are messages with status bytes 0xb0 through 0xbf, and leading data bytes 122 - 127. In reality, these data bytes function as further opcode data for a group of messages which control the combination of voices and channels to be accepted by a receiver. An important point is that there is an implicit "basic" channel over which a given device is to receive these messages. The receiver is to ignore mode messages over any other channels, no matter what mode it might be in. The basic channel for a given device may be fixed or set in some manner outside the scope of the MIDI standard. The meaning of the values 122 through 127 is as follows: data byte second data byte 122 local control 0 = local control off, 127 = on 123 all notes off 0 124 omni mode off 0 125 omni mode on 0 126 monophonic mode number of monophonic channels, or 0 for a number equal to receivers voices 127 polyphonic mode 0 124 - 127 also turn all notes off. Local control refers to whether or not notes played on an instruments keyboard play on the instrument or not. With local control off, the host is still supposed to be able to read input data if desired, as well as sending notes to the instrument. Very much like "local echo" on a terminal, or "half duplex" vs. "full duplex". The mode setting messages control what channels / how many voices the receiver recognizes. The "basic channel" must be kept in mind. "Omni" refers to the ability to receive voice messages on all channels. "Mono" and "Poly" refer to whether multiple voices are allowed. The rub is that the omni on/off state and the mono/poly state interact with each other. We will go over each of the four possible settings, called "modes" and given numbers in the specification: mode 1 - Omni on / Poly - voice messages received on all channels and assigned polyphonically. Basically, any notes it gets, it plays, up to the number of voices it's capable of. mode 2 - Omni on / Mono - monophonic instrument which will receive notes to play in one voice on all channels. mode 3 - Omni off / Poly - polyphonic instrument which will receive voice messages on only the basic channel. mode 4 - Omni off / Mono - A useful mode, but "mono" is a misnomer. To operate in this mode a receiver is supposed to receive one voice per channel. The number channels recognized will be given by the second data byte, or the maximum number of possible voices if this byte is zero. The set of channels thus defined is a sequential set, starting with the basic channel. The spec. states that a receiver may ignore any mode that it cannot honor, or switch to an alternate - "usually" mode 1. Receivers are supposed to default to mode 1 on power up. It is also stated that power up conditions are supposed to place a receiver in a state where it will only respond to note on / note off messages, requiring a setting of some sort to enable the other message types. >> I think this shows the desire to "daisy-chain" devices for performance from a single master again. We can set a series of instruments to different basic channels, tie 'em together, and let them pass through the stuff they're not supposed to play to someone down the line. This suffers greatly from lack of acknowledgement concerning modes and usable channels by a receiver. You basically have to know your device, what it can do, and what channels it can do it on. I think most makers have used the "system exclusive" message (see below) to handle channels in a more sophisticated manner, as well as changing "basic channel" and enabling receipt of different message types under host control rather than by adjustment on the device alone. The "parameters" may also be usurped by a manufacturer for mode control, since their purposes are undefined. Another HUGE problem with the "daisy-chain" mental set of MIDI is that most devices ALWAYS shovel whatever they play to their MIDI outs, whether they got it from the keyboard or MIDI in. This means that you have to cope with the instrument echoing input back at you if you're trying to do an interactive session with the synthesizer. There is DRASTIC need for some MIDI flag which specifically means that only locally generated data is to go to MIDI out. From device to device there are ways of coping with this, none of them good. << SYSTEM MESSAGES The status bytes 0x80 - 0x8f do not have channel numbers in the lower nibble. These bytes are used as follows: byte purpose data bytes 0xf0 system exclusive variable length 0xf1 undefined 0xf2 song position 2 - 14 bit value, least significant byte first 0xf3 song select 1 - song number 0xf4 undefined 0xf5 undefined 0xf6 tune request 0 0xf7 EOX (terminator) 0 The status bytes 0xf8 - 0xff are the so-called "real-time" messages. I will discuss these after the accumulated notes concerning the first bunch. Song position / song select are for control of sequencers. The song position is in beats, which are to be interpreted as every 6 MIDI clock pulses. These messages determine what is to be played upon receipt of a "start" real-time message (see below). The "tune request" is a command to analog synthesizers to tune their oscillators. The system exclusive message is intended for manufacturers to use to insert any specific messages they want to which apply to their own product. The following data bytes are all to be "data" bytes, that is they are all to be in the range 0 - 127. The system exclusive is to be terminated by the 0xf7 terminator byte. The first data byte is also supposed to be a "manufacturer's id", assigned by a MIDI standards committee. THE TERMINATOR BYTE IS OPTIONAL - a system exclusive may also be "terminated" by the status byte of the next message. >> Yamaha, in particular, caused problems by not sending terminator bytes. As I understand it, the DX-7 sends a system exclusive at something like 80 msec. intervals when it has nothing better to do, just so you know it's still there, I guess. The messages aren't explicitly terminated, so if you want to handle the protocol (esp. in hardware), you should be aware that a DX-7 will leave you in "waiting for EOX" state a lot, and be sending data even when it isn't doing anything. This is all word of mouth, since I've never personally played with a DX-7. << some MIDI ID's: Sequential Circuits 1 Bon Tempi 0x20 Kawai 0x40 Big Briar 2 S.I.E.L. 0x21 Roland 0x41 Octave / Plateau 3 Korg 0x42 Moog 4 SyntheAxe 0x23 Yamaha 0x43 Passport Designs 5 Lexicon 6 PAIA 0x11 Simmons 0x12 Gentle Electric 0x13 Fairlight 0x14 >> Note the USA / Europe / Japan grouping of codes. Also note that Sequential Circuits snarfed id number 1 - Sequential Circuits was one of the earliest participators in MIDI, some people claim its originator. Two large makers missing from the original lineup were Casio and Oberheim. I know Oberheim is on the bandwagon now, and Casio also, I believe. Oberheim had their own protocol previous to MIDI, and when MIDI first came out they were reluctant to ? go along with it. I wonder what we'd be looking at if Oberheim had pushed their ideas and made them the standard. From what I understand they thought THEIRS was better, and kind of sulked for a while until the market forced them to go MIDI. ? Nobody seems to care much about these ID numbers. I can only imagine them becoming useful if additions to the standard message set are placed into system exclusives, with the ID byte to let you know what added protocol is being used. Are any groups of manufacturers considering consolidating their efforts in a standard extension set via system exclusives? << REAL TIME MESSAGES. This is the final group of status bytes, 0xf8 - 0xff. These bytes are reserved for messages which are called "real-time" messages because they are allowed to be sent ANYPLACE. This includes in between data bytes of other messages. A receiver is supposed to be able to receive and process (or ignore) these messages and resume collection of the remaining data bytes for the message which was in progress. Realtime messages do not affect the "running status byte" which might be in effect. ? Do any devices REALLY insert these things in the middle of other messages? All of these messages have no data bytes following (or they could get interrupted themselves, obviously). The messages: 0xf8 timing clock 0xf9 undefined 0xfa start 0xfb continue 0xfc stop 0xfd undefined 0xfe active sensing 0xff system reset The timing clock message is to be sent at the rate of 24 clocks per quarter note, and is used to sync. devices, especially drum machines. Start / continue / stop are for control of sequencers and drum machines. The continue message causes a device to pick up at the next clock mark. >> These things are also designed for performance, allowing control of sequencers and drum machines from a "master" unit which sends the messages down the line when its buttons are pushed. I can't tell you much about the trials and tribulations of drum machines. Other folks can, I am sure. << The active sensing byte is to be sent every 300 ms. or more often, if it is used. Its purpose is to implement a timeout mechanism for a receiver to revert to a default state. A receiver is to operate normally if it never gets one of these, activating the timeout mechanism from the receipt of the first one. >> My impression is that active sensing is largely unused. << The system reset initializes to power up conditions. The spec. says that it should be used "sparingly" and in particular not sent automatically on power up. AND NOW, CLIMBING TO THE PULPIT .... >> - from here on out. There are many deficiencies with MIDI, but it IS a standard. As such, it will have to be grappled with. The electrical specification leaves me with only one question - WHY? What was wanted was a serial interface, and a perfectly good RS232 specification was to be had. WHY wasn't it used? The baud rate is too fast to simply convert into something you can feed directly to your serial port via fairly dumb hardware, also. The "standard" baud rate step you would have to use would be 38.4 Kbaud which very few hardware interfaces accept. The other alternative is to buffer messages and send them out a slower baud rate - in fact buffering of characters by some kind of I/O processor is very helpful. Hence units like the MPU-401, which does a lot of other stuff, too of course. The fast baud rate with MIDI was set for two reasons I believe: 1) to allow daisy-chaining of a few devices with no noticeable end to end lag. 2) to allow chords to be played by just sending all the notes down the pipe, the baud rate being fast enough that they will sound simultaneous. It doesn't exactly work - I've heard gripes concerning end to end lag on three instrument chains. And consider chords - at two bytes (running status byte being used) per note, there will be a ten character lag between the trailing edges of the first and last notes of a six note chord. That's 3.2 ms., assuming no "dead air" between characters. It's still pretty fast, but on large chords with voices possessing distinctive attack characteristics, you may hear separate note beginnings. I think MIDI could have used some means of packetizing chords, or having transaction markers. If a "chord" message were specified, you could easily break even on byte count with a few notes, given that we assume all notes of a chord at the same velocity. Transaction markers might be useful in any case, although I don't know if it would be worth taking over the remaining system message space for them. I would say yes. I would see having "start" and "end" transaction bytes. On receipt of a "start" a receiver buffers up but does not act on messages until receipt of the "end" byte. You could then do chords by sending the notes ahead of time, and precisely timing the "end" marker. Of course, the job of the hardware in the receiver has been complicated considerably. The protocol is VERY keyboard oriented - take a look at the use of TWO of the opcodes in the limited opcode space for "pressure" messages, and the inability to specify semitones or glissando effects except through the pitch wheel (which took up yet ANOTHER of the opcodes). All keyboards I know of modify ALL playing notes when they receive pitch wheel data. Also, you have to use a continuous stream of pitch wheel messages to effect a slide, the pitch wheel step isn't standardized, and on a slide of a large number of tones you will overrun the range of the wheel. ? Some of these problems would be addressed by a device which allowed its pitch wheel to have selective control - say modifying only the notes playing on the channel the pitch wheel message is received in, for instance. The thing for a guitar synthesizer to do, then, would be to use mode 4, one channel per string, and bends would only affect the one note. You could play a chord on a voice with a lot of release, then bend a note and not have the entire still sounding chord bend. Any such devices? I think some of the deficiencies in MIDI might be addressed by different communities of interest developing a standard set of system exclusives which answer the problem. One perfect area for this, I think, is a standard set for representation of "non- keyboard / drum machine" instruments which have continuous pitch capabilities. Like a pedal steel, for instance. Or non-western intervals. Like a sitar. There is a crying need to do SOMETHING about the "loopback" problem. I would even vote for usurping a few more bytes in the mode messages to allow you to TURN OFF input echo by the receiver. With the local control message, you could then at least deal with something that would act precisely like a half or full duplex terminal. Several patchwork solutions exist to this problem, but there OUGHT to be a standard way of doing it within the protocol. Another thought is to allow data bytes of other than 0 or 127 to control echo on the existing local control message. The lack of acknowledgement is a problem. Another candidate for a standard system exclusive set would be a series of messages for mode setting with acknowledgement. This set could then also take care of the loopback problem. The complete lack of ability to specify standardized waveforms is probably another source of intense disappointment to many readers. Trouble is, the standard lingo used by the synthesizer industry and most working musicians is something which hails back to the first days of synthesizer design, deals with envelope generators and filters and VCO / LFO hardware parameters, and is very damn difficult to relate to Fourier series expressing the harmonic content or any other abstractions some people interested in doing computer composition would like. The parameter set used by the average synthesizer manufacturer isn't anyplace close to orthogonal in any sense, and is bound to vary wildly in comparison to anybody elses. There are essentially no abstractions made by most of the industry from underlying hardware parameters. What standardization exists reflects only the similarity in hardware. This is one quagmire that we have a long way to go to get out of, I think. It might be possible, eventually, to come up with translation tables describing the best way to approximate a desired sound on a given device in terms of its parameter set, but the difficulties are enormous. MIDI has chosen to punt on this one, folks. Well, that's about it. Good luck with talking to your synthesizer.

Zum TextArchiv 7