Changes

This file The <B>Standard MIDI File</B> (SMF) is a mapping file for atlas textures like iconsformat used to store MIDI data (plus someother kinds of data typically needed by a sequencer.tex

== Layout of '''icon.sp1''': ==This format stores the standard MIDI messages (ie, status bytes with appropriate data bytes)=== Header ==='''plus a time-stamp for each message (4 x (PointerCount + 1))''' ie, a series of bytesthat represent how many clock pulses{| class=to wait before "wikitableplaying"the event). The format also allows saving information about tempo,! Offset! SizeOf! Name! Description|-| 0| UInt32| PointerCount| Number time and key signatures, the names of entriestracks and patterns, and other information typically|-| 4| Struct Pointer[PointerCount]| Pointers| Seek locations needed by a sequencer. One SMF can store information for entry groupsnumerous patterns and tracks so that any|}sequencer can preserve these structures when loading the file.

<B><FONT COLOR=== Pointer ===RED>NOTE:</FONT></B> A <B>track</B> usually is analogous to one musical part,'''4''' bytes{| class="wikitable"! Offset! SizeOfsuch as a Trumpet part. A <B>pattern</B> would be analogous to all of the musical parts (ie,! Name! Description|-| 0| UInt16| Pointer| Seek location Trumpet, Drums, Piano, etc) for entry group|-| 2| UInt16| Count| Number of entries in group|}one song.

=== Entry Group ===The format was designed to be generic so that the most important data can be read by all'''sequencers. Think of a MIDI file as a musical version of an ASCII text file (8 x Countexceptthat the MIDI file contains binary data)''' bytes , and the various sequencer programs as text editorsall capable of reading that file. But, unlike ASCII, MIDI file format saves data in <B>chunks<br/B>At pointer(ie, groups of bytes preceded by an ID and size) which can be parsed, loaded, skipped, etc.Therefore, SMF format is flexible enough for a particular sequencer to storeits own proprietary, "extra" data in such a way that another sequencer won's location there will t be confused whenloading the file and can safely ignore this extra stuff that it doesn'''Struct Entry[Count]'''t need. Example of For example, maybe a sequencer wants to save a "flag byte"that indicates whether the user has turned on an entry group audible metronome click. The sequencer can savethis flag byte in such a way that another sequencer can skip this byte withouthaving to understand what that byte is for. In the direction pad is in eight pieces. Four of them are unpressed future, the SMF format can also beextended to include new "official" chunks that all sequencer programs may elect to load and four are pressed versionsuse. It has four entries for This can be done without making old data files obsolete, nor making old sequencers no longerable to load the direction pad depending on new files. So, the directions it format is highlightingdesigned to beextensible in a backwardly compatible way.

=== Entry ===Of course, SMF files may be used by other MIDI software than just sequencers.'''8''' bytesSince SMF files can store any and all types of MIDI messages, including System Exclusive{| class="wikitable"! Offset! SizeOf! Name! Description|-|0|Byte|xPos|Pixel X coordinate in image atlas|-|1|Byte|yPos|Pixel Y coordinate in image atlas|-|2|Byte[2]|UNK|Unknown messages, they may be used to store/load data|-|4|Byte|Width|Width by all kinds of entry in pixelsMIDI software, such as a Patch|-Editor that wants to save some System Exclusive messages it received from a MIDI module. (The|5|Byte|Offset X|Offset of X coordinate "timestamp" for when drawing|-|6|Byte|Height|Height of entry in pixels|-|7|Byte|Offset Y|Offset of Y coordinate for when drawing|}Invalid Entries will have '''X''' and '''Y''' of '''zero'''. The top '''16x16''' pixel area is blank. Everything in '''icon.tex''' is aligned each message may be irrelevant to such a Patch Editor. But it'''8x8 grid'''. Some entry groups leave out connecting pieces I think you are expected to fill in the blank. Some things like the menu border and menu background s easilyignored for programs that don't appear to be listed in this filereally need it).

===End of file===In conclusion, any software that saves or loads MIDI data should use SMF format for its dataEverything at and beyond file pointer '''4272 {0x10C0}''' appears to be garbagefiles.

== Layout of '''face.sp2''' and '''cardanm.sp2''': Chunks ==

Both '''face.sp2''' and '''cardanm.sp2''' have the same layout. Main difference Data is '''facealways saved within a <B>chunk</B>.sp2''' has '''32''' valid and '''64''' total entries. '''cardanm.sp2''' only has '''11''' valid entries and '''1''' invalid, as it has no dims. In each There can be many chunks inside of the card texture files the final slot is the '''Triple Triad''' card back. If the entry had dims they would be X='''192''',Y='''128''', W='''64''', H='''64'''a MIDI file.

=== Header ==={| class="wikitable"! Offset! SizeOf! Name! Description|-| 0| UInt32| Count| Number of entriesCount Each chunk can be more than the actual images in the texture.<br/>'''facea different size (and likely will be).sp2A chunk''': There are s size is how many (8 images per texture in 2 textures, and there are 32/64 valid entries. 1 is blank.<br/>-bit)'''cardanm.sp2''': There bytes are 11 images pre texture contained in 10 textures, and there are 11/12 valid entries. The 12th entry is the card back but it's missing dimschunk.

|-| 4| UInt32[Count]| Locations| Seek location The data bytes in a chunk are typically related in some way. For example, all of the bytes in one chunk may be for one particular sequencer track. The bytes for each entry|}=== Entry ===another sequencer track may be put in'''16''' a different chunk. So, a chunk is simply a group of related bytes.

{| class="wikitable"! Offset! SizeOf! Name! Description|-| 0| UInt32| Count| Number of entries at this locationAlways '''1'''|-| Each chunk must begin with a 4 character (ie, 4| byte| xPos| Pixel X coordinate in image atlas|-| 5| byte| yPos| Pixel Y coordinate in image atlas'''face.sp2''': Invalid entries seem to have '''yPos>=Texture.Height'''.ascii bytes) <br /B>Detected switch from '''face1.tex''' to '''face2.tex''' when '''yPos<previous.yPos'''.|-| 6| byte[2]| UNK| Unknown'''face.sp2''': '''{0x20,0x36}''' on the valid entries. '''{0x60,0x36}''' on invalid entries.ID<br /B>which tells what "type"'''cardanm.sp2''': '''{0x20,0xB6}''' on the valid entries. '''{0x00,0x00}''' on the invalid entry.|-| 8| UInt16| Width| Width of entry in pixelsPossible chunk this is really a '''byte''' with a '''0 x-offset'''.|-| 10| UInt16| Height| Height of entry in pixelsPossible this is really a '''byte''' with a '''0 y-offset'''.|-| 12| byte[4]| UNK| Unknown'''face.sp2''': '''{0x00,0x00,0x8E,0x00}''' on most. Last one has all '''{0x00}'''<br />'''cardanm.sp2''': '''{0x00,0x00,0xAE,0x00}''' on most. Last one has all '''{0x00}'''|}

=== End The next 4 bytes must form a 32-bit length (ie, size) of file ==='''facethe chunk.sp2'''File ends with '''byte[16]''' of '''{0x00}'''

<U>All chunks must begin with these two fields</U> (ie, 8 bytes), which are referred to as the<B>chunk header</B>. Here's what a chunk's header looks like if you defined it in C:<c>struct CHUNK_HEADER{ char ID[4]; unsigned long Length; };</c><B><FONT COLOR=RED>NOTE:</FONT></B> The <B>Length</B> does not include the 8 byte chunkheader. It simply tells you how many bytes of data are in the chunk <U>following this header</U>. And here's an example chunk header (with bytes expressed in hex) if you examined it with a hex editor:  4D 54 68 64 00 00 00 06 Note that the first 4 bytes make up the ascii ID of <B>MThd</B> (ie, the first fourbytes are the ascii values for 'M', 'T', 'h', and 'd'). The next 4 bytes tell us that there shouldbe 6 more data bytes in the chunk (and after that we should find the next chunk header or the endof the file). === Content MThd Chunk === The MThd header has an ID of <B>MThd</B>, and a Length of <B>6</B>. Let's examine the 6 data bytes (which follow the MThd header) in an MThd chunk. The first two data bytes tell the <B>Format</B> (which I prefer to call "type").There are actually 3 different types (ie, formats) of MIDI files. A type of 0 means that the filecontains one single track containing midi data on possibly all 16 midi channels. If your sequencersorts/stores all of its midi data in one single block of memory with the data in the order that it's"played", then it should read/write this type. A type of 1 means that the file contains one ormore simultaneous (ie, all start from an assumed time of 0) tracks, perhaps each on a single midichannel. Together, all of these tracks are considered one sequence or pattern. If yoursequencer separates its midi data (i.e. tracks) into different blocks of memory but plays them backsimultaneously (ie, as one "pattern"), it will read/write this type. A type of 2 means that thefile contains one or more sequentially independant single-track patterns. If your sequencerseparates its midi data into different blocks of memory, but plays only one block at a time (ie,each block is considered a different "excerpt" or "song"), then it will read/write this type. The next 2 bytes tell how many tracks are stored in the file, <B>NumTracks</B>. Of course,for format type 0, this is always 1. For the other 2 types, there can be numerous tracks. The last two bytes indicate how many Pulses (i.e. clocks) Per Quarter Note (abbreviated as PPQN) resolution the time-stamps are based upon, <B>Division</B>. For example, if your sequencer has 96 ppqn, this field would be (in hex):  00 60 <B><FONT COLOR=RED>NOTE:</FONT></B> The 4 bytes that make up the <B>Length</B> are stored in (Motorola) "Big Endian" byte order, not (Intel) "Little Endian" reverse byte order. (ie, The 06 is the fourth byte insteadof the first of the four). In fact, all MIDI files begin with the above <B>MThd header</B> (and that's how you know that it'face1sa MIDI file). Alternately, if the first byte of Division is negative, then this represents the divisionof a second that the time-stamps are based upon. The first byte will be -24, -25, -29, or -30,corresponding to the 4 SMPTE standards representing frames per second.texThe second byte (apositive number) is the resolution within a frame (ie, subframe). Typical values may be 4 (MIDITime Code), 8, 10, 80 (SMPTE bit resolution), or 100. You can specify millisecond-based timing by the data bytes of -25 and 40 subframes. Here's what an MThd chunk looks like if you defined it in C: <c>struct MTHD_CHUNK{ /* Here's the 8 byte header that all chunks must have */ char ID[4]; /* This will be ' and M','T','face2.texh','d'*/ unsigned long Length; /* This will be 6 */  /* Here are the 6 bytes */ unsigned short Format; unsigned short NumTracks; unsigned short Division;};</c> And here' s an example of a complete MThd chunk (with header) if you examined it in a hex editor:<pre>4D 54 68 64 MThd ID00 00 00 06 Length of the MThd chunk is always 6.00 01 The Format type is 1.00 02 There are 2 MTrk chunks in this file.E7 28 Each increment of delta-time represents a millisecond.</pre> === MTrk Chunk ===After the MThd chunk, you should find an <B>MTrk chunk</B>, as this is the only othercurrently defined chunk. (If you find some other chunk ID, it must be proprietary to some otherprogram, so skip it by ignoring the following data bytes indicated by the chunk'sLength). An MTrk chunk contains all of the midi data (with timing bytes), plus optional non-midi datafor <U>one track</U>. Obviously, you should encounter as many MTrk chunks in the file as theMThd chunk's NumTracks field indicated. The MTrk header begins with the ID of <b>MTrk</B>, followed by the Length (ie, number of data bytes for this track). The Length will likely be different for each track. (After all, a track containing the violin part for a Bach concerto will likely contain more data than a track containing a simple 2 bar drum beat). Here's what an MTrk chunk looks like if you defined it in C:<c>struct MTRK_CHUNK{| class /* Here's the 8 byte header that all chunks must have */ char ID[4]; /* This will be 'M','T','r','k' */ unsigned long Length; /* This will be the actual size of Data[] */  /* Here are the data bytes */ unsigned char Data[]; /* Its actual size is Data[Length] */};</c>  ==== Variable Quantities ====Think of a track in the MIDI file in the same way that you normally think of a track in asequencer. A sequencer track contains a series of <B>events</B>. For example, the firstevent in the track may be to sound a middle C note. The second event may be to sound theE above middle C. These two events may both happen at the same time. The third event maybe to release the middle C note. This event may happen a few musical beats after the firsttwo events (ie, the middle C note is held down for a few musical beats). Each event has a"time" when it must occur, and the events are arranged within a "wikitablechunk"of memory in the order!Namethat they occur.!File!XIn a MIDI file, an event's "time" precedes the data bytes that make up that event itself. In!Yother words, the bytes that make up the event's time-stamp come first. A given event's!Widthtime-stamp is referenced from the previous event. For example, if the first event occurs 4 clocks!Heightafter the start of play, then its "delta-time" is 04. If the next event occurs simultaneously with|that first event, its time is 00. So, a delta-time is the duration (in clocks) between an event|Squall Leonhartand the preceding event.|face1.tex|<B><FONT COLOR=RED>NOTE:</FONT></B> Since all tracks start with an assumed time of 0, the first|event's delta-time is referenced from 0. A delta-time is stored as a series of bytes which is called a <B>variable lengthquantity</B>. Only the first 7 bits of each byte is significant (right-justified; sort of like an|ASCII byte). So, if you have a 32-bit delta-time, you have to unpack it into a series of 7-bit|48bytes (ie, as if you were going to transmit it over midi in a SYSEX message). Of course, youwill have a variable number of bytes depending upon your delta-time. To indicate which is thelast byte of the series, you leave bit #7 clear. In all of the preceding bytes, you set bit #7. So,if a delta-time is between 0-127, it can be represented as one byte. The largest delta-timeallowed is 0FFFFFFF, which translates to 4 bytes variable length. Here are examples of|delta-times as 32-bit values, and the variable length quantities that they translate to: <pre> NUMBER VARIABLE QUANTITY00000000 0000000040 400000007F 7F00000080 81 0000002000 C0 0000003FFF FF 7F00004000 81 80 0000100000 C0 80 00001FFFFF FF FF 7F00200000 81 80 80 0008000000 C0 80 80 000FFFFFFF FF FF FF 7F</pre>|Zell Dincht|face1Here are some C routines to read and write variable length quantities such as delta-times.texWith|<B>WriteVarLen()</B>, you pass a 32-bit value (ie, unsigned long) and it spits out the correct|0series of bytes to a file. <B>ReadVarLen()</B> reads a series of bytes from a file until it|reaches the last byte of a variable length quantity, and returns a 32-bit value. <c>void WriteVarLen(register unsigned long value){ register unsigned long buffer; buffer = value & 0x7F;  while ( (value >>= 7) ) { buffer <<= 8; buffer |= ((value & 0x7F) |480x80); }  while (TRUE) { putc(buffer,outfile); if (buffer & 0x80) buffer >>= 8; else break; }} unsigned long ReadVarLen(){ register unsigned long value; register unsigned char c;  if ( (value = getc(infile)) & 0x80 )| { value &= 0x7F; do { value = (value << 7) + ((c = getc(infile)) & 0x7F); } while (c & 0x80); }  return(value);}</c> <B><FONT COLOR=RED>NOTE:</FONT></B> The concept of variable length quantities (ie, breaking up alarge value into a series of bytes) is used with other fields in a MIDI file besides delta-times,|Irvine Kinneasas you'll see later. For those not writing in C, you may benefit from a psuedo-code explanation of|face1the above routines.texIn pseudo-code, ReadVarLen() is:|64|<OL><LI>Initialize the variable which will hold the value. Set it to 0. We'llcall this variable 'result'.</LI><LI>Read the next byte of the Variable Length quantity from the MIDI file.</LI><LI>Shift all of the bits in 'result' 7 places to the left. (ie, Multiply 'result' by 128).</LI><LI>Logically OR 'result' with the byte that was read in, but first mask off bit #7of the byte. (ie, AND the byte with hexadecimal 7F before you OR with'result'. But make sure you save the original value of the byte for the testin the next step).</LI><LI>Test if bit #7 of the byte is set. (ie, Is the byte AND hexadecimal80 equal to hexadecimal 80)? If so, loop back to step #2. Otherwise,you're done, and 'result' now has the appropriate value.</LI></OL>|32|48In pseudo code, WriteVarLen() could be: |-<OL>|Quistis Trepe<LI>Assume that you have a variable named 'result' which|face1contains the value to write out as a Variable Length Quantity.tex</LI>|96|<LI>Declare an array which can contain 4 numbers. We'll callthis variable 'array'. Initialize a variable named 'count' to 0.</LI>|32<LI>Is 'result' less than 128? If so, skip to step #8.</LI><LI>Take the value 'result' AND with hexadecimal 7F, and OR|48with hexadecimal 80, and store it in 'count' element of 'array'.|-(ie, The first time through the loop, this gets stored in the first|Rinoa Heartillyelement of 'array'). NOTE: Don't alter the value of 'result' itself.|face1<LI>Increment 'count' by 1.tex</LI>|<LI>Shift all bits in 'result' 7 places to the right. (This can be done by dividing by 128).</LI>|0<LI>Loop back to step #3.</LI><LI>Take the value 'result' AND with hexadecimal 7F, and storeit in 'count' element of 'array'.</LI><LI>Increment 'count' by 1.</LI><LI>Write out the values stored in 'array'. Start with the lastelement stored above, and finish with the first element stored.(ie, Write them out in reverse order so that the first element of'array' gets written to the MIDI file last). NOTE: The variable|32'count' tells you how many total bytes to write. It also can be|48used as an index into the array (if you subtract one from it, and|keep writing out bytes until it is -1).</LI></OL>|Selphie Tilmitt|face1.tex==== Events in an MTrk ====|160|0An MTrk can contain [http://www.borg.com/~jglatt/tech/midispec.htm MIDI events] and non-MIDI events (ie, events that contain data such as|32tempo settings, track names, etc).|48|The first (1 to 4) byte(s) in an MTrk will be the first event's delta-time as a variable length|Seifer Almasyquantity. The next data byte is actually the first byte of that event itself. I'll refer to this as|face1the event's <B>Status</B>. For [http://www.borg.com/~jglatt/tech/midispec.texhtm MIDI events], this will be the actual MIDI Status byte|192(or the first midi data byte if running status). For example, if the byte is hex 90, then this|event is a <B>Note-On</B> upon midi channel 0. If for example, the byte was hex 23, you'd have to|32recall the previous event's status (ie, midi running status). Obviously, the first MIDI event in|48the MTrk <U>must</U> have a status byte. After a midi status byte comes its 1 or 2 data bytes|(depending upon the status -some MIDI messages only have 1 subsequent data byte). After thatyou'll find the next event's delta time (as a variable quantity), etc.|Edea Kramer|face1.tex----|224|0<CENTER><FONT COLOR=RED><B>SYSEX events</B></FONT></CENTER>|32|48SYSEX (system exclusive) events (status = F0) are a special case because a SYSEX event can|be any length. After the F0 status (which is always stored --no running status here), you'll find|Laguna Loireyet another series of variable length bytes. Combine them with ReadVarLen() and you'll come upwith a 32-bit value that tells you how many more bytes follow which make up this SYSEX event.|face1This length doesn't include the F0 status.tex|0|48For example, consider the following SYSEX MIDI message: |32 F0 7F 7F 04 01 7F 7F F7|48|This would be stored in a MIDI file as the following series of bytes (minus the delta-timebytes which would precede it):  F0 07 7F 7F 04 01 7F 7F F7 The 07 above is the variable length quantity (which happens to fit in just one byte for thisexample). It indicates that there are seven, following bytes that comprise this SYSEX message. |Kiros SeagillReally oddball midi units send a system exclusive message as a series of small "packets" (with|face1a time delay inbetween transmission of each packet).texThe first packet begins with an F0, but it|32doesn't end with an F7. The subsequent packets don't start with an F0 nor end with F7. The last|48packet doesn't start with an F0, but does end with the F7. So, between the first packet's opening F0 and|32the last packet's closing F7, there's 1 SYSEX message there. (Note: only extremely poor designs,|48such as the crap marketed by Casio exhibit such horrid behavior). Of course, since a delay is|-needed inbetween each packet, you need to store each packet as a separate event with its own|Ward Zabactime in the MTrk. Also, you need some way of knowing which events shouldn't begin with an F0|face1(ie, all of them except the first packet).texSo, the MIDI file redefines a midi status of F7|64(normally used as an end mark for SYSEX packets) as a way to indicate an event that doesn't|48begin with F0. If such an event follows an F0 event, then it's assumed that the F7 event is the|32second "packet" of a series. In this context, it's referred to as a SYSEX CONTINUATION event.|48Just like the F0 type of event, it has a variable length followed by data bytes. On the other|-hand, the F7 event could be used to store MIDI REALTIME or MIDI COMMON messages. In this case,|Lionafter the variable length bytes, you should expect to find a MIDI Status byte of F1, F2, F3, F6,|face1F8, FA, FB, FC, or FE.tex(Note that you wouldn't find any such bytes inside of a SYSEX CONTINUATION|128event). When used in this manner, the F7 event is referred to as an ESCAPED event.|48----|32<CENTER><FONT COLOR=RED><B>Non-MIDI events</B></FONT></CENTER>|48|A status of FF is reserved to indicate a special non-MIDI event. (Note that FF is used in MIDI|MiniMogto mean "reset", so it wouldn't be all that useful to store in a data file. Therefore, the MIDIfile arbitrarily redefines the use of this status). After the FF status byte is another byte that|face1tells you what <B>Type</B> of non-MIDI event it is. It's sort of like a second status byte.texThenafter this byte is another byte(s -- a variable length quantity again) that tells how many more|160data bytes follow in this event (ie, its Length). This Length doesn't include the FF, Type|48byte, nor the Length byte. These special, non-MIDI events are called <B>Meta-Events</B>, and|32most are optional unless otherwise noted. The section of this online book entitled "Meta-Events"|48lists the currently defined Meta-Events. Note that unless otherwise mentioned, more than one of|these events can be placed in an MTrk (even the same Meta-Event) at any delta-time. (Just like|Bokoall midi events, Meta-Events have a delta-time from the previous event regardless of what type|face1of event that may be. So, you can freely intermix MIDI and Meta events).tex|192|48|32|48==== Meta-Events in an MTrk ====|----|Angelo===== Sequence Number ===== FF 00 02 <I><FONT COLOR=RED><B>ss ss</B></FONT></I> |face1or...tex|224|48 FF 00 00|32|48This optional event must occur at the beginning of a MTrk (ie, before any non-zero|delta-times and before any midi events). It specifies the sequence number. The two data bytes|Quezacotl<I><FONT COLOR=RED><B>ss ss</B></FONT></I>, are that number which corresponds to the <B>MIDICue</B> message. In a format 2 MIDI file, this number identifies each "pattern" (ie, Mtrk) sothat a "song" sequence can use the MIDI Cue message to refer to patterns. If the <I><FONT COLOR=RED><B>ss ss</B></FONT></I> numbers are omitted (ie, the second form|face2shown above), then the MTrk's location in the file is used.tex(ie, The first MTrk chunk is|sequence number 0. The second MTrk is sequence number 1. Etc). |In format 0or 1, which contain only one "pattern" (even though format 1 contains|32several MTrks), this event is placed in only the first MTrk. So, a group of format 0 or 1 files|48with different sequence numbers can comprise a "song collection".|-|ShivaThere can be only one of these events per MTrk chunk in a Format 2. There can be only one|face2of these events in a Format 0 or 1, and it must be in the first MTrk.tex|32----===== Text ===== FF 01 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|0|32Any amount of text (amount of bytes = <I><FONT COLOR=GREEN><B>len</B></FONT></I>) for any|48purpose. It's best to put this event at the beginning of an MTrk. Although this text could be|used for any purpose, there are other text-based Meta-Events for such things as orchestration,|Ifritlyrics, track name, etc. This event is primarily used to add "comments" to a MIDI file which a|face2program would be expected to ignore when loading that file.tex|64|0Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since itis expressed as a variable length quantity.|32----|48===== Copyright =====|- FF 02 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Siren|face2A copyright message. It's best to put this event at the beginning of an MTrk.tex|96|0Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since itis expressed as a variable length quantity.|32----|48===== Sequence/Track Name =====|- FF 03 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Brothers|face2The name of the sequence or track.texIt's best to put this event at the beginning of an|128MTrk.|0|32Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it|48is expressed as a variable length quantity.|----===== Instrument ===== FF 04 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Diablos|face2The name of the instrument (ie, MIDI module) being used to play the track. This may bedifferent than the Sequence/Track Name.texFor example, maybe the name of your sequence (ie, Mtrk)|160is "Butterfly", but since the track is played upon a Roland S-770, you may also include an|0Instrument Name of "Roland S-770".|32|48It's best to put one (or more) of this event at the beginning of an MTrk to provide the user|-with identification of what instrument(s) is playing the track. Usually, the instruments (ie,|Carbunclepatches, tones, banks, etc) are setup on the audio devices via <B>MIDI Program Change</B>|face2and <B>MIDI Bank Select Controller</B> events within the MTrk.texSo, this event exists merely to|192provide the user with visual feedback of what instruments are used for a track.|0|32Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it|48is expressed as a variable length quantity.|----===== Lyric ===== FF 05 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Leviathan|face2A song lyric which occurs on a given beat.texA single Lyric|224MetaEvent should contain only one syllable.|0|32Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it|48is expressed as a variable length quantity.|----===== Marker =====  FF 06 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Pandemona|face2The text for a marker which occurs on a given beat. Marker events might be used to denote a loop start and loop end (ie, where the sequence loops back to a previous event).tex|0|48Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since itis expressed as a variable length quantity.|32----|48===== Cue Point=====|- FF 07 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Cerberus|face2The text for a cue point which occurs on a given beat.texA Cue Point might be used to denote|32where a WAVE (ie, sampled sound) file starts playing, for example, where the<I><FONT COLOR=RED><B>text</B></FONT></I> would be the WAVE's filename.|48|32Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it|48is expressed as a variable length quantity.|----===== Program (Patch) Name ===== FF 08 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I> The name of the program (ie, patch) used to play the MTrk. This may be|Alexanderdifferent than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk)is "Butterfly", but since the track is played upon an electric piano patch, you may also include a|face2Program Name of "ELECTRIC PIANO".tex|64|48Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via<B>MIDI Program Change</B> and <B>MIDI Bank Select Controller</B> events within the MTrk. So,|32this event exists merely to provide the user with visual feedback of what particular patch is|48used for a track. But it can also give a hint to intelligent software if patch remapping needs|to be done. For example, if the MIDI file was created on a non-General MIDI instrument, then|Doomtrainthe <B>MIDI Program Change</B> event will likely contain the|face2wrong value when played on a General MIDI instrument.texIntelligent software can use the|96Program Name event to look up the correct value for the <B>MIDI Program Change</B> event.|48|32Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it|48is expressed as a variable length quantity.|----===== Device (Port) Name ===== FF 09 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>|Bahamut|face2The name of the MIDI device (port) where the track is routed.texThis replaces the "MIDI Port"Meta-Event which some sequencers formally used to route MIDI tracks to various MIDI ports (in|128order to support more than 16 MIDI channels).|48|32For example, assume that you have a MIDI interface that has 4 MIDI output ports. They are|48listed as "MIDI Out 1", "MIDI Out 2", "MIDI Out 3", and "MIDI Out 4". If you wished a particular|MTrk to use "MIDI Out 1" then you would put a Port Name Meta-event at the beginning of the MTrk,with "MIDI Out 1" as the <I><FONT COLOR=RED><B>text</B></FONT></I>.|Cactuar|face2All MIDI events that occur in the MTrk, after a given Port Name event, will be routed to thatport.tex|160|48In a format 0 MIDI file, it would be permissible to have numerous Port Name events intermixedwith MIDI events, so that the one MTrk could address numerous ports. But that would likely make|32the MIDI file much larger than it need be. The Port Name event is useful primarily in format 1|48MIDI files, where each MTrk gets routed to one particular port.|-|TonberryNote that <B>len</B> could be a series of bytes since it is expressed as a variable length|face2quantity.tex|192----===== End of Track =====|48 FF 2F 00|32|48This event is <u>not</u> optional. It must be the last event in every MTrk. It's used as a definitive marking of the end of an MTrk. Only 1 per MTrk. |----===== Tempo ===== FF 51 03 <I><FONT COLOR=RED><B>tt tt tt</B></FONT></I>|Eden|face2Indicates a tempo change. The 3 data bytes of <B>tt tt tt</B> are the tempo in microseconds per quarter note. In otherwords, the microsecond tempo value tells you how long each one of your sequencer's "quarter notes" should be.texFor example,|224if you have the 3 bytes of 07 A1 20, then each quarter note should be 0x07A120 (or 500,000) microseconds long.|48|32So, the MIDI file format expresses tempo as "the amount of time (ie, microseconds) per quarter note".|48|}<B><FONT COLOR=RED>NOTE:</FONT></B> If there are no tempo events in a MIDI file, then theThere tempo is assumed to be 120 BPM In a format 0 file, the tempo changes are scattered throughout the one blank space MTrk. In format 1, the very first MTrk should consist of only the tempo (and time signature) eventsso that it could be read by some device capable of generating a "tempo map". It is best not toplace MIDI events in '''face1this MTrk.tex'''In format 2, I skipped that entryeachMTrk should begin with at least one initial tempo (and time signature) event.----===== SMPTE Offset ===== Content FF 54 05 <I><FONT COLOR=RED><B>hr mn se fr ff</B></FONT></I> Designates the SMPTE start time (hours, minutes, seconds, frames, subframes) of '''mc00the MTrk. It shouldbe at the start of the MTrk. The hour should not be encoded with the SMPTE format as it is in<B>MIDI Time Code</B>. In a format 1 file, the SMPTE OFFSET must be stored with the tempomap (ie, the first MTrk), and has no meaning in any other MTrk.tex'''The <FONT COLOR=RED><B>ff</B></FONT>field contains fractional frames in 100ths of a frame, even in SMPTE based MTrks which specify a differentframe subdivision for delta-'''mc09times (ie, different from the subframe setting in the MThd).tex''' ----===== Time Signature ===== FF 58 04 <I><FONT COLOR=RED><B>nn dd cc bb</B></FONT></I> Time signature is expressed as 4 numbers. <I><FONT COLOR=RED><B>nn</B></FONT></I>Each level and <I><FONT COLOR=RED><B>dd</B></FONT></I> represent the"numerator" and "denominator" of the signature as notated on sheet music. The denominator is anegative power of 2: 2 = quarter note, 3 = eighth, etc. The <I><FONT COLOR=RED><B>cc</B></FONT></I> expresses the [https:number ofMIDI clocks in a metronome click. The <I><FONT COLOR=RED><B>bb</B></FONT></finalfantasyI> parameter expresses the number of notated32nd notes in a MIDI quarter note (24 MIDI clocks).fandomThis event allows a program to relate whatMIDI thinks of as a quarter, to something entirely different.com For example, 6/8 time with ametronome click every 3 eighth notes and 24 clocks per quarter note would be the followingevent:  FF 58 04 06 03 18 08 <B><FONT COLOR=RED>NOTE:</wikiFONT></Final_Fantasy_VIII_Triple_Triad_cards fandom wiki page]B> If there are no time signature events in a MIDI file,then the time signature is in assumed to be 4/4. In a format 0 file, the time signatures changes are scattered throughout the oneMTrk. In format 1, the same order very first MTrk should consist of only the contents time signature (and tempo) eventsso that it could be read by some device capable of the tex filesgenerating a "tempo map". It is best not toplace MIDI events in this MTrk. In format 2, eachMTrk should begin with at least one initial time signature (and tempo) event.----===== Key Signature ===== FF 59 02 <I><FONT COLOR=RED><B>sf mi</B></FONT></I> <I><FONT COLOR=RED><B>sf</B></FONT></I> = -7 for 7 flats, -1 for 1 flat, etc, 0 for key of c, 1 for 1 sharp, etc.  <I><FONT COLOR=RED><B>mi</B></FONT></I> = 0 for major, 1 for minor----===== Proprietary Event ===== FF 7F <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>data</B></FONT></I> This can be used by a program to store proprietary data. The cardback first byte(s) should be a unique IDof some sort so that a program can identity whether the event belongs to it, or to some otherprogram. A 4 character (ie, ascii) ID is always the bottom right recommended for such. Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of each texturebytes since itis expressed as a variable length quantity.