home *** CD-ROM | disk | FTP | other *** search
/ Sound Sensations! / sound_sensations.iso / midifile / mididox / midi.doc
Text File  |  1991-02-28  |  35KB  |  735 lines
  1. Standard MIDI-File Format Spec. 1.1 ---
  2. ---------------------------------------
  3.  
  4. Distributed by:
  5. The International MIDI Association
  6. 5316 W. 57th St.
  7. Los Angeles, CA  90056
  8. (213) 649-6434
  9.  
  10.  
  11. 0 - Introduction
  12.  
  13. The document outlines the specification for MIDI Files. The purpose of MIDI
  14. Files  is to provide a way of interchanging time-stamped MIDI data  between
  15. different  programs on the same or different computers. One of the  primary
  16. design goals is compact representation, which makes it very appropriate for
  17. disk-based  file format, but which might make it inappropriate for  storing
  18. in  memory  for  quick access by a sequencer program.  (It  can  be  easily
  19. converted to a quickly-accessible format on the fly as files are read in or
  20. written  out.) It is not intended to replace the normal file format of  any
  21. program, though it could be used for this purpose if desired.
  22.  
  23. MIDI Files contain one or more MIDI streams, with time information for each
  24. event.  Song,  sequence,  and track structures, tempo  and  time  signature
  25. information,   are  all  supported.  Track  names  and  other   descriptive
  26. information may be stored with the MIDI data. This format supports multiple
  27. tracks  and  multiple  sequences so that if the user  of  a  program  which
  28. supports multiple tracks intends to move a file to another one, this format
  29. can allow that to happen.
  30.  
  31. This  spec defines the 8-bit binary data stream used in the file. The  data
  32. can  be stored in a binary file, nibbilized, 7-bit-ized for efficient  MIDI
  33. transmission,  converted  to  Hex ASCII, or translated  symbolically  to  a
  34. printable  text  file. This spec addresses what's in the 8-bit  stream.  It
  35. does  not address how a MIDI File will be transmitted over MIDI. It is  the
  36. general  feeling  that a MIDI transmission protocol will be  developed  for
  37. files in general and MIDI Files will use this scheme.
  38.  
  39.  
  40. 1 - Sequences, Tracks, Chunks: File Block Structure
  41.  
  42. CONVENTIONS
  43. In this document, bit 0 means the least significant bit of a byte, and  bit
  44. 7 is the most significant.
  45.  
  46. Some numbers in MIDI Files are represented is a form called VARIABLE-LENGTH
  47. QUANTITY.  These numbers are represented 7 bits per byte, most  significant
  48. bits first. All bytes except the last have bit 7 set, and the last byte has
  49. bit  7  clear. If the number is between 0 and 127, it is  thus  represented
  50. exactly as one byte.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Here   are  some  examples  of  numbers  represented   as   variable-length
  60. quantities:
  61.  
  62.           00000000            00
  63.           00000040            40
  64.           0000007F            7F
  65.           00000080            81 00
  66.           00002000            C0 00
  67.           00003FFF            FF 7F
  68.           00004000            81 80 00
  69.           00100000            C0 80 00
  70.           001FFFFF            FF FF 7F
  71.           00200000            81 80 80 00
  72.           08000000            C0 80 80 00
  73.           0FFFFFFF            FF FF FF 7F
  74.  
  75. The largest number which is allowed is 0FFFFFFF so that the variable-length
  76. representations  must fit in 32 bits in a routine to write  variable-length
  77. numbers. Theoretically, larger numbers are possible, but 2 x 10^8 96ths  of
  78. a  beat at a fast tempo of 500 beats per minute is four days,  long  enough
  79. for any delta-time!
  80.  
  81. FILES
  82. To  any file system, a MIDI File is simply a series of 8-bit bytes. On  the
  83. Macintosh, this byte stream is stored in the data fork of a file (with file
  84. type  'MIDI'),  or  on the Clipboard (with data type  'MIDI').  Most  other
  85. computers  store  8-bit  byte  streams  in  files  --  naming  or   storage
  86. conventions for those computers will be defined as required.
  87.  
  88.  
  89. CHUNKS
  90. MIDI Files are made up of -chunks-. Each chunk has a 4-character type and a
  91. 32-bit  length, which is the number of bytes in the chunk.  This  structure
  92. allows future chunk types to be designed which may be easily be ignored  if
  93. encountered by a program written before teh chunk type is introduced.  Your
  94. programs  should  EXPECT  alien chunks and treat them as  if  they  weren't
  95. there.
  96.  
  97. Each chunk begins with a 4-character ASCII type. It is followed by a 32-bit
  98. length,  most significant byte first (a length of 6 is stored as 00  00  00
  99. 06).  This length refers to the number of bytes of data which  follow:  the
  100. eight bytes of type and length are not included. Therefore, a chunk with  a
  101. length of 6 would actually occupy 14 bytes in the disk file.
  102.  
  103. This  chunk  architecture is similar to that used by Electronic  Arts'  IFF
  104. format,  and  the chunks described herin could easily be placed in  an  IFF
  105. file.  The  MIDI  File itself is not an IFF file:  it  contains  no  nested
  106. chunks, and chunks are not constrained to be an even number of bytes  long.
  107. Converting  it to an IFF file is as easy as padding odd length chunks,  and
  108. sticking the whole thing inside a FORM chunk.
  109.  
  110. MIDI  Files contain two types of chunks: header chunks and track chunks.  A
  111. -header-  chunk provides a minimal amount of information pertaining to  the
  112. entire MIDI file. A -track- chunk contains a sequential stream of MIDI data
  113. which  may contain information for up to 16 MIDI channels. The concepts  of
  114. multiple tracks, multiple MIDI outputs, patterns, sequences, and songs  may
  115. all be implemented using several track chunks.
  116.  
  117. A  MIDI File always starts with a header chunk, and is followed by  one  or
  118. more track chunks.
  119.  
  120.           MThd  <length of header data>
  121.           <header data>
  122.           MTrk  <length of track data>
  123.           <track data>
  124.           MTrk  <length of track data>
  125.           <track data>
  126.           . . .
  127.  
  128.  
  129. 2 - Chunk Descriptions
  130.  
  131. HEADER CHUNKS
  132. The  header  chunk  at  the beginning of  the  file  specifies  some  basic
  133. information  about the data in the file. Here's the syntax of the  complete
  134. chunk:
  135.  
  136. <Header Chunk> = <chunk type><length><format><ntrks><division>
  137.  
  138. As  described  above,  <chunk type> is the four  ASCII  characters  'MThd';
  139. <length> is a 32-bit representation of the number 6 (high byte first).
  140.  
  141. The data section contains three 16-bit words, stored most-significant  byte
  142. first.
  143.  
  144. The  first word, <format>, specifies the overall organization of the  file.
  145. Only three values of <format> are specified:
  146.  
  147. 0-the file contains a single multi-channel track
  148. 1-the file contains one or more simultanious tracks (or MIDI outputs) of  a
  149.   sequence
  150. 2-the  file  contains  one or more  sequentially  independant  single-track
  151.   patterns
  152.  
  153. More information about these formats is provided below.
  154.  
  155. The next word, <ntrks>, is the number of track chunks in the file. It  will
  156. always be 1 for a format 0 file.
  157.  
  158. The  third word, <division>, specifies the meaning of the  delta-times.  It
  159. has two formats, one for metrical time, and one for time-code-based time:
  160.  
  161.           +---+-----------------------------------------+
  162.           | 0 |         ticks per quarter-note          |
  163.           ==============================================|
  164.           | 1 | negative SMPTE format | ticks per frame |
  165.           +---+-----------------------+-----------------+
  166.           |15 |14                   8 |7              0 |
  167.  
  168. If bit 15 of <division> is zero, the bits 14 thru 0 represent the number of
  169. delta time "ticks" which make up a quarter-note. For instance, if  division
  170. is  96,  then a time interval of an eighth-note between two events  in  the
  171. file would be 48.
  172.  
  173.  
  174. If  bit  15  of <division> is a one, delta times in a  file  correspond  to
  175. subdivisions  of  a second, in a way consistent with SMPTE  and  MIDI  Time
  176. Code. Bits 14 thru 8 contain one of the four values -24, -25, -29, or  -30,
  177. corresponding  to the four standard SMPTE and MIDI Time Code  formats  (-29
  178. corresponds  to  30 drop frome), and represents the number  of  frames  per
  179. second.  These  negative numbers are stored in two's compliment  form.  The
  180. second  byte  (stored positive) is the resolution within a  frame:  typical
  181. values may be 4 (MIDI Time Code resolution), 8, 10, 80 (bit resolution), or
  182. 100. This stream allows exact specifications of time-code-based tracks, but
  183. also  allows  milisecond-based  tracks by specifying  25|frames/sec  and  a
  184. resolution of 40 units per frame. If the events in a file are stored with a
  185. bit resolution of thirty-framel time code, the division word would be  E250
  186. hex.
  187.  
  188. FORMATS 0, 1, AND 2
  189. A  Format 0 file has a header chunk followed by one track chunk. It is  the
  190. most interchangable representation of data. It is very useful for a  simple
  191. single-track  player  in a program which needs to  make  synthesizers  make
  192. sounds,  but  which  is primarily concerened with something  else  such  as
  193. mixers  or sound effect boxes. It is very desirable to be able  to  produce
  194. such  a format, even if your program is track-based, in order to work  with
  195. these  simple  programs. On the other hand, perhaps someone  will  write  a
  196. format  conversion from format 1 to format 0 which might be so easy to  use
  197. in some setting that it would save you the trouble of putting it into  your
  198. program.
  199.  
  200. A  Format  1  or 2 file has a header chunk followed by one  or  more  track
  201. chunks.  programs which support several simultanious tracks should be  able
  202. to save and read data in format 1, a vertically one-dementional form,  that
  203. is,  as a collection of tracks. Programs which support several  independant
  204. patterns  should be able to save and read data in format 2, a  horizontally
  205. one-dementional  form.  Providing these minimum  capabilities  will  ensure
  206. maximum interchangability.
  207.  
  208. In  a MIDI system with a computer and a SMPTE synchronizer which uses  Song
  209. Pointer  and Timing Clock, tempo maps (which describe the tempo  throughout
  210. the track, and may also include time signature information, so that the bar
  211. number  may be derived) are generally created on the computer. To use  them
  212. with the synchronizer, it is necessary to transfer them from the  computer.
  213. To make it easy for the synchronizer to extract this data from a MIDI File,
  214. tempo  information should always be stored in the first MTrk chunk.  For  a
  215. format 0 file, the tempo will be scattered through the track and the  tempo
  216. map  reader should ignore the intervening events; for a format 1 file,  the
  217. tempo  map must be stored as the first track. It is polite to a  tempo  map
  218. reader  to offerr your user the ability to make a format 0 file  with  just
  219. the tempo, unless you can use format 1.
  220.  
  221. All MIDI Files should specify tempo and time signature. If they donn't, the
  222. time signature is assumed to be 4/4, and the tempo 120 beats per minute. In
  223. format  0, these meta-events should occur at least at the beginning of  the
  224. single  multi-channel  track.  In format 1,  these  meta-events  should  be
  225. contained  i|  the  first  track.  In format  2,  each  of  the  temporally
  226. independant  patterns  should contain at least initial time  signature  and
  227. tempo information.
  228.  
  229. We  may  decide to define other format IDs to support other  structures.  A
  230. program encountering an unknown format ID may still read other MTrk  chunks
  231. it  finds  from the file, as format 1 or 2, if its user can make  sense  of
  232. them and arrange them into some other structure if appropriate. Also,  more
  233. parameters may be added to the MThd chunk in the future: it is important to
  234. read and honor the length, even if it is longer than 6.
  235.  
  236. TRACK CHUNKS
  237. The  track  chunks (type MTrk) are where actual song data is  stored.  Each
  238. track  chunk  is  simply a stream of MIDI  events  (and  non-MIDI  events),
  239. preceded  by  delta-time  values. The format for  Track  Chunks  (described
  240. below) is exactly the same for all three formats (0, 1, and 2: see  "Header
  241. Chunk" above) of MIDI Files.
  242.  
  243. Here  is the syntax of an MTrk chunk (the + means "one or more":  at  least
  244. one MTrk event must be present):
  245.  
  246. <Track Chunk> = <chunk type><length><MTrk event>+
  247.  
  248. The syntax of an MTrk event is very simple:
  249.  
  250. <MTrk event> = <delta-time><event>
  251.  
  252. <delta-time>  is  stored as a variable-length quantity. It  represents  the
  253. amount  of time before the following event. If the first event in  a  track
  254. occurs  at  the  very  beginning  of  a  track,  or  if  two  events  occur
  255. simultaineously,  a  delta-time  of zero is used.  Delta-times  are  always
  256. present. (Not storing delta-times of 0 requires at least two bytes for  any
  257. other  value,  and  most delta-times aren't zero.) Delta-time  is  in  some
  258. fraction  of a beat (or a second, for recording a track with SMPTE  times),
  259. as specified in the header chunk.
  260.  
  261. <event> = <MIDI event> | <sysex event> | <meta-event>
  262.  
  263. <MIDI  event> is any MIDI channel message. Running status is  used:  status
  264. bytes  of MIDI channel messages may be omitted if the preceding event is  a
  265. MIDI  channel  message with the same status. The first event in  each  MTrk
  266. chunk  must specifyy status. Delta-time is not considered an event  itself:
  267. it is an integral part of the syntax for an MTrk event. Notice that running
  268. status occurs across delta-times.
  269.  
  270. <sysex event> is used to specify a MIDI system exclusive message, either as
  271. one unit or in packets, or as an "escape" to specify any arbitrary bytes to
  272. be  transmitted. A normal complete system exclusive message is stored in  a
  273. MIDI File in this way:
  274.  
  275.           F0 <length> <bytes to be transmitted after F0>
  276.  
  277. The length is stored as a variable-length quantity. It specifies the number
  278. of  bytes which follow it, not including the F0 or the length  itself.  For
  279. instance,  the transmitted message F0 43 12 00 07 F7 would be stored  in  a
  280. MIDI File as F0 05 43 12 00 07 F7. It is required to include the F7 at  the
  281. end  so that the reader of the MIDI File knows that it has read the  entire
  282. message.
  283.  
  284. Another  form  of sysex event is provided which does not imply that  an  F0
  285. should  be transmitted. This may be used as an "escape" to provide for  the
  286. transmission of things which would not otherwise be legal, including system
  287. realtime  messages, song pointer or select, MIDI Time Code, etc. This  uses
  288. the F7 code:
  289.  
  290.           F7 <length> <all bytes to be transmitted>
  291.  
  292. Unfortunately,  some  synthesizer manufacturers specify that  their  system
  293. exclusive messages are to be transmitted as little packets. Each packet  is
  294. only part of an entire syntactical system exclusive message, but the  times
  295. they are transmitted are important. Examples of this are the bytes sent  in
  296. a CZ patch dump, or the FB-01's "system exclusive mode" in which microtonal
  297. data can be transmitted. The F0 and F7 sysex events may be used together to
  298. break  up  syntactically  complete system  exclusive  messages  into  timed
  299. packets.
  300.  
  301. An  F0  sysex  event is used for the first packet in a series --  it  is  a
  302. message  in which the F0 should be transmitted. An F7 sysex event  is  used
  303. for  the remainder of the packets, which do not begin with F0. (Of  course,
  304. the F7 is not considered part of the system exclusive message).
  305.  
  306. A  syntactic system exclusive message must always end with an F7,  even  if
  307. the real-life device didn't send one, so that you know when you've  reached
  308. the end of an entire sysex message without looking ahead to the next  event
  309. in the MIDI File. If it's stored in one compllete F0 sysex event, the  last
  310. byte must be an F7. There also must not be any transmittable MIDI events in
  311. between  the  packets  of a multi-packet  system  exclusive  message.  This
  312. principle is illustrated in the paragraph below.
  313.  
  314. Here is a MIDI File of a multi-packet system exclusive message: suppose the
  315. bytes  F0 43 12 00 were to be sent, followed by a 200-tick delay,  followed
  316. by  the bytes 43 12 00 43 12 00, followed by a 100-tick delay, followed  by
  317. the bytes 43 12 00 F7, this would be in the MIDI File:
  318.  
  319.           F0 03 43 12 00
  320.           81 48                        200-tick delta time
  321.           F7 06 43 12 00 43 12 00
  322.           64                           100-tick delta time
  323.           F7 04 43 12 00 F7
  324.  
  325.  
  326. When  reading a MIDI File, and an F7 sysex event is encountered  without  a
  327. preceding  F0 sysex event to start a multi-packet system exclusive  message
  328. sequence,  it  should  be presumed that the F7 event is being  used  as  an
  329. "escape". In this case, it is not necessary that it end with an F7,  unless
  330. it is desired that the F7 be transmitted.
  331.  
  332.  
  333. <meta-event>  specifies  non-MIDI information useful to this format  or  to
  334. sequencers, with this syntax:
  335.  
  336.           FF <type> <length> <bytes>
  337.  
  338. All  meta-events  begin  with FF, then have an event type  byte  (which  is
  339. always  less  than 128), and then have the length of the data stored  as  a
  340. variable-length  quantity, and then the data itself. If there is  no  data,
  341. the  length is 0. As with chunks, future meta-events may be designed  which
  342. may  not  be known to existing programs, so programs must  properly  ignore
  343. meta-events  which they do not recognize, and indeed should expect  to  see
  344. them.  Programs must never ignore the length of a meta-event which they  do
  345. not  recognize,  and  they  shouldn't be  surprized  if  it's  bigger  than
  346. expected.  If  so, they must ignore everything past what they  know  about.
  347. However,  they must not add anything of their own to the end of  the  meta-
  348. event.
  349. Sysex events and meta events cancel any running status which was in effect.
  350. Running status does not apply to and may not be used for these messages.
  351.  
  352.  
  353. 3 - Meta-Events
  354.  
  355. A  few meta-events are defined herin. It is not required for every  program
  356. to support every meta-event.
  357.  
  358. In the syntax descriptions for each of the meta-events a set of conventions
  359. is  used  to describe parameters of the events. The FF  which  begins  each
  360. event, the type of each event, and the lengths of events which do not  have
  361. a  variable  amount of data are given directly in hexadecimal.  A  notation
  362. such  as dd or se, which consists of two lower-case  letters,  mnemonically
  363. represents  an 8-bit value. Four identical lower-case letters such as  wwww
  364. mnemonically  refer to a 16-bit value, stored most-significant-byte  first.
  365. Six  identical lower-case letters such as tttttt refer to a  24-bit  value,
  366. stored  most-significan-byte first. The notation len refers to  teh  length
  367. portion of the meta-event syntax, that is, a number, stored as a  variable-
  368. length  quantity, which specifies how many bytes (possibly text) data  were
  369. just specified by the length.
  370.  
  371. In  general, meta-events in a track which occur at the same time may  occur
  372. in any order. If a copyright event is used, it should be placed as early as
  373. possible  in  the file, so it will be noticed easily. Sequence  Number  and
  374. Sequence/Track  Name events, if present, must appear at time 0. An  end-of-
  375. track event must occur as the last event in the track.
  376.  
  377. Meta-events initially defined include:
  378.  
  379. FF 00 02                     Sequence Number
  380.     This  optional  event, which must occur at the beginning  of  a  track,
  381.     before  any  nonzero  delta-times, and before  any  transmittable  MIDI
  382.     events, specifies the number of a sequence. In a format 2 MIDI File, it
  383.     is used to identify each "pattern" so that a "song" sequence using  the
  384.     Cue  message to refer to the patterns. If the ID numbers  are  omitted,
  385.     the sequences' lacations in order in the file are used as defaults.  In
  386.     a format 0 or 1 MIDI File, which only contain one sequence, this number
  387.     should  be  contained  in the first (or only)  track.  If  transfer  of
  388.     several multitrack sequences is required, this must be done as a  group
  389.     of format 1 files, each with a different sequence number.
  390.  
  391. FF 01 len text               Text Event
  392.     Any amount of text describing anything. It is a good idea to put a text
  393.     event right at the beginning of a track, with the name of the track,  a
  394.     description  of its intended orchestration, and any  other  information
  395.     which the user wants to put there. Text events may also occur at  other
  396.     times in a track, to be used as lyrics, or descriptions of cue  points.
  397.     The text in this event should be printable ASCII characters for maximum
  398.     interchange.  However, other characters codes using the high-order  bit
  399.     may be used for interchange of files between different programs on  the
  400.     same  computer which supports an extended character set. Programs on  a
  401.     computer  which  does not support non-ASCII  characters  should  ignore
  402.     those characters.
  403.  
  404.     Meta-event  types 01 through 0F are reserved for various types of  text
  405.     events,  each of which meets the specification of text  events  (above)
  406.     but is used for a different purpose:
  407.  
  408. FF 02 len text               Copyright Notice
  409.     Contains a copyright notice as printable ASCII text. The notice  should
  410.     contain the characters (C), the year of the copyright, and the owner of
  411.     the  copyright. If several pieces of music are in the same  MIDI  File,
  412.     all of the copyright notices should be placed together in this event so
  413.     that it will be at the beginning of the file. This event should be  the
  414.     first event in the track chunk, at time 0.
  415.  
  416. FF 03 len text               Sequence/Track Name
  417.     If in a format 0 track, or the first track in a format 1 file, the name
  418.     of the sequence. Otherwise, the name of the track.
  419.  
  420. FF 04 len text               Instrument Name
  421.     A description of the type of instrumentation to be used in that  track.
  422.     May  be  used  with the MIDI Prefix meta-event to  specify  which  MIDI
  423.     channel the description applies to, or the channel may be specified  as
  424.     text in the event itself.
  425.  
  426. FF 05 len text               Lyric
  427.     A  lyric to be sung. Generally, each syllable will be a seperate  lyric
  428.     event which begins at the event's time.
  429.  
  430. FF 06 len text               Marker
  431.     Normally  in a format 0 track, or the first track in a format  1  file.
  432.     The  name of that point in the sequence, such as a rehersal  letter  or
  433.     section name ("First Verse", etc.)
  434.  
  435. FF 07 len text               Cue Point
  436.     A description of something happening on a film or video screen or stage
  437.     at that point in the musical score ("Car crashes into  house",
  438.     "curtain opens", "she slaps his face", etc.)
  439.  
  440. FF 20 01 cc                  MIDI Channeel Prefix
  441.     The  MIDI  channel  (0-15)  containted in this event  may  be  used  to
  442.     associate a MIDI channel with all events which follow, including System
  443.     exclusive  and meta-events. This channel is "effective" until the  next
  444.     normal  MIDI event (which contains a channel) or the next MIDI  Channel
  445.     Prefix meta-event. If MIDI channels refer to "tracks", this message may
  446.     into  a  format 0 file, keeping their non-MIDI data associated  with  a
  447.     track. This capability is also present in Yamaha's ESEQ file format.
  448.  
  449. FF 2F 00                     End of Track
  450.     This  event  is not optional. It is included so that  an  exact  ending
  451.     point may be specified for the track, so that an exect length, which is
  452.     necessary for tracks which are looped or concatenated.
  453.  
  454.  
  455. FF 51 03 tttttt              Set Tempo
  456.                              (in microseconds per MIDI quarter-note)
  457.     This   event  indicates  a  tempo  change.  Another  way   of   putting
  458.     "microseconds  per  quarter-note" is "24ths of a microsecond  per  MIDI
  459.     clock".  Repersenting tempos as time per beat instead of beat per  time
  460.     allows absolutly exact long-term synchronization with a time-based sync
  461.     protocol  such  as SMPTE time code or MIDI time code.  This  amount  of
  462.     accuracy  provided by this tempo resolution allows a four-minute  piece
  463.     at  120 beats per minute to be accurate within 500 usec at the  end  of
  464.     the  piece. Ideally, these events should only occur where  MIDI  clocks
  465.     would  be  located -- this convention is intended to  guarntee,  or  at
  466.     least   increase   the   liklihood,   of   compatibility   with   other
  467.     synchronization  devices so that a time signature/tempo map  stored  in
  468.     this format may easily be transfered to another device.
  469.  
  470. FF 54 05 hr mn se fr ff      SMPTE Offset
  471.     This  event, if present, designates the SMPTE time at which  the  track
  472.     chunk  is supposed to start. It should be present at the  beginning  of
  473.     the  track,  that is, before any nonzero delta-times,  and  before  any
  474.     transmittable  MIDI  events. the hour must be encoded  with  the  SMPTE
  475.     format, just as it is in MIDI Time Code. In a format 1 file, the  SMPTE
  476.     Offset must be stored with the tempo map, and has no meaning in any  of
  477.     the other tracks. The ff field contains fractional frames, in 100ths of
  478.     a  frame,  even in SMPTE-based tracks which specify a  different  frame
  479.     subdivision for delta-times.
  480.  
  481. FF 58 04 nn dd cc bb         Time Signature
  482.     The  time signature is expressed as four numbers. nn and  dd  represent
  483.     the  numerator  and denominator of the time signature as  it  would  be
  484.     notated.  The  denominator is a neqative power of two: 2  represents  a
  485.     quarter-note,  3  represents  an eighth-note,  etc.  The  cc  parameter
  486.     expresses  the  number  of MIDI clocks in a  metronome  click.  The  bb
  487.     parameter  expresses  the  number  of  notated  32nd-notes  in  a  MIDI
  488.     quarter-note (24 MIDI clocks). This was added because there are already
  489.     multiple  programs which allow a user to specify that what MIDI  thinks
  490.     of as a quarter-note (24 clocks) is to be notated as, or related to  in
  491.     terms of, something else.
  492.  
  493.     Therefore, the complete event for 6/8 time, where the metronome  clicks
  494.     every three eighth-notes, but there are 24 clocks per quarter-note,  72
  495.     to the bar, would be (in hex):
  496.  
  497.                FF 58 04 06 03 24 08
  498.  
  499.     That is, 6/8 time (8 is 2 to the 3rd power, so this is 06 03), 36  MIDI
  500.     clocks  per dotted-quarter (24 hex!), and eight notated 32nd-notes  per
  501.     quarter-note.
  502.  
  503.  
  504. FF 59 02 sf mi               Key Signature
  505.     sf = -7: 7 flats
  506.     sf = -1: 1 flat
  507.     sf =  0: key of C
  508.     sf =  1: 1 sharp
  509.     sf =  7: 7 sharps
  510.  
  511.     mi =  0: major key
  512.     mi =  1: minor key
  513.  
  514. FF 7F len data               Sequencer Specific Meta-Event
  515.     Special requirements for particular sequencers may use this event type:
  516.     the  first  byte or bytes of data is a manufacturer ID (these  are  one
  517.     byte,  or  if the first byte is 00, three bytes). As with  MIDI  System
  518.     Exclusive,  manufacturers  who define something using  this  meta-event
  519.     should  publish  it  so that others may be used by  a  sequencer  which
  520.     elects  to  use  this as its only file format;  sequencers  with  their
  521.     established  feature-specific  formats  should probably  stick  to  the
  522.     standard features when using this format.
  523.  
  524. 4 - Program Fragments and Example MIDI Files
  525.  
  526. Here are some of the routines to read and write variable-length numbers  in
  527. MIDI Files. These routines are in C, and use getc and putc, which read  and
  528. write single 8-bit characters from/to the files infile and outfile.
  529.  
  530. WriteVarLen (value)
  531. register long value;
  532. (
  533.    register long buffer;
  534.  
  535.    buffer = value & 0x7f;
  536.    while ((value >>= 7) > 0)
  537.    (
  538.       buffer <<= 8;
  539.       buffer |= 0x80;
  540.       buffer += (value & 0x7f);
  541.    )
  542.  
  543.    while (TRUE)
  544.    (
  545.       putc(buffer,outfile);
  546.       if (buffer & 0x80)
  547.          buffer >>= 8;
  548.       else
  549.          break;
  550.    )
  551. )
  552.  
  553. doubleword ReadVarLen ()
  554. (
  555.    register doubleword value;
  556.    register byte c;
  557.  
  558.    if ((value = getc(infile)) & 0x80)
  559.    (
  560.       value &= 0x7f;
  561.       do
  562.       (
  563.          value = (value << 7) + ((c = getc(infile))) & 0x7f);
  564.       ) while (c & 0x80);
  565.    )
  566.    return (value);
  567. )
  568.  
  569.  
  570. As an example, MIDI Files for the following excerpt are shown below. First,
  571. a format 0 file is shown, with all information intermingled; then, a format
  572. 1 file is shown with all data seperated into four tracks: one for tempo and
  573. time  signature,  and three for the notes. A resolution of 96  "ticks"  per
  574. quarter  note is used. A time signature of 4/4 and a tempo of  120,  though
  575. implied, are explicitly stated.
  576.  
  577.  
  578.  
  579.  
  580.  
  581.                    |\
  582.               ---- | > ---------------------------------------
  583.                    |/         ____                    O
  584. Channel 1     ---- X --------------------------------|--------
  585.                   /                                  |
  586. Preset 5      -- / | --------------------------------|--------
  587.                 / ____                               |
  588.               -|   |  \ --------------------------------------
  589.                 \  |   |
  590.               -- \_|__/ --------------------------------------
  591.                   _|
  592.  
  593.  
  594.                    |\
  595.               ---- | > ---------------------------------------
  596.                    |/           \
  597. Channel 2     ---- X ------------>----------|-----------------
  598.                   /             /           |
  599. Preset 46     -- / | ----------<------------|-----------------
  600.                 / ____          \           | .
  601.               -|   |  \ --------->---------O------------------
  602.                 \  |   |       (
  603.               -- \_|__/ --------\-----------------------------
  604.                   _|             \
  605.  
  606.  
  607.                               --O--
  608.  
  609.               ----__ -----------------------------------------
  610.                  /  \  .
  611. Channel 3     - /    | ---------------------------------------
  612.                      | .
  613. Preset 70     ------ | ---------------------------------------
  614.                     /           O
  615.               ---- / -----------------------------------------
  616.                   /
  617.               -- / -------------------------------------------
  618.  
  619.  
  620. The contents of the MIDI stream represented by this example are broken down
  621. here:
  622.  
  623. Delta-Time  Event-Code  Other Bytes     Comment
  624. (decimal)   (hex)       (decimal)
  625. ----------  ----------  -----------     -----------------------------
  626. 0           FF 58       04 04 02 24 08  4 bytes; 4/4 time; 24 MIDI
  627.                                         clocks/click, 8 32nd notes/
  628.                                         24 MIDI clocks
  629. 0           FF 51       03 500000       3 bytes: 500,000 usec/
  630.                                         quarter note
  631. 0           C0          5               Ch.1 Program Change 5
  632. 0           C1          46              Ch.2 Program Change 46
  633. 0           C2          70              Ch.3 Program Change 70
  634. 0           92          48 96           Ch.3 Note On C2, forte
  635. 0           92          60 96           Ch.3 Note On C3, forte
  636. 96          91          67 64           Ch.2 Note On G3, mezzo-forte
  637. 96          90          76 32           Ch.1 Note On E4, piano
  638. 192         82          48 64           Ch.3 Note Off C2, standard
  639. 0           82          60 64           Ch.3 Note Off C3, standard
  640. 0           81          67 64           Ch.2 Note Off G3, standard
  641. 0           80          76 64           Ch.1 Note Off E4, standard
  642. 0           FF 2F       00              Track End
  643.  
  644. The  entire  format 0 MIDI file contents in hex follow.  First, the  header
  645. chunk:
  646.               40 54 68 64              MThd
  647.               00 00 00 06              chunk length
  648.               00 00                    format 0
  649.               00 01                    one track
  650.               00 60                    96 per quarter-note
  651.  
  652. Then the track chunk. Its header followed by the events (notice the running
  653. status is used in places):
  654.  
  655.               4D 54 72 6B              MTrk
  656.               00 00 00 3B              chunk length (59)
  657.  
  658. Delta-Time    Event                    Comments
  659. ----------    -----------------------  -------------------------------
  660. 00            FF 58 04 04 02 18 08     time signature
  661. 00            FF 51 03 07 A1 20        tempo
  662. 00            C0 05
  663. 00            C1 2E
  664. 00            C2 46
  665. 00            92 30 60
  666. 00            3C 60                    running status
  667. 60            91 43 40
  668. 60            90 4C 20
  669. 81 40         82 30 40                 two-byte delta-time
  670. 00            3C 40                    running status
  671. 00            81 43 40
  672. 00            80 4C 40
  673. 00            FF 2F 00                 end of track
  674.  
  675. A  format  1 representation of the file is slightly different.  Its  header
  676. chunk:
  677.  
  678.               4D 54 68 64              MThd
  679.               00 00 00 06              chunk length
  680.               00 01                    format 1
  681.               00 04                    four tracks
  682.               00 60                    96 per quarter note
  683.  
  684. First,  the  track chunk for the time signature/tempo  track.  Its  header,
  685. followed by the events:
  686.  
  687.               4D 54 72 6B              MTrk
  688.               00 00 00 14              chunk length (20)
  689.  
  690. Delta-Time    Event                    Comments
  691. ----------    -----------------------  -------------------------------
  692. 00            FF 58 04 04 02 18 08     time signature
  693. 00            FF 51 03 07 A1 20        tempo
  694. 83 00         FF 2F 00                 end of track
  695.  
  696. Then,  the track chunk for the first music track. The MIDI  convention  for
  697. note on/off running status is used in this example:
  698.  
  699.               4D 54 72 6B              MTrk
  700.               00 00 00 10              chunk length (16)
  701.  
  702. Delta-Time    Event                    Comments
  703. ----------    -----------------------  -------------------------------
  704. 00            C0 05
  705. 81 40         90 4C 20
  706. 81 40         4C 00                    Running status: note on, vel=0
  707. 00            FF 2F 00
  708.  
  709. Then, the track chunk for the second music track:
  710.  
  711.               4D 54 72 6B              MTrk
  712.               00 00 00 0F              chunk length (15)
  713.  
  714. Delta-Time    Event                    Comments
  715. ----------    -----------------------  -------------------------------
  716. 00            C1 2E
  717. 60            91 43 40
  718. 82 20         43 00                    running status
  719. 00            FF 2F 00                 end of track
  720.  
  721.  
  722. Then, the track chunk for the third music track:
  723.  
  724.               4D 54 72 6B              MTrk
  725.               00 00 00 15              chunk length (21)
  726.  
  727. Delta-Time    Event                    Comments
  728. ----------    -----------------------  -------------------------------
  729. 00            C2 46
  730. 00            92 30 60
  731. 00            3C 60                    running status
  732. 83 00         30 00                    two-byte delta-time, running status
  733. 00            3C 00                    running status
  734. 00            FF 2F 00                 end of track
  735.