***************************************************************** T H E M I D I F O R M A T G U I D E S C O L L E C T I O N ***************************************************************** combined by Alfred Faust (alfred.j.faust@gmx.de) ################################################################################ I've made this collection for all peoples, who are interested in programming for MIDI. But I can't give you any guarantees for completness or correctness of this guides. !!!!! NO LIABILITY FOR CONSEQUENTIAL DAMAGES !!!!! You know - the DISCLAIMER ... it must be I'm a poor men ..... ;) But I work with this explanations for a long time, and my meaning is : it's all correct. It will be a good idea to print out the whole document for reading. ################################################################################ You will find in this File: =========================== I. Standard MIDI-File Format by Dave Oppenheim (© 1988) II. General MIDI Level Spec by Jeff Mallory (© 1992) III. Brief Overview of Proposed General MIDI Level 1 Spec (after "Electronic Musician", 8/91 issue) IV. MIDI sample dump standard (© 1986 by the MIDI Manufacturers Association and the Japanese MIDI Standards Committee) V. The USENET MIDI Primer by Bob McQueer ################################################################################ [This document is Dave Oppenheim's current version of the MIDI file specification, as sent to those who have participated in its development. The consensus seems to be to submit this to the MIDI Manufacturers' Association as version 1.0. I apologize for any loss of clarity that might have occurred in the conversion from a Microsoft Word document to this pure text file. I have removed some of the discussion about recent changes to the specification in order to keep the file size reasonable.--Doug Wyatt] ################################################################################ Standard MIDI Files 0.06 March 1, 1988 0 Introduction This describes a proposed standard MIDI file format. 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, nibbleized, 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. 1 Sequences, Tracks, Chunks: File Block Structure Sequence 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. On the Macintosh, data is passed either in the data fork of a file, or on the Clipboard. (The file type on the Macintosh for a file in this format will be "Midi".) On any other computer, the data is simply the contents of the file. This structure allows future chunk types to be designed which may easily be ignored if encountered by a program written before the chunk type is introduced. Your programs should expect alien chunks and treat them as if they weren't there. This proposal defines two types of chunks: a header chunk and a track chunk. 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 ... Track Data Format (MTrk chunk type) The MTrk chunk type is where actual song data is stored. It is simply a stream of MIDI events (and non-MIDI events), preceded by delta-time values. Some numbers in MTrk chunks are represented in a form called a variablelength 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: Number (hex) Representation (hex) 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 variablelength representation must fit in 32 bits in a routine to write variable-length numbers. Theoretically, larger numbers are possible, but 2 x 108 96ths of a beat at a fast tempo of 500 beats per minute is four days, long enough for any delta-time! Here is the syntax of an MTrk chunk: = + = 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 simultaneously, 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 may be omitted after the first byte. The first event in a file must specify status. Delta-time is not considered an event itself: it is an integral part of the specification. Notice that running status occurs across delta-times. 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 sysex events, running status is not allowed. 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. New for 0.06: programs must never ignore the length of a meta-event which they do recognize, and they shouldn't be surprised if it's bigger than they 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 a meta-event. is used to specify a MIDI system exclusive message, or as an "escape" to specify any arbitrary bytes to be transmitted. 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 at 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. To be able to handle situations like these, two forms of are provided: F0 F7 In both cases, is stored as a variable-length quantity. It is equal to the number of bytes following it, not including itself or the message type (F0 or F7), but all the bytes which follow, including any F7 at the end which is intended to be transmitted. The first form, with the F0 code, is used for syntactically complete system exclusive messages, or the first packet an a series Q that is, messages in which the F0 should be transmitted. The second form is used for the remainder of the packets within a syntactic sysex message, which do not begin with F0. Of course, the F7 is not considered part of the system exclusive message. Of course, just as in MIDI, running status is not allowed, in this case because the length is stored as a variable-length quantity which may or may not start with bit 7 set. (New to 0.06) 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. This principle is repeated and illustrated in the paragraphs below. The vast majority of system exclusive messages will just use the F0 format. 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. As mentioned above, 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. For special situations when a single system exclusive message is split up, with parts of it being transmitted at different times, such as in a Casio CZ patch transfer, or the FB-01's "system exclusive mode", the F7 form of sysex event is used for each packet except the first. None of the packets would end with an F7 except the last one, which must end with an F7. There also must not be any transmittable MIDI events inbetween the packets of a multi-packet system exclusive message. Here is an example: suppose the bytes F0 43 12 00 were to be sent, followed by a 200-tick delay, followed by the bytes 43 12 00 43 12 00, followed by a 100-tick delay, followed 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 The F7 event may also be used as an "escape" to transmit any bytes whatsoever, including real-time bytes, song pointer, or MIDI Time Code, which are not permitted normally in this specification. No effort should be made to interpret the bytes used in this way. Since a system exclusive message is not being transmitted, it is not necessary or appropriate to end the F7 event with an F7 in this case. 2 Header Chunk The header chunk at the beginning of the file specifies some basic information about the data in the file. The data section contains three 16-bit words, stored high byte first (of course). 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 first word, format, 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 simultaneous tracks (or MIDI outputs) of a sequence 2 the file contains one or more sequentially independent single-track patterns The next word, , is the number of track chunks in the file. The third word, , is the division of a quarter-note represented by the delta-times in the file. (IF division is negative, it represents the division of a second represented by the delta-times in the file, so that the track can represent events occurring in actual time instead of metrical time. It is represented in the following way: the upper byte is one of the four values -24, -25, -29, or -30, corresponding to the four standard SMPTE and MIDI time code formats, and represents the number of frames per second. 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 system allows exact specification of time-code-based tracks, but also allows millisecond-based tracks by specifying 25 frames/sec and a resolution of 40 units per frame.) Format 0, that is, one multi-channel track, is the most interchangeable representation of data. One application of MIDI files is a simple single-track player in a program which needs to make synthesizers make sounds, but which is primarily concerned 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. Programs which support several simultaneous tracks should be able to save and read data in format 1, a vertically one-dimensional form, that is, as a collection of tracks. Programs which support several independent patterns should be able to save and read data in format 2, a horizontally one-dimensional form. Providing these minimum capabilities will ensure maximum interchangeability. MIDI files can express tempo and time signature, and they have been chosen to do so for transferring tempo maps from one device to another. 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 (starting in 0.04) be stored as the first track. It is polite to a tempo map reader to offer 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 don'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 metaevents should be contained in the first track. In format 2, each of the temporally independent 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 reading an unfamiliar format ID should return an error to the user rather than trying to read further. 3 Meta-Events A few meta-events are defined herein. It is not required for every program to support every meta-event. Meta-events initially defined include: FF 00 02 ssss 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. The number in this track corresponds to the sequence number in the new Cue message discussed at the summer 1987 MMA meeting. 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' locations 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 character 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. (New for 0.06 ). 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 first 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 separate 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 rehearsal 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 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 it has an exact 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". Representing tempos as time per beat instead of beat per time allows absolutely 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 Q this convention is intended to guarantee, or at least increase the likelihood, of compatibility with other synchronization devices so that a time signature/tempo map stored in this format may easily be transferred to another device. FF 54 05 hr mn se fr ff SMPTE Offset (New in 0.06 - SMPTE Format specification) 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 negative 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 quarternote (24 MIDI Clocks). This was added because there are already multiple programs which allow the 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), 32 MIDI clocks per dotted-quarter (24 hex!), and eight notated 32nd-notes per MIDI 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. However, as this is an interchange format, growth of the spec proper is preferred to use of this event type. This type of event 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 separated 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. The contents of the MIDI stream represented by this example are broken down here: Delta Event Other Bytes Comment Time Code (deci as mal) (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 07 A1 20 500000 3 bytes: 500,000 5 sec per quarter-note 0 C0 05 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: 4D 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 that 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 end of track 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 5 MIDI Transmission of MIDI Files Since it is inconvenient to exchange disks between different computers, and since many computers which will use this format will have a MIDI interface anyway, MIDI seems like a perfect way to send these files from one computer to another. And, while we're going through all the trouble to make a way of sending MIDI Files, it would be nice if they could send any files (like sampled sound files, text files, etc.) Goals The transmission protocol for MIDI files should be reasonably efficient, should support fast transmission for computers which are capable of it, and slower transmission for less powerful ones. It should not be impossible to convert a MIDI File to or from an arbitrary internal representation on the fly as it is transmitted, but, as long as it is not too difficult, it is very desirable to use a generic method so that any file type could be accommodated. To make the protocol efficient, the MIDI transmission of these files will take groups of seven 8-bit bytes and transmit them as eight 7-bit MIDI data bytes. This is certainly in the spirit of the rest of this format (keep it small, because it's not that hard to do). To accommodate a wide range of transmission speeds, files will be transmitted in packets with acknowledge -- this allows data to be stored to disk as it is received. If the sender does not receive a response from a reader in a certain amount of time, it can assume an open-loop situation, and then just continue. The last edition of MIDI Files contained a specialized protocol for sending just MIDI Files. To meet a deadline, unfortunately I don't have time right now to propose a new generalized protocol. This will be done within the next couple of months. I would welcome any proposals anyone else has, and would direct your attention to the proposal from Ralph Muha of Kurzweil, available in a recent MMA bulletin, and also directly from him. -- Michael S. Czeiszperger | "The only good composer is a dead composer" Systems Analyst | Snail: 2015 Neil Avenue (614) The Ohio State University | Columbus, OH 43210 292- ARPA:czei@accelerator.eng.ohio-state.edu PAN:CZEI 0161 ################################################################################ MIDI 1.0 Specification: Status Data Byte(s) Description D7----D0 D7----D0 ------------------------------------------------------------------------- Channel Voice Messages ------------------------------------------------------------------------- 1000cccc 0nnnnnnn Note Off event. 0vvvvvvv This message is sent when a note is released (ended). (nnnnnnn) is the note number. (vvvvvvv) is the velocity. 1001cccc 0nnnnnnn Note On event. 0vvvvvvv This message is sent when a note is depressed (start). (nnnnnnn) is the note number. (vvvvvvv) is the velocity. 1010cccc 0nnnnnnn Polyphonic Key Pressure (After-touch). 0vvvvvvv This message is sent when the pressure (velocity) of a previously triggered note changes. (nnnnnnn) is the note number. (vvvvvvv) is the new velocity. 1011cccc 0ccccccc Control Change. 0vvvvvvv This message is sent when a controller value changes. Controllers include devices such as pedals and levers. Certain controller numbers are reserved for specific purposes. See Channel Mode Messages. (ccccccc) is the controller number. (vvvvvvv) is the new value. 1100cccc 0ppppppp Program Change. This message sent when the patch number changes. (ppppppp) is the new program number. 1101nnnn 0ccccccc Channel Pressure (After-touch). This message is sent when the channel pressure changes. Some velocity-sensing keyboards do not support polyphonic after-touch. Use this message to send the single greatest velocity (of all te current depressed keys). (ccccccc) is the channel number. 1110nnnn 0lllllll Pitch Wheel Change. 0mmmmmmm This message is sent to indicate a change in the pitch wheel. The pitch wheel is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits. ------------------------------------------------------------------------- Channel Mode Messages (See also Control Change, above) ------------------------------------------------------------------------- 1011nnnn 0ccccccc Channel Mode Messages. 0vvvvvvv This the same code as the Control Change (above), but implements Mode control by using reserved controller numbers. The numbers are: Local Control. When Local Control is Off, all devices on a given channel will respond only to data received over MIDI. Played data, etc. will be ignored. Local Control On restores the functions of the normal controllers. c = 122, v = 0: Local Control Off c = 122, v = 127: Local Control On All Notes Off. When an All Notes Off is received, all oscillators will turn off. c = 123, v = 0: All Notes Off (See text for description of actual mode commands.) c = 124, v = 0: Omni Mode Off c = 125, v = 0: Omni Mode On c = 126, v = M: Mono Mode On (Poly Off) where M is the number of channels (Omni Off) or 0 (Omni On) c = 127, v = 0: Poly Mode On (Mono Off) (Note: These four messages also cause All Notes Off) .pa ------------------------------------------------------------------------- System Common Messages ------------------------------------------------------------------------- 11110000 0iiiiiii System Exclusive. 0ddddddd This message makes up for all that MIDI .. doesn't support. (iiiiiii) is a seven .. bit Manufacturer's I.D. code. If the 0ddddddd synthesizer recognizes the I.D. code as 11110111 its own, it will listen to the rest of the message (ddddddd). Otherwise, the message will be ignored. System Exclusive is used to send bulk dumps such as patch parameters and other non-spec data. (Note: Real-Time messages ONLY may be interleaved with a System Exclusive.) 11110001 Undefined. 11110010 0lllllll Song Position Pointer. 0mmmmmmm This is an internal 14 bit register that holds the number of MIDI beats (1 beat= six MIDI clocks) since the start of the song. l is the LSB, m the MSB. 11110011 0sssssss Song Select. The Song Select specifies which sequence or song is to be played. 11110100 Undefined. 11110101 Undefined. 11110110 Tune Request. Upon receiving a Tune Request, all analog sythesizers should tune their oscillators. 11110111 End of Exclusive. Used to terminate a System Exclusive dump (see above). .pa ------------------------------------------------------------------------- System Real-Time Messages ------------------------------------------------------------------------- 11111000 Timing Clock. Sent 24 times per quarter note when synchronization is required (see text). 11111001 Undefined. 11111010 Start. Start the current sequence playing. (This message will be followed with Timing Clocks). 11111011 Continue. Continue at the point the sequence was Stopped. 11111100 Stop. Stop the current sequence. 11111101 Undefined. 11111110 Active Sensing. Use of this message is optional. When initially sent, the receiver will expect to receive another Active Sensing message each 300ms (max), or it will be assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation. 11111111 Reset. Reset all receivers in the system to power-up status. This should be used sparingly, preferably under manual control. In particular, it should not be sent on power-up. -- Greg, lee@uhccux.uhcc.hawaii.edu Date: Tue, 14 Jan 92 23:01:16 EST From: jeff@millie.loc.gov (Jeff Mallory) Subject: General MIDI Level Spec ################################################################################ **** 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) ################################################################################ MIDI SAMPLE DUMP STANDARD 1) INTRODUCTION The MIDI SDS was adopted in January 1986 by the MIDI Manufacturers Association and the Japanese MIDI Standards Committee. The SDS defines the standard method for transfer of sound sample data between MIDI-equipped devices. Sample dumps may be accomplished with either an 'open loop' or 'closed loop' system. The open loop method simply involves the straight dump of all sample data from its source to the destination, with no timeouts, packet acknowledgements, or any other form of handshaking, much as in the manner of a sysex bulk dump, usually intiated at the source. The closed loop method allows the use of handshaking messages between the dump source and destination, and usually places the dump process under the control of the slave, to allow it time to process the incoming data as necessary. As with any standard, it can not be assumed that a device adheres to it unless the accompanying documentation specifically indicates it. Even then, it is best to check its conformity with non-critical data. 2) SPEC: SAMPLE DUMP FORMATS DUMP HEADER: F0 7E cc 01 ss ss ee ff ff ff gg gg gg hh hh hh ii ii ii jj F7 where cc = channel number ss ss = sample number (LSB first) ee = sample format (number of significant bits; 8->28) ff ff ff = sample period (1/sample rate) in nanoseconds (LSB first) gg gg gg = sample length, in words hh hh hh = sustain loop start point (word number) (LSB first) ii ii ii = sustain loop end point (word number) (LSB first) jj = loop type (00:forwards only; 01:alternating) DATA PACKET: F0 7E cc 02 kk <120 bytes> mm F7 where cc = channel number kk = running packet count (00->7F) mm = checksum (XOR of 7E, cc, 02, kk <120 bytes>) The total size of a data packet is 127 bytes. This is to avoid overflow of the MIDI input buffer of a device that may want to receive an entire packet before processing it. A data packet consists of its own header, a packet number, 120 bytes of data, a checksum, and an EOX. The packet number begins at 00 and increments with each new packet. It resets to 00 after it reaches 7F, and continues counting. The packet number is used by the receiver to distinguish between a new data packet, or a resend of a previous packet. The packet number is followed by 120 bytes of data, which form 60, 40, or 30 words (MSB first for multiword samples), depending on the length of a single data sample. Each data byte hold seven bits, with the msb in each byte SET to 0, in order to conform to the requirements of MIDI data transmission. Information is left justified within the 7-bit bytes, and unused bits are filled with 0. Example: Assume a data point in the memory of a 16-bit sampler, with the value 87E5. In binary, that would be 1000 0111 1110 0101 and would be encoded as the following MIDI data stream: 01000011 01111001 00100000 The checksum is the running XOR of all the data after the SYSEX byte, up to but not including the checksum itself. 3) SPEC: SAMPLE DUMP MESSAGES DUMP REQUEST: F0 7E cc 03 ss ss F7 where cc = channel number ss ss = sample number requested (LSB first) Upon receiving the request, the sampler checks the sample number to see if it is within legal range. If it is not, the request is ignored. If it is, the sample dump is started. One packet at a time is sent, under control of the handshaking messages outlined below. HANDSHAKING MESSAGES: For all below: cc = channel number pp = packet number Packet numbers are included in the handshaking messages to accomodate machines that have the intelligence to re-transmit specific packets after an entire dump is finished, or if synchronization is lost. ACK : F0 7E cc 7F pp F7 Means last packet was recieved correctly (checksum OK, etc), please send next one. Packet number is packet being acknowledged as correct. NAK : F0 7E cc 7E pp F7 Means last packet not received correctly, please send again. Packet number is packet being rejected. CANCEL : F0 7E cc 7D pp F7 Means abort dump immediately. Packet number is packet on WHICH abort occurs. WAIT : F0 7E cc 7C pp F7 Means pause dump indefinitely, until next message is sent. Allows the unit recieving the dump to perform other functions (disk access, etc), before receiving the remainder of the dump. The next message it sends (eg ACK, ABORT) will determine if the dump continues or aborts. 4) DUMP PROCEDURE: MASTER (DUMP SOURCE) Once a dump has been requested, either via MIDI or through the front panel, the DUMP HEADER is sent. After sending the header, the master must time out for at least two seconds, to allow the receiver to decide if it will accept this sample (has enough memory, etc). IF it receives a CANCEL, within this time, it should abort immediately. If it receives an CAK, it will start sending packets immediately. If it receives a WAIT, it pauses until another message is received, and then processes that mesage normally. If nothing is recieved within the timeout, an open loop is assumed, and the dump starts with the first packet. After sending each packet, the master should time out for at least 20 milliseconds and watch its MIDI In. If an ACK is received, it sends the next packet immediately. If it receives an NAK, and the packet number matches the number of the last packet sent, it resend that packet If the packet numbers don't match, and the device is incapable of sending packets out of order, the NAK will be ignored. IF a WAIT is received, the master should watch its MIDI In port indefinitely for another ACK, NAK, or CANCEL message, which it should then process normally. IF no messages are received within 20 milliseconds of the transmission of a packet, the master may assume an open loop configuration, and send the next packet. This process continues until there are less than 121 data bytes to send. The final packet will still consist of 120n bytes, regardless of how many significant bytes actually remain, and the unused bytes will be filled with zeroes. The receiver should handshake after receiving the last packet. 5) DUMP PROCEDURE: SLAVE (DUMP DESTINATION) When receiving a sample dump, a device should keep a running checksum during reception. If its checksum matches the checksum in the data packet, it will send an ACK and wait for the next packet. If it does not match, it will send an NAK containing the number of the packet that caused the error, and wait for the next packet. If, after sending an NAK, the packet number of the next packet doesn't match the previous packet number (the one that was NAK'd), and the unit is not capable of accepting packets out of order, the error is ignored and the dump continues as if the checksums had matched. IF a receiver runs out of memory before the dumpo is completed, it should send a CANCEL to stop the dump. 6) SDS OVERVIEW SAMPLE DUMP DATA FORMAT: DUMP HEADER: Sysex ID: Universal Non-Real Time Channel Number Sub ID: Header Sample Number (2 bytes, LSB first) Sample Format Sample Period (3 bytes, LSB first) Sample Length (3 bytes, LSB first) Sustain Loop Start Point (3 bytes, LSB first) Sustain Loop End Point (3 bytes, LSB first) Loop Type Eox SAMPLE DUMP DATA FORMAT: DATA PACKET: Sysex ID: Universal Non-Real Time Channel Number Sub ID: Data Packet Packet Number Sample Data (120 bytes) Checksum Eox SAMPLE DUMP MESSAGES: DUMP REQUEST: Sysex ID: Universal Non-Real Time Channel Number Sub ID: Dump Request Sample Number (2 bytes, LSB first) Eox SAMPLE DUMP MESSAGES: HANDSHAKING FLAGS: Sysex ID: Universal Non-Real Time Channel Number Sub ID: ACK or NAK or CANCEL or WAIT Packet Number Eox ################################################################################ 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 "barebones" 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 dispositions, 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, followed 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, followed by 1 byte velocity 0x90-0x9f note on 2 - 1 byte pitch, followed 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 "nonkeyboard / 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. Bob McQueer 22 Bcy, 3151 All rites reversed. Reprint what you like.