Part 5 of a series of articles detailing the MIDI protocol.

One of the three parts of the MIDI protocol is the data storage format specification (remember, the other two are the message format and the hardware interface specification). The message format was discussed in the first three articles of the series, now is the time for the storage format. It was proposed by the MMA organization in late 1987 and was named Standard MIDI Files (SMF).

The purpose of MIDI files is to allow events (that is, time-stamped MIDI messages) to be exchanged between various devices and programs. Before the advent of standard MIDI files, an arrangement prepared in one sequencer could not be loaded into another due to format incompatibilities. This is not to say that with the advent of SMF, all sequencer manufacturers have switched to this format. There are several reasons for this, and we will also talk about them today.

Since the storage of information is directly related to the device of sequencers, we will dwell on this matter in more detail, but only to the extent that is necessary to understand SMF. And, undoubtedly, we will devote one of the next articles in the cycle to sequencers.

Developments
A time-stamped MIDI message is called event... Different units can be used to indicate time - ticks, internal pulses, time in SMPTE format, etc. It is important to understand the fundamental difference between an event and a message. The message "lives" for a fraction of a millisecond of real time - from the moment it is generated by the source to the moment it is sent to the receiver for execution. It can be caught in the process of transmission over a MIDI cable in the form of a set of pulses. An event is a few bytes of information recorded in the device's memory, on the basis of which a message will be generated in the future, at the appointed time.

For example, the sequencer can store a "pick a note" event with a timestamp of 100ms from the start of playback. You can edit this event in two dimensions: firstly, change the parameters of the MIDI message itself (in this case, the pitch or dynamics of the note), and secondly, move the note along the track, that is, change the execution time of the message.

Events appear in the sequencer's memory while recording MIDI messages. When you press the Record button, the sequencer turns on the hardware pulse generator (ticks) and starts "listening" to the specified MIDI input. For example, when you press a key, the input receives the "pick a note" message. The sequencer looks - aha, the message arrived at the 20th tick, and writes it into memory with a label 20. After a couple of seconds, they released the key - the message "remove the note" came, the internal generator happily waved 64 ticks to the sequencer at that moment. The sequencer saves a message with label 64. Now we are dealing with two events - Note On and Note Off. The pulse generator is turned on again during playback. When the 20th tick comes up, a Note On message is sent to the MIDI output of the sequencer, the 64th tick is a Note Off. We recorded and then played back the performer's actions!

Obviously, the same can be done offline, that is, without the need for live performance. By clicking the mouse in the right place on the track (and having selected the note duration in advance), we will build in the memory of the sequencer exactly the previous picture.

Memory types
Now is the time to apply two daunting computer terms: primary and secondary memory. Primary (or internal) memory is the sequencer memory where messages are recorded and events are stored throughout the entire session. The contents of this memory are cleared when the power is turned off. This interpretation is more suitable for hardware sequencers. In software sequencers, primary memory is simply the computer's RAM. To store the contents of the primary memory for a long time, secondary memory is used, or, in other words, data carriers. This can be a floppy disk, hard drive, smart card, and the like.

The amount of primary memory in hardware sequencers and workstations (remember, a workstation is a tone generator and sequencer in one box) is usually expressed in the number of stored notes (for example, 200 thousand). Sometimes the volume is expressed in events, in this case you need to be on your guard - one note requires two events to store (pressing and releasing a key), and turning the pitch wheel or aftertouch can generate up to 100 or more events. It happens that the memory size of a sequencer is expressed in native computer units - kilobytes. But this is also not very convenient - one event can occupy a different number of bytes (from five to several tens).

In modern software sequencers, few people care about the amount of primary memory - even on a machine with 128 MB of RAM, you can forget about any restrictions when working with MIDI data. In addition, there are sequencers that can play an arrangement directly from disk, without loading it into the primary memory (and, by the way, record it too), which generally erases the distinction between the two types of memory.

In secondary memory, data is usually written to a file. Most sequencers have their own proprietary format of this file, which makes it difficult to exchange arrangements created in different devices or programs. It was stated earlier that this was the main reason for the creation of SMF.

Time measurement
In fact, there are no "ticks" inside the sequencer. There is a hardware timer that generates pulses with a strictly constant frequency (for example, every microsecond). Forcing musicians to measure time in microseconds would be a monstrous mockery, as, indeed, in other units of real time (seconds, minutes). Musicians are used to thinking in bars and beats, and expressing time in relative units (note durations), depending on the current tempo.

"No problem," the manufacturers replied, "let them measure it as it is more convenient for them." Only the minimum unit of measurement will not be some 32nd duration, but a conventionally taken tick (the unit is even smaller, so that, for example, one thirty-second can contain 48 ticks). Since since the classical era, the pace has been measured by the number of quarters per minute (BPM, beats per minute), then they decided to take a quarter as the main duration and indicate the number of ticks per quarter - PPQN (Pulse Per Quarter Note). The larger the PPQN, the better the resolution of the sequencer and the more accurate in time it can capture messages during recording and output them to the MIDI output during playback. Most sequencers allow you to set PPQN arbitrarily - for example, from 32 to 1536 ticks per quarter (modern sequencers - up to 15360 PPQN).

A tick is a rate-dependent unit: the faster the rate, the shorter the interval between ticks in real-time units. This interval can be found by the formula in Fig. 1.

For example, at 120 BPM and 96 PPQN, ticks will follow every 5.208 milliseconds. At the same resolution and 180 BPM, the interval between ticks will be reduced to 3.472 ms. How does a sequencer count ticks if its internal timer pulses every microsecond? It's very simple: based on the current tempo and resolution in a quarter, exactly according to the specified formula. Since one millisecond contains 1000 microseconds, in the last example the sequencer will generate another tick when it receives 3472 pulses from the timer.

The position of an event on the timeline is set in the sequencer, usually in the "bars: beats: ticks" format, for example, 22: 3: 152. That is: the twenty-second measure, the third beat, the 152nd tick from the beginning of the third beat. This principle of timing (the English term - Timebase) is called musical, because it is familiar and convenient for musicians. Please note that you need to know the current time signature to work in this format. That is, how many beats the measure contains and what each beat is equal to.

So, with a 4/4 time signature, a beat is equal to a quarter, and a measure contains four beats. At 384 PPQN resolution, there will be 384 ticks in one beat, and there will be 1536 ticks in each tick (384 x 4). At 6/8 and the same resolution, one beat will be 192 ticks (an eighth is half as long as a quarter), and a beat will be six beats, or 1152 ticks (192 x 6). Thus, writing 22: 3: 152 in the first case means 35096 ticks from the beginning of the song (22 x 1536 + 3 x 384 + 152), and in the second - 26072 ticks (22 x 1152 + 3 x 192 + 152).

So, to determine the position of an event in real time units based on the "bars: beats: ticks" format, you need to know three parameters: the current tempo, time signature and resolution in ticks per quarter (PPQN).

There is another possibility of timing, when the position of an event on a track is expressed in absolute units that do not depend on the tempo, most often in the SMPTE time format - "hours: minutes: seconds: frames". This principle of timing is called "time-code-based" (timecode-based, absolute). The need for it arises when the sequencer is working together with a tape recorder or film / video equipment. Editing operations with film, video and audio material, specifying the positions of the beginning and end of the recording is more convenient to perform, being tied to an absolute scale, and not to measures and beats.

In this case, the coordinate of the event on the time ruler depends on the current tempo. So with a tempo of 120 BPM, the first beat of the second measure can have an SMPTE time of 00: 00: 02: 00, and with a tempo of 60 BPM - 00: 00: 04: 00. When an event is positioned within a frame (between seconds), its coordinate will also differ with a different frame format (number of frames per second). You can read more about SMPTE and MIDI Time Code in the previous article in the series.

Variable length quantities
Enough lyrical digressions, now our task is to understand the data storage format. And the first challenge that SMF developers faced was how to keep the timing of the event.

There are two options here: to store for each event the time from the beginning of the song, or from the last event before it (on the same channel). However, the first option is not rational, because most often the interval between events is small, neighboring events have execution times close to each other. So, in a passage of three notes, the first can have a time, say, 22: 3: 152, the second - 22: 3: 244, the third - 22: 3: 288. To store these numbers (translated into ticks from the beginning of the song), you need to reserve at least four bytes for each. If you go along the second path, then instead of three large numbers, you can save one large starting (22: 3: 152), and after it - two small ones, the difference in ticks between the first and second, and the second and third notes (in this case, 92 and 44), one byte is enough for them. But still, the problem remains: depending on the event, you need to allocate a different number of bytes to save time.

If SMF was being developed at the present time (and even by Microsoft, which generally cares little about the size of its files and the required memory), this problem would be turned a blind eye. We allocated a fixed field for saving time, say, 8 bytes per event, and did not suffer. However, in 1988, primary (RAM) memory was very expensive, every byte was counted, and the secondary (disk media) had a very modest size. Therefore, the SMF developers wanted to get the most compact format possible.

It was decided to keep delta time, that is, the difference in ticks between this event and the previous one (or the beginning of the song). For example, if the first event - the hitting of the note to the first octave - occurred at the time of 40 ticks from the beginning of the song, then its delta time will be 40. If after four ticks the note F is played, then its delta time will be 4. If two events occur simultaneously, then one of them is assigned a delta time equal to zero. If the event occurs exactly at the beginning of the song, it also has a delta time of zero. However, the next event can happen in an hour and a half (that is, in several million ticks). How to be in this case? After all, memory needs to be saved, and it is undesirable to allocate a fixed field of several bytes for delta time.

The so-called variable lengths... They provide a convenient way to write integers, from smallest to largest, without having to allocate a fixed number of bytes for the number. The bits of the original number are packed into one or more bytes: each byte has seven bits (on the right, bits 0 through 6). The most significant bit in a byte is service; all bytes in the series, except for the last one, must contain one, the last one - zero. Several packaging examples are shown in Fig. 4.

For example, you need to pack the number 64 (hex 0x40) into variable length format. In binary form, this number is written as 0100 0000. There are just seven significant bits, so this number is packed into one byte unchanged - 0100 0000 (it is also the last byte of the series), the most significant bit is 0.

Now the number is 128 (0x80). In binary form, it is written as 1000 0000. There are eight significant bits, so everything will not fit into one byte, you need to split it into two. The first byte must have one in the most significant bit, the second (as the terminating byte of the series) - zero. We put the seven least significant bits of the original number in the second byte, it turns out 0 000 0000. We put the remaining one bit (one) on the right side of the first byte - we get 1000 0001. As a result, the number 0x80 is written as two bytes: 0x81 0x00. Unpacking is very simple. We do not know in advance how many bytes are in the series. We read the first byte - 1000 0001. The most significant service bit (1) indicates that this is not the last byte of the series, there are more bytes. We discard the service unit, leaving seven bits - 000 0001. Read the second byte - 0000 0000. The most significant service bit (0) indicates that this is the final byte of the series (that is, there are only two bytes in the series). We discard the service bit. There are also seven bits left - 000 0000. We add to them on the left seven bits allocated from the first byte, we get 000 0001 000 0000. Discarding the first six zeros, we get the required number 1000 0000 (0x80).

So, the method of variable lengths allows different numbers of bytes to be allocated for different numbers: for numbers in the range from 0 to 127 - one byte, from 128 to 16383 - two bytes, and so on. The maximum number represented in this way is, in principle, not limited. However, in SMF, the burst length is limited to four bytes (three with the most significant bit set and one terminating with a zero). As a result, the maximum delta time can be 0x0FFFFFFF (or 268 435 455 ticks), which at a rate of 500 BPM and a resolution of 96 PPQN is about four days. More than enough!

In the form of variable length values, the SMF indicates not only the delta time, but also the length of some events.

Interchange File Format (IFF)
The structure of the standard MIDI file is almost entirely derived from the IFF (Interchange File Format), developed in 1985 by Electronic Arts. It is a data storage and exchange format that has made life easier for both users and software developers for nearly twenty years. Electronic Arts not only provided open source documentation, but also the C source code for reading and writing IFF files.

The IFF format is backward compatible and extensible. The former means that the new version of the program can read files created by the previous version without any problems. Second, you don't need to invent a new format to store additional information; it is enough to enter your own extension into the IFF. The structure of the format allows programs from different manufacturers to exchange data that do not have appropriate business agreements among themselves. All this pleases the users - having saved the data in the IFF format, they are no longer chained to the closed format of their system and can use the data in any IFF-compatible software and hardware environment.

An IFF file is a collection of data organized in such a way that different, unrelated programs can read it. On the other hand, the program can store specific information in the IFF that is meaningful only to itself. The IFF structure makes this easy. Other programs that do not know how to handle such information can ignore it without compromising the reading of the main content.

There are several types of IFF files. For example, ILBM and GIFF files contain graphic information, SMUS files contain musical notation, and AIFF and WAVE files contain digital audio.

An IFF file is made up of similar elements called chunks. A block is a data structure consisting of an alphabetic identifier (four ASCII characters), a block size (four bytes), and the data itself (Figure 5). It is convenient to think of a block as a shell in which the data is "wrapped". The data itself can contain anything: graphics, text, animation, sound, a set of 3D objects, and so on.

Blocks in the IFF file can be nested, fig. 6. In fact, an IFF file is nothing more than a top-level block containing one or more other blocks inside it. This principle of data storage allows you to "wrap" several heterogeneous data into a file, including several IFF files, which already resembles a file system inside a file. True, with nested data organization, there is one drawback - the file becomes difficult to interpret, to isolate blocks from it.

Most IFF files contain a top-level block with the identifier "FORM". It includes other blocks (Fig. 7). The only data in the FORM block is four bytes describing the file type (eg "ILBM", InterLeaved Bit Map). Immediately behind these are nested blocks such as "BMHD" (image header), "CMAP" (palette), and "BODY" (pixels themselves). The names of the blocks and the data format are invented by the developer of the specific file type. Other programs, if they come across a block with an unfamiliar name, can safely skip it, guided by the field containing the block length.

All numeric data in IFF files are stored in big-endian order, that is, the most significant byte of the number (MSB) is stored first, then the least significant byte. See the sidebar for more on this. Blocks within a file must always start with an even byte. If the previous block contains an odd number of bytes, it is padded with a null byte to be even.

SMF structure
Standard MIDI files, like IFF files, are made up of Chunks. There are two types of chunks in total: Header Chunk and Track Chunk. There can be only one header block and one or more track blocks in an SMF file. The block has a typical IFF structure: the first four bytes are the identifier, the next four bytes are the block length in bytes, excluding the eight bytes type / length. The header block identifier is four "MThd" characters, and the track block identifier is four "MTrk" characters. This structure will allow new block types to be defined in the future, and an unfamiliar block can be easily ignored based on its length. The SMF specification warns: "Programs should be prepared to ignore blocks of unknown types when they encounter them."

The header block contains general information about the file, the track block contains the stream of MIDI messages with timestamps. In addition, the MIDI file stores additional information necessary for sequencers: tempo, time signature, key, metronome settings, and the like. This information is not transmitted via the MIDI interface, and the events that form it are called meta-events.

A MIDI file always starts with a header block followed by one or more track blocks (Figure 9). That is, any standard MIDI file starts with the four letters "M", "T", "h", "d". This means that the MIDI file does not comply with the IFF specification (which requires that every IFF-compliant file begins with a top-level block of one of three types - "FORM", "CAT" or "LIST"). There are other differences: SMFs cannot contain nested blocks, and the block length does not have to be even. However, converting an SMF to an IFF compliant file is straightforward. It is enough to pad the blocks of odd length with a zero byte (if any) and put all the contents in the FORM block. A similar operation is used in the RMID format proposed by Microsoft (see sidebar).