tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6295

 
 
 

RTP Payload Format for MIDI

Part 4 of 7, p. 75 to 100
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 75 
A.6.  Chapter N: MIDI NoteOff and NoteOn

   In this appendix, we consider NoteOn commands with zero velocity to
   be NoteOff commands.  Readers may wish to review the Appendix A.1
   definition of "N-active commands" before reading this appendix.

   Chapter N completely protects note commands in streams that alternate
   between NoteOn and NoteOff commands for a particular note number.
   However, in rare applications, multiple overlapping NoteOn commands
   may appear for a note number.  Chapter E, described in Appendix A.7,
   augments Chapter N to completely protect these streams.

   A channel journal MUST contain Chapter N if an N-active MIDI NoteOn
   (0x9) or NoteOff (0x8) command appears in the checkpoint history.
   Figure A.6.1 shows the format for Chapter N.

Top      Up      ToC       Page 76 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|     LEN     |  LOW  | HIGH  |S|   NOTENUM   |Y|  VELOCITY   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|   NOTENUM   |Y|  VELOCITY   |             ....              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    OFFBITS    |    OFFBITS    |     ....      |    OFFBITS    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.6.1 -- Chapter N Format

   Chapter N consists of a 2-octet header followed by at least one of
   the following data structures:

   o A list of note logs to code NoteOn commands.
   o A NoteOff bitfield structure to code NoteOff commands.

   We define the header bitfield semantics in Appendix A.6.1.  We define
   the note log semantics and the NoteOff bitfield semantics in Appendix
   A.6.2.

   If one or more N-active NoteOn or NoteOff commands in the checkpoint
   history reference a note number, the note number MUST be coded in
   either the note log list or the NoteOff bitfield structure.

   The note log list MUST contain an entry for all note numbers whose
   most recent checkpoint history appearance is in an N-active NoteOn
   command.  The NoteOff bitfield structure MUST contain a set bit for
   all note numbers whose most recent checkpoint history appearance is
   in an N-active NoteOff command.

   A note number MUST NOT be coded in both structures.

   All note logs and NoteOff bitfield set bits MUST code the most recent
   N-active NoteOn or NoteOff reference to a note number in the session
   history.

   The note log list MUST obey the oldest-first ordering rule (defined
   in Appendix A.1).

Top      Up      ToC       Page 77 
A.6.1.  Header Structure

   The header for Chapter N, shown in Figure A.6.2, codes the size of
   the note list and bitfield structures.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |B|     LEN     |  LOW  | HIGH  |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.6.2 -- Chapter N Header

   The LEN field, a 7-bit integer value, codes the number of 2-octet
   note logs in the note list.  Zero is a valid value for LEN and codes
   an empty note list.

   The 4-bit LOW and HIGH fields code the number of OFFBITS octets that
   follow the note log list.  LOW and HIGH are unsigned integer values.
   If LOW <= HIGH, there are (HIGH - LOW + 1) OFFBITS octets in the
   chapter.  The value pairs (LOW = 15, HIGH = 0) and (LOW = 15, HIGH =
   1) code an empty NoteOff bitfield structure (i.e., no OFFBITS
   octets).  Other (LOW > HIGH) value pairs MUST NOT appear in the
   header.

   The B bit provides S-bit functionality (Appendix A.1) for the NoteOff
   bitfield structure.  By default, the B bit MUST be set to 1.
   However, if the MIDI command section of the previous packet (packet I
   - 1, with I as defined in Appendix A.1) includes a NoteOff command
   for the channel, the B bit MUST be set to 0.  If the B bit is set to
   0, the higher-level recovery journal elements that contain Chapter N
   MUST have S bits that are set to 0, including the top-level journal
   header.

   The LEN value of 127 codes a note list length of 127 or 128 note
   logs, depending on the values of LOW and HIGH.  If LEN = 127, LOW =
   15, and HIGH = 0, the note list holds 128 note logs, and the NoteOff
   bitfield structure is empty.  For other values of LOW and HIGH, LEN =
   127 codes that the note list contains 127 note logs.  In this case,
   the chapter has (HIGH - LOW + 1) NoteOff OFFBITS octets if LOW <=
   HIGH and has no OFFBITS octets if LOW = 15 and HIGH = 1.

Top      Up      ToC       Page 78 
A.6.2.  Note Structures

   Figure A.6.3 shows the 2-octet note log structure.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |S|   NOTENUM   |Y|  VELOCITY   |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure A.6.3 -- Chapter N Note Log

   The 7-bit NOTENUM field codes the note number for the log.  A note
   number MUST NOT be represented by multiple note logs in the note
   list.

   The 7-bit VELOCITY field codes the velocity value for the most recent
   N-active NoteOn command for the note number in the session history.
   Multiple overlapping NoteOns for a given note number may be coded
   using Chapter E, as discussed in Appendix A.7.

   VELOCITY is never zero; NoteOn commands with zero velocity are coded
   as NoteOff commands in the NoteOff bitfield structure.

   The note log does not code the execution time of the NoteOn command.
   However, the Y bit codes a hint from the sender about the NoteOn
   execution time.  The Y bit codes a recommendation to play (Y = 1) or
   skip (Y = 0) the NoteOn command recovered from the note log.  See
   Section 4.2 of [RFC4696] for non-normative guidance on the use of the
   Y bit.

   Figure A.6.1 shows the NoteOff bitfield structure as the list of
   OFFBITS octets at the end of the chapter.  A NoteOff OFFBITS octet
   codes NoteOff information for eight consecutive MIDI note numbers,
   with the most significant bit representing the lowest note number.
   The most significant bit of the first OFFBITS octet codes the note
   number 8*LOW; the most significant bit of the last OFFBITS octet
   codes the note number 8*HIGH.

   A set bit codes a NoteOff command for the note number.  In the most
   efficient coding for the NoteOff bitfield structure, the first and
   last octets of the structure contain at least one set bit.  Note that
   Chapter N does not code NoteOff velocity data.

   Note that in the general case, the recovery journal does not code the
   relative placement of a NoteOff command and a Change Control command
   for controller 64 (Damper Pedal (Sustain)).  In many cases, a
   receiver processing a loss event may deduce this relative placement

Top      Up      ToC       Page 79 
   from the history of the stream and thus determine if a NoteOff note
   is sustained by the pedal.  If such a determination is not possible,
   receivers SHOULD err on the side of silencing pedal sustains, as
   erroneously sustained notes may produce unpleasant (albeit transient)
   artifacts.

A.7.  Chapter E: MIDI Note Command Extras

   Readers may wish to review the Appendix A.1 definition of "N-active
   commands" before reading this appendix.  In this appendix, a NoteOn
   command with a velocity of 0 is considered to be a NoteOff command
   with a release velocity value of 64.

   Chapter E encodes recovery information about MIDI NoteOn (0x9) and
   NoteOff (0x8) command features that rarely appear in MIDI streams.
   Receivers use Chapter E to reduce transient artifacts for streams
   where several NoteOn commands appear for a note number without an
   intervening NoteOff.  Receivers also use Chapter E to reduce
   transient artifacts for streams that use NoteOff release velocity.
   Chapter E supplements the note information coded in Chapter N
   (Appendix A.6).

   Figure A.7.1 shows the format for Chapter E.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|     LEN     |S|   NOTENUM   |V|  COUNT/VEL  |S|  NOTENUM    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V|  COUNT/VEL  |  ....                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure A.7.1 -- Chapter E Format

   The chapter consists of a 1-octet header followed by a variable-
   length list of 2-octet note logs.  Appendix A.7.1 defines the
   bitfield format for a note log.

   The log list MUST contain at least one note log.  The 7-bit LEN
   header field codes the number of note logs in the list, minus one.  A
   channel journal MUST contain Chapter E if the rules defined in this
   appendix require that one or more note logs appear in the list.  The
   note log list MUST obey the oldest-first ordering rule (defined in
   Appendix A.1).

Top      Up      ToC       Page 80 
A.7.1.  Note Log Format

   Figure A.7.2 reproduces the note log structure of Chapter E.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |S|   NOTENUM   |V|  COUNT/VEL  |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.7.2 -- Chapter E Note Log

   A note log codes information about the MIDI note number coded by the
   7-bit NOTENUM field.  The nature of the information depends on the
   value of the V flag bit.

   If the V bit is set to 1, the COUNT/VEL field codes the release
   velocity value for the most recent N-active NoteOff command for the
   note number that appears in the session history.

   If the V bit is set to 0, the COUNT/VEL field codes a reference count
   of the number of NoteOn and NoteOff commands for the note number that
   appears in the session history.

   The reference count is set to 0 at the start of the session.  NoteOn
   commands increment the count by 1.  NoteOff commands decrement the
   count by 1.  However, a decrement that generates a negative count
   value is not performed.

   If the reference count is in the range 0-126, the 7-bit COUNT/VEL
   field codes an unsigned integer representation of the count.  If the
   count is greater than or equal to 127, COUNT/VEL is set to 127.

   By default, the count is reset to 0 whenever a Reset State command
   (Appendix A.1) appears in the session history and whenever MIDI
   Control Change commands for controller numbers 123-127 (numbers with
   All Notes Off semantics) or 120 (All Sound Off) appear in the session
   history.

A.7.2.  Log Inclusion Rules

   If the most recent N-active NoteOn or NoteOff command for a note
   number in the checkpoint history is a NoteOff command with a release
   velocity value other than 64, a note log whose V bit is set to 1 MUST
   appear in Chapter E for the note number.

Top      Up      ToC       Page 81 
   If the most recent N-active NoteOn or NoteOff command for a note
   number in the checkpoint history is a NoteOff command, and if the
   reference count for the note number is greater than 0, a note log
   whose V bit is set to 0 MUST appear in Chapter E for the note number.

   If the most recent N-active NoteOn or NoteOff command for a note
   number in the checkpoint history is a NoteOn command, and if the
   reference count for the note number is greater than 1, a note log
   whose V bit is set to 0 MUST appear in Chapter E for the note number.

   At most, two note logs MAY appear in Chapter E for a note number: one
   log whose V bit is set to 0 and one log whose V bit is set to 1.

   Chapter E codes a maximum of 128 note logs.  If the log inclusion
   rules yield more than 128 REQUIRED logs, note logs whose V bit is set
   to 1 MUST be dropped from Chapter E in order to reach the 128-log
   limit.  Note logs whose V bit is set to 0 MUST NOT be dropped.

   Most MIDI streams do not use NoteOn and NoteOff commands in ways that
   would trigger the log inclusion rules.  For these streams, Chapter E
   would never be REQUIRED to appear in a channel journal.

   The ch_never parameter (Appendix C.2.3) may be used to configure the
   log inclusion rules for Chapter E.

A.8.  Chapter T: MIDI Channel Aftertouch

   A channel journal MUST contain Chapter T if an N-active and C-active
   MIDI Channel Aftertouch (0xD) command appears in the checkpoint
   history.  Figure A.8.1 shows the format for Chapter T.

                               0
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |S|   PRESSURE  |
                              +-+-+-+-+-+-+-+-+

                      Figure A.8.1 -- Chapter T Format

   The chapter has a fixed size of 8 bits.  The 7-bit PRESSURE field
   holds the pressure value of the most recent N-active and C-active
   Channel Aftertouch command in the session history.

   Chapter T only encodes commands that are C-active and N-active.  We
   define a C-active restriction because [RP015] declares that a Control
   Change command for controller 121 (Reset All Controllers) acts to
   reset the channel pressure to 0 (see the discussion at the end of
   Appendix A.5 for a more complete rationale).

Top      Up      ToC       Page 82 
   We define an N-active restriction on the assumption that aftertouch
   commands are linked to note activity, and thus Channel Aftertouch
   commands that are not N-active are stale and should not be used to
   repair a stream.

A.9.  Chapter A: MIDI Poly Aftertouch

   A channel journal MUST contain Chapter A if a C-active Poly
   Aftertouch (0xA) command appears in the checkpoint history.  Figure
   A.9.1 shows the format for Chapter A.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|    LEN      |S|   NOTENUM   |X|  PRESSURE   |S|   NOTENUM   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X|  PRESSURE   |  ....                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure A.9.1 -- Chapter A Format

   The chapter consists of a 1-octet header followed by a variable-
   length list of 2-octet note logs.  A note log MUST appear for a note
   number if a C-active Poly Aftertouch command for the note number
   appears in the checkpoint history.  A note number MUST NOT be
   represented by multiple note logs in the note list.  The note log
   list MUST obey the oldest-first ordering rule (defined in Appendix
   A.1).

   The 7-bit LEN field codes the number of note logs in the list, minus
   one.  Figure A.9.2 reproduces the note log structure of Chapter A.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |S|   NOTENUM   |X|  PRESSURE   |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.9.2 -- Chapter A Note Log

   The 7-bit PRESSURE field codes the pressure value of the most recent
   C-active Poly Aftertouch command in the session history for the MIDI
   note number coded in the 7-bit NOTENUM field.

Top      Up      ToC       Page 83 
   As a rule, the X bit MUST be set to 0.  However, the X bit MUST be
   set to 1 if the command coded by the log appears before one of the
   following commands in the session history: MIDI Control Change
   numbers 123-127 (numbers with All Notes Off semantics) or 120 (All
   Sound Off).

   We define C-active restrictions for Chapter A because [RP015]
   declares that a Control Change command for controller 121 (Reset All
   Controllers) acts to reset the polyphonic pressure to 0 (see the
   discussion at the end of Appendix A.5 for a more complete rationale).

Appendix B.  The Recovery Journal System Chapters

B.1.  System Chapter D: Simple System Commands

   The system journal MUST contain Chapter D if an active MIDI Reset
   (0xFF), MIDI Tune Request (0xF6), MIDI Song Select (0xF3), undefined
   MIDI System Common (0xF4 and 0xF5), or undefined MIDI System Real-
   Time (0xF9 and 0xFD) command appears in the checkpoint history.

   Figure B.1.1 shows the variable-length format for Chapter D.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|B|G|H|J|K|Y|Z|  Command logs ...                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure B.1.1 -- System Chapter D Format

   The chapter consists of a 1-octet header followed by one or more
   command logs.  Header flag bits indicate the presence of command logs
   for the Reset (B = 1), Tune Request (G = 1), Song Select (H = 1),
   undefined System Common 0xF4 (J = 1), undefined System Common 0xF5 (K
   = 1), undefined System Real-Time 0xF9 (Y = 1), or undefined System
   Real-Time 0xFD (Z = 1) commands.

   Command logs appear in a list following the header, in the order that
   the flag bits appear in the header.

Top      Up      ToC       Page 84 
   Figure B.1.2 shows the 1-octet command log format for the Reset and
   Tune Request commands.

                               0
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |S|    COUNT    |
                              +-+-+-+-+-+-+-+-+

             Figure B.1.2 -- Command Log for Reset and Tune Request

   Chapter D MUST contain the Reset command log if an active Reset
   command appears in the checkpoint history.  The 7-bit COUNT field
   codes the total number of Reset commands (modulo 128) present in the
   session history.

   Chapter D MUST contain the Tune Request command log if an active Tune
   Request command appears in the checkpoint history.  The 7-bit COUNT
   field codes the total number of Tune Request commands (modulo 128)
   present in the session history.

   For these commands, the COUNT field acts as a reference count.  See
   the definition of "session history reference counts" in Appendix A.1
   for more information.

   Figure B.1.3 shows the 1-octet command log format for the Song Select
   command.

                               0
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |S|    VALUE    |
                              +-+-+-+-+-+-+-+-+

                 Figure B.1.3 -- Song Select Command Log Format

   Chapter D MUST contain the Song Select command log if an active Song
   Select command appears in the checkpoint history.  The 7-bit VALUE
   field codes the song number of the most recent active Song Select
   command in the session history.

B.1.1.  Undefined System Commands

   In this section, we define the Chapter D command logs for the
   undefined system commands.  [MIDI] reserves the undefined system
   commands 0xF4, 0xF5, 0xF9, and 0xFD for future use.  At the time of
   this writing, any MIDI command stream that uses these commands is

Top      Up      ToC       Page 85 
   non-compliant with [MIDI].  However, future versions of [MIDI] may
   define these commands, and a few products do use these commands in a
   non-compliant manner.

   Figure B.1.4 shows the variable-length command log format for the
   undefined System Common commands (0xF4 and 0xF5).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|C|V|L|DSZ|      LENGTH       |    COUNT      |  VALUE ...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  LEGAL ...                                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure B.1.4 -- Undefined System Common Command Log Format

   The command log codes a single command type (0xF4 or 0xF5, not both).
   Chapter D MUST contain a command log if an active 0xF4 command
   appears in the checkpoint history and MUST contain an independent
   command log if an active 0xF5 command appears in the checkpoint
   history.

   A Chapter D Undefined System Common command log consists of a two-
   octet header followed by a variable number of data fields.  Header
   flag bits indicate the presence of the COUNT field (C = 1), the VALUE
   field (V = 1), and the LEGAL field (L = 1).  The 10-bit LENGTH field
   codes the size of the command log and conforms to semantics described
   in Appendix A.1.

   The 2-bit DSZ field codes the number of data octets in the command
   instance that appears most recently in the session history.  If DSZ =
   0-2, the command has 0-2 data octets.  If DSZ = 3, the command has 3
   or more command data octets.

   We now define the default rules for the use of the COUNT, VALUE, and
   LEGAL fields.  The session configuration tools defined in Appendix
   C.2.3 may be used to override this behavior.

   By default, if the DSZ field is set to 0, the command log MUST
   include the COUNT field.  The 8-bit COUNT field codes the total
   number of commands of the type coded by the log (0xF4 or 0xF5)
   present in the session history, modulo 256.

   By default, if the DSZ field is set to 1-3, the command log MUST
   include the VALUE field.  The variable-length VALUE field codes a
   verbatim copy the data octets for the most recent use of the command

Top      Up      ToC       Page 86 
   type coded by the log (0xF4 or 0xF5) in the session history.  The
   most significant bit of the final data octet MUST be set to 1, and
   the most significant bit of all other data octets MUST be set to 0.

   The LEGAL field is reserved for future use.  If an update to [MIDI]
   defines the 0xF4 or 0xF5 command, an IETF Standards-Track document
   may define the LEGAL field.  Until such a document appears, senders
   MUST NOT use the LEGAL field, and receivers MUST use the LENGTH field
   to skip over the LEGAL field.  The LEGAL field would be defined by
   the IETF if the semantics of the new 0xF4 or 0xF5 command could not
   be protected from packet loss via the use of the COUNT and VALUE
   fields.

   Figure B.1.5 shows the variable-length command log format for the
   undefined System Real-Time commands (0xF9 and 0xFD).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|C|L| LENGTH  |     COUNT     |  LEGAL ...                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure B.1.5 -- Undefined System Real-Time Command Log Format

   The command log codes a single command type (0xF9 or 0xFD, not both).
   Chapter D MUST contain a command log if an active 0xF9 command
   appears in the checkpoint history and MUST contain an independent
   command log if an active 0xFD command appears in the checkpoint
   history.

   A Chapter D Undefined System Real-Time command log consists of a one-
   octet header followed by a variable number of data fields.  Header
   flag bits indicate the presence of the COUNT field (C = 1) and the
   LEGAL field (L = 1).  The 5-bit LENGTH field codes the size of the
   command log and conforms to semantics described in Appendix A.1.

   We now define the default rules for the use of the COUNT and LEGAL
   fields.  The session configuration tools defined in Appendix C.2.3
   may be used to override this behavior.

   The 8-bit COUNT field codes the total number of commands of the type
   coded by the log present in the session history, modulo 256.  By
   default, the COUNT field MUST be present in the command log.

   The LEGAL field is reserved for future use.  If an update to [MIDI]
   defines the 0xF9 or 0xFD command, an IETF Standards-Track document
   may define the LEGAL field to protect the command.  Until such a
   document appears, senders MUST NOT use the LEGAL field, and receivers

Top      Up      ToC       Page 87 
   MUST use the LENGTH field to skip over the LEGAL field.  The LEGAL
   field would be defined by the IETF if the semantics of the new 0xF9
   or 0xFD command could not be protected from packet loss via the use
   of the COUNT field.

   Finally, we note that some non-standard uses of the undefined System
   Real-Time commands act to implement non-compliant variants of the
   MIDI sequencer system.  In Appendix B.3.1, we describe resiliency
   tools for the MIDI sequencer system that provide some protection in
   this case.

B.2.  System Chapter V: Active Sense Command

   The system journal MUST contain Chapter V if an active MIDI Active
   Sense (0xFE) command appears in the checkpoint history.  Figure B.2.1
   shows the format for Chapter V.

                               0
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |S|    COUNT    |
                              +-+-+-+-+-+-+-+-+

                     Figure B.2.1 -- System Chapter V Format

   The 7-bit COUNT field codes the total number of Active Sense commands
   (modulo 128) present in the session history.  The COUNT field acts as
   a reference count.  See the definition of "session history reference
   counts" in Appendix A.1 for more information.

B.3.  System Chapter Q: Sequencer State Commands

   This appendix describes Chapter Q, the system chapter for the MIDI
   sequencer commands.

   The system journal MUST contain Chapter Q if an active MIDI Song
   Position Pointer (0xF2), MIDI Clock (0xF8), MIDI Start (0xFA), MIDI
   Continue (0xFB), or MIDI Stop (0xFC) command appears in the
   checkpoint history and if the rules defined in this appendix require
   a change in the Chapter Q bitfield contents because of the command
   appearance.

Top      Up      ToC       Page 88 
   Figure B.3.1 shows the variable-length format for Chapter Q.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|N|D|C|T| TOP |            CLOCK              | TIMETOOLS ... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure B.3.1 -- System Chapter Q Format

   Chapter Q consists of a 1-octet header followed by several optional
   fields, in the order shown in Figure B.3.1.

   Header flag bits signal the presence of the 16-bit CLOCK field (C =
   1) and the 24-bit TIMETOOLS field (T = 1).  The 3-bit TOP header
   field is interpreted as an unsigned integer, as are CLOCK and
   TIMETOOLS.  We describe the TIMETOOLS field in Appendix B.3.1.

   Chapter Q encodes the most recent state of the sequencer system.
   Receivers use the chapter to resynchronize the sequencer after a
   packet loss episode.  Chapter fields encode the on/off state of the
   sequencer, the current position in the song, and the downbeat.

   The N header bit encodes the relative occurrence of the Start, Stop,
   and Continue commands in the session history.  If an active Start or
   Continue command appears most recently, the N bit MUST be set to 1.
   If an active Stop appears most recently, or if no active Start, Stop,
   or Continue commands appear in the session history, the N bit MUST be
   set to 0.

   The C header flag, the TOP header field, and the CLOCK field act to
   code the current position in the sequence:

   o  If C = 1, the 3-bit TOP header field and the 16-bit CLOCK field
      are combined to form the 19-bit unsigned quantity 65536*TOP +
      CLOCK.  This value encodes the song position in units of MIDI
      Clocks (24 clocks per quarter note), modulo 524288.  Note that the
      maximum song position value that may be coded by the Song Position
      Pointer command is 98303 clocks (which may be coded with 17 bits)
      and that MIDI-coded songs are generally constructed to avoid
      durations longer than this value.  However, the 19-bit size may be
      useful for real-time applications, such as a drum machine MIDI
      output that is sending clock commands for long periods of time.

Top      Up      ToC       Page 89 
   o  If C = 0, the song position is the start of the song.  The C = 0
      position is identical to the position coded by C = 1, TOP = 0, and
      CLOCK = 0, for the case where the song position is less than
      524288 MIDI clocks.  In certain situations (defined later in this
      section), normative text may require the C = 0 or the C = 1, TOP =
      0, CLOCK = 0 encoding of the start of the song.

   The C, TOP, and CLOCK fields MUST be set to code the current song
   position, for both N = 0 and N = 1 conditions.  If C = 0, the TOP
   field MUST be set to 0.  See [MIDI] for a precise definition of a
   song position.

   The D header bit encodes information about the downbeat and acts to
   qualify the song position coded by the C, TOP, and CLOCK fields.

   If the D bit is set to 1, the song position represents the most
   recent position in the sequence that has played.  If D = 1, the next
   Clock command (if N = 1) or the next (Continue, Clock) pair (if N =
   0) acts to increment the song position by one clock and to play the
   updated position.

   If the D bit is set to 0, the song position represents a position in
   the sequence that has not yet been played.  If D = 0, the next Clock
   command (if N = 1) or the next (Continue, Clock) pair (if N = 0) acts
   to play the point in the song coded by the song position.  The song
   position is not incremented.

   An example of a stream that uses D = 0 coding is one whose most
   recent sequence command is a Start or Song Position Pointer command
   (both N = 1 conditions).  However, it is also possible to construct
   examples where D = 0 and N = 0.  A Start command immediately followed
   by a Stop command is coded in Chapter Q by setting C = 0, D = 0, N =
   0, TOP = 0.

   If N = 1 (coding Start or Continue), D = 0 (coding that the downbeat
   has yet to be played), and the song position is at the start of the
   song, the C = 0 song position encoding MUST be used if a Start
   command occurs more recently than a Continue command in the session
   history, and the C = 1, TOP = 0, CLOCK = 0 song position encoding
   MUST be used if a Continue command occurs more recently than a Start
   command in the session history.

B.3.1.  Non-Compliant Sequencers

   The Chapter Q description in this appendix assumes that the sequencer
   system counts off time with Clock commands, as mandated in [MIDI].
   However, a few non-compliant products do not use Clock commands to
   count off time, but instead use non-standard methods.

Top      Up      ToC       Page 90 
   Chapter Q uses the TIMETOOLS field to provide resiliency support for
   these non-standard products.  By default, the TIMETOOLS field MUST
   NOT appear in Chapter Q, and the T header bit MUST be set to 0.  The
   session configuration tools described in Appendix C.2.3 may be used
   to select TIMETOOLS coding.

   Figure B.3.2 shows the format of the 24-bit TIMETOOLS field.

                0                   1                   2
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                   TIME                        |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure B.3.2 -- TIMETOOLS Format

   The TIME field is a 24-bit unsigned integer quantity, with units of
   milliseconds.  TIME codes an additive correction term for the song
   position coded by the TOP, CLOCK, and C fields.  TIME is coded in
   network byte order (big-endian).

   A receiver computes the correct song position by converting TIME into
   units of MIDI clocks and adding it to 65536*TOP + CLOCK (assuming C =
   1).  Alternatively, a receiver may convert 65536*TOP + CLOCK into
   milliseconds (assuming C = 1) and add it to TIME.  The downbeat (D
   header bit) semantics defined in Appendix B.3 apply to the corrected
   song position.

B.4.  System Chapter F: MIDI Time Code Tape Position

   This appendix describes Chapter F, the system chapter for the MIDI
   Time Code (MTC) commands.  Readers may wish to review the Appendix
   A.1 definition of "finished/unfinished commands" before reading this
   appendix.

   The system journal MUST contain Chapter F if an active System Common
   Quarter Frame command (0xF1) or an active finished System Exclusive
   (Universal Real Time) MTC Full Frame command (F0 7F cc 01 01 hr mn sc
   fr F7) appears in the checkpoint history.  Otherwise, the system
   journal MUST NOT contain Chapter F.

Top      Up      ToC       Page 91 
   Figure B.4.1 shows the variable-length format for Chapter F.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|C|P|Q|D|POINT|  COMPLETE ...                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ...       |  PARTIAL  ...                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ...       |
      +-+-+-+-+-+-+-+-+

                    Figure B.4.1 -- System Chapter F Format

   Chapter F holds information about recent MTC tape positions coded in
   the session history.  Receivers use Chapter F to resynchronize the
   MTC system after a packet loss episode.

   Chapter F consists of a 1-octet header followed by several optional
   fields, in the order shown in Figure B.4.1.  The C and P header bits
   form a Table of Contents (TOC) and signal the presence of the 32-bit
   COMPLETE field (C = 1) and the 32-bit PARTIAL field (P = 1).

   The Q header bit codes information about the COMPLETE field format.
   If Chapter F does not contain a COMPLETE field, Q MUST be set to 0.

   The D header bit codes the tape movement direction.  If the tape is
   moving forward, or if the tape direction is indeterminate, the D bit
   MUST be set to 0.  If the tape is moving in the reverse direction,
   the D bit MUST be set to 1.  In most cases, the ordering of commands
   in the session history clearly defines the tape direction.  However,
   a few command sequences have an indeterminate direction (such as a
   session history consisting of one Full Frame command).

   The 3-bit POINT header field is interpreted as an unsigned integer.
   Appendix B.4.1 defines how the POINT field codes information about
   the contents of the PARTIAL field.  If Chapter F does not contain a
   PARTIAL field, POINT MUST be set to 7 (if D = 0) or 0 (if D = 1).

   Chapter F MUST include the COMPLETE field if an active finished Full
   Frame command appears in the checkpoint history or if an active
   Quarter Frame command that completes the encoding of a frame value
   appears in the checkpoint history.

   The COMPLETE field encodes the most recent active complete MTC frame
   value that appears in the session history.  This frame value may take
   the form of a series of 8 active Quarter Frame commands (0xF1 0x0n

Top      Up      ToC       Page 92 
   through 0xF1 0x7n for forward tape movement, 0xF1 0x7n through 0xF1
   0x0n for reverse tape movement) or may take the form of an active
   finished Full Frame command.

   If the COMPLETE field encodes a Quarter Frame command series, the Q
   header bit MUST be set to 1, and the COMPLETE field MUST have the
   format shown in Figure B.4.2.  The 4-bit fields MT0 through MT7 code
   the data (lower) nibble for the Quarter Frame commands for Message
   Type 0 through Message Type 7 [MIDI].  These nibbles encode a
   complete frame value, in addition to fields reserved for future use
   by [MIDI].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MT0  |  MT1  |  MT2  |  MT3  |  MT4  |  MT5  |  MT6  |  MT7  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure B.4.2 -- COMPLETE Field Format, Q = 1

   In this usage, the frame value encoded in the COMPLETE field MUST be
   offset by 2 frames (relative to the frame value encoded in the
   Quarter Frame commands) if the frame value codes a 0xF1 0x0n through
   0xF1 0x7n command sequence.  This offset compensates for the two-
   frame latency of the Quarter Frame encoding for forward tape
   movement.  No offset is applied if the frame value codes a 0xF1 0x7n
   through 0xF1 0x0n Quarter Frame command sequence.

   The most recent active complete MTC frame value may alternatively be
   encoded by an active finished Full Frame command.  In this case, the
   Q header bit MUST be set to 0, and the COMPLETE field MUST have the
   format shown in Figure B.4.3.  The HR, MN, SC, and FR fields
   correspond to the hr, mn, sc, and fr data octets of the Full Frame
   command.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      HR       |      MN       |      SC       |      FR       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure B.4.3 -- COMPLETE Field Format, Q = 0

Top      Up      ToC       Page 93 
B.4.1.  Partial Frames

   The most recent active session history command that encodes MTC frame
   value data may be a Quarter Frame command other than a forward-moving
   0xF1 0x7n command (which completes a frame value for forward tape
   movement) or a reverse-moving 0xF1 0x1n command (which completes a
   frame value for reverse tape movement).

   We consider this type of Quarter Frame command to be associated with
   a partial frame value.  The Quarter Frame sequence that defines a
   partial frame value MUST either start at Message Type 0 and increment
   contiguously to an intermediate Message Type less than 7 or start at
   Message Type 7 and decrement contiguously to an intermediate Message
   type greater than 0.  A Quarter Frame command sequence that does not
   follow this pattern is not associated with a partial frame value.

   Chapter F MUST include a PARTIAL field if the most recent active
   command in the checkpoint history that encodes MTC frame value data
   is a Quarter Frame command that is associated with a partial frame
   value.  Otherwise, Chapter F MUST NOT include a PARTIAL field.

   The partial frame value consists of the data (lower) nibbles of the
   Quarter Frame command sequence.  The PARTIAL field codes the partial
   frame value, using the format shown in Figure B.4.2.  Message Type
   fields that are not associated with a Quarter Frame command MUST be
   set to 0.

   The POINT header field identifies the Message Type fields in the
   PARTIAL field that code valid data.  If P = 1, the POINT field MUST
   encode the unsigned integer value formed by the lower 3 bits of the
   upper nibble of the data value of the most recent active Quarter
   Frame command in the session history.  If D = 0 and P = 1, POINT MUST
   take on a value in the range 0-6.  If D = 1 and P = 1, POINT MUST
   take on a value in the range 1-7.

   If D = 0, MT fields (Figure B.4.2) in the inclusive range from 0 up
   to and including the POINT value encode the partial frame value.  If
   D = 1, MT fields in the inclusive range from 7 down to and including
   the POINT value encode the partial frame value.  Note that, unlike
   the COMPLETE field encoding, senders MUST NOT add a 2-frame offset to
   the partial frame value encoded in PARTIAL.

   For the default semantics, if a recovery journal contains Chapter F
   and if the session history codes a legal [MIDI] series of Quarter
   Frame and Full Frame commands, the chapter always contains a COMPLETE
   or a PARTIAL field (and may contain both fields).  Thus, a one-octet
   Chapter F (C = P = 0) always codes the presence of an illegal command
   sequence in the session history (under some conditions, the C = 1, P

Top      Up      ToC       Page 94 
   = 0 condition may also code the presence of an illegal command
   sequence).  The illegal command sequence conditions are transient in
   nature and usually indicate that a Quarter Frame command sequence
   began with an intermediate Message Type.

B.5.  System Chapter X: System Exclusive

   This appendix describes Chapter X, the system chapter for MIDI System
   Exclusive (SysEx) commands (0xF0).  Readers may wish to review the
   Appendix A.1 definition of "finished/unfinished commands" before
   reading this appendix.

   Chapter X consists of a list of one or more command logs.  Each log
   in the list codes information about a specific finished or unfinished
   SysEx command that appears in the session history.  The system
   journal MUST contain Chapter X if the rules defined in Appendix B.5.2
   require that one or more logs appear in the list.

   The log list is not preceded by a header.  Instead, each log
   implicitly encodes its own length.  Given the length of the N'th list
   log, the presence of the (N+1)'th list log may be inferred from the
   LENGTH field of the system journal header (Figure 10 in Section 5 of
   the main text).  The log list MUST obey the oldest-first ordering
   rule (defined in Appendix A.1).

B.5.1.  Chapter Format

   Figure B.5.1 shows the bitfield format for the Chapter X command
   logs.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|T|C|F|D|L|STA|    TCOUNT     |     COUNT     |  FIRST ...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  DATA ...                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure B.5.1 -- Chapter X Command Log Format

   A Chapter X command log consists of a 1-octet header followed by the
   optional TCOUNT, COUNT, FIRST, and DATA fields.

   The T, C, F, and D header bits act as a Table of Contents (TOC) for
   the log.  If T is set to 1, the 1-octet TCOUNT field appears in the
   log.  If C is set to 1, the 1-octet COUNT field appears in the log.
   If F is set to 1, the variable-length FIRST field appears in the log.
   If D is set to 1, the variable-length DATA field appears in the log.

Top      Up      ToC       Page 95 
   The L header bit sets the coding tool for the log.  We define the log
   coding tools in Appendix B.5.2.

   The STA field codes the status of the command coded by the log.  The
   2-bit STA value is interpreted as an unsigned integer.  If STA is 0,
   the log codes an unfinished command.  Non-zero STA values code
   different classes of finished commands.  An STA value of 1 codes a
   cancelled command, an STA value of 2 codes a command that uses the
   "dropped 0xF7" construction, and an STA value of 3 codes all other
   finished commands.  Section 3.2 in the main text describes cancelled
   and "dropped 0xF7" commands.

   The S bit (Appendix A.1) of the first log in the list acts as the S
   bit for Chapter X.  For the other logs in the list, the S bit refers
   to the log itself.  The value of the "phantom" S bit associated with
   the first log is defined by the following rules:

   o  If the list codes one log, the phantom S-bit value is the same as
      the Chapter X S-bit value.

   o  If the list codes multiple logs, the phantom S-bit value is the
      logical OR of the S-bit value of the first and second command logs
      in the list.

   In all other respects, the S bit follows the semantics defined in
   Appendix A.1.

   The FIRST field (present if F = 1) encodes a variable-length unsigned
   integer value that sets the coverage of the DATA field.

   The FIRST field (present if F = 1) encodes a variable-length unsigned
   integer value that specifies which SysEx data bytes are encoded in
   the DATA field of the log.  The FIRST field consists of an octet
   whose most significant bit is set to 0, optionally preceded by one or
   more octets whose most significant bit is set to 1.  The algorithm
   shown in Figure B.5.2 decodes this format into an unsigned integer to
   yield the value dec(FIRST).  FIRST uses a variable-length encoding
   because dec(FIRST) references a data octet in a SysEx command, and a
   SysEx command may contain an arbitrary number of data octets.

      One-Octet FIRST value:

         Encoded form: 0ddddddd
         Decoded form: 00000000 00000000 00000000 0ddddddd

Top      Up      ToC       Page 96 
      Two-Octet FIRST value:

         Encoded form: 1ccccccc 0ddddddd
         Decoded form: 00000000 00000000 00cccccc cddddddd

      Three-Octet FIRST value:

         Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
         Decoded form: 00000000 000bbbbb bbcccccc cddddddd

      Four-Octet FIRST value:

         Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
         Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd


              Figure B.5.2 -- Decoding FIRST Field Formats

   The DATA field (present if D = 1) encodes a modified version of the
   data octets of the SysEx command coded by the log.  Status octets
   MUST NOT be coded in the DATA field.

   If F = 0, the DATA field begins with the first data octet of the
   SysEx command and includes all subsequent data octets for the command
   that appear in the session history.  If F = 1, the DATA field begins
   with the (dec(FIRST) + 1)'th data octet of the SysEx command and
   includes all subsequent data octets for the command that appear in
   the session history.  Note that the word "command" in the
   descriptions above refers to the original SysEx command as it appears
   in the source MIDI data stream, not to a particular MIDI list SysEx
   command segment.

   The length of the DATA field is coded implicitly, using the most
   significant bit of each octet.  The most significant bit of the final
   octet of the DATA field MUST be set to 1.  The most significant bit
   of all other DATA octets MUST be set to 0.  This coding method relies
   on the fact that the most significant bit of a MIDI data octet is 0
   by definition.  Apart from this length-coding modification, the DATA
   field encodes a verbatim copy of all data octets it encodes.

B.5.2.  Log Inclusion Semantics

   Chapter X offers two tools to protect SysEx commands: the "recency"
   tool and the "list" tool.  The tool definitions use the concept of
   the "SysEx type" of a command, which we now define.

   Each SysEx command instance in a session, excepting MTC Full Frame
   commands, is said to have a "SysEx type".  Types are used in equality

Top      Up      ToC       Page 97 
   comparisons: two SysEx commands in a session are said to have "the
   same SysEx type" or "different SysEx types".

   If efficiency is not a concern, a sender may follow a simple typing
   rule: every SysEx command in the session history has a different
   SysEx type, and thus no two commands in the session have the same
   type.

   To improve efficiency, senders MAY implement exceptions to this rule.
   These exceptions declare that certain sets of SysEx command instances
   have the same SysEx type.  Any command not covered by an exception
   follows the simple rule.  We list exceptions below:

   o  All commands with identical data octet fields (same number of data
      octets, same value for each data octet) have the same type.  This
      rule MUST be applied to all SysEx commands in the session or not
      at all.  Note that the implementation of this exception requires
      no sender knowledge of the format and semantics of the SysEx
      commands in the stream, merely the ability to count and compare
      octets.

   o  Two instances of the same command whose semantics set or report
      the value of the same "parameter" have the same type.  The
      implementation of this exception requires specific knowledge of
      the format and semantics of SysEx commands.  In practice, a sender
      implementation chooses to support this exception for certain
      classes of commands (such as the Universal System Exclusive
      commands defined in [MIDI]).  If a sender supports this exception
      for a particular command in a class (for example, the Universal
      Real Time System Exclusive message for Master Volume, F0 F7 cc 04
      01 vv vv F7, defined in [MIDI]), it MUST support the exception to
      all instances of this particular command in the session.

   We now use this definition of "SysEx type" to define the "recency"
   tool and the "list" tool for Chapter X.

   By default, the Chapter X log list MUST code sufficient information
   to protect the rendered MIDI performance from indefinite artifacts
   caused by the loss of all finished or unfinished active SysEx
   commands that appear in the checkpoint history (excluding finished
   MTC Full Frame commands, which are coded in Chapter F (Appendix
   B.4)).

   To protect a command of a specific SysEx type with the recency tool,
   senders MUST code a log in the log list for the most recent finished
   active instance of the SysEx type that appears in the checkpoint
   history.  Additionally, if an unfinished active instance of the SysEx
   type appears in the checkpoint history, senders MUST code a log in

Top      Up      ToC       Page 98 
   the log list for the unfinished command instance.  The L header bit
   of both command logs MUST be set to 0.

   To protect a command of a specific SysEx type with the list tool,
   senders MUST code a log in the Chapter X log list for each finished
   or unfinished active instance of the SysEx type that appears in the
   checkpoint history.  The L header bit of list tool command logs MUST
   be set to 1.

   As a rule, a log REQUIRED by the list or recency tool MUST include a
   DATA field that codes all data octets that appear in the checkpoint
   history for the SysEx command instance associated with the log.  The
   FIRST field MAY be used to configure a DATA field that minimally
   meets this requirement.

   An exception to this rule applies to cancelled commands (defined in
   Section 3.2).  REQUIRED command logs associated with cancelled
   commands MAY be coded with no DATA field.  However, if DATA appears
   in the log, DATA MUST code all data octets that appear in the
   checkpoint history for the command associated with the log.

   As defined by the preceding text in this section, by default all
   finished or unfinished active SysEx commands that appear in the
   checkpoint history (excluding finished MTC Full Frame commands) MUST
   be protected by the list tool or the recency tool.

   For some MIDI source streams, this default yields a Chapter X whose
   size is too large.  For example, imagine that a sender begins to
   transcode a SysEx command with 10,000 data octets onto a UDP RTP
   stream "on the fly", by sending SysEx command segments as soon as
   data octets are delivered by the MIDI source.  After 1000 octets have
   been sent, the expansion of Chapter X yields an RTP packet that is
   too large to fit in the Maximum Transmission Unit (MTU) for the
   stream.

   In this situation, if a sender uses the closed-loop sending policy
   for SysEx commands, the RTP packet size may always be capped by
   stalling the stream.  In a stream stall, once the packet reaches a
   maximum size, the sender refrains from sending new packets with non-
   empty MIDI Command Sections until receiver feedback permits the
   trimming of Chapter X.  If the stream permits arbitrary commands to
   appear between SysEx segments (selectable during configuration using
   the tools defined in Appendix C.1), the sender may stall the SysEx
   segment stream but continue to code other commands in the MIDI list.

   Stalls are a workable but suboptimal solution to Chapter X size
   issues.  As an alternative to stalls, senders SHOULD take preemptive

Top      Up      ToC       Page 99 
   action during session configuration to reduce the anticipated size of
   Chapter X, using the methods described below:

   o  Partitioned transport.  Appendix C.5 provides tools for sending a
      MIDI name space over several RTP streams.  Senders may use these
      tools to map a MIDI source into a low-latency UDP RTP stream (for
      channel commands and short SysEx commands) and a reliable
      [RFC4571] TCP stream (for bulk-data SysEx commands).  The
      cm_unused and cm_used parameters (Appendix C.1) may be used to
      communicate the nature of the SysEx command partition.  As TCP is
      reliable, the RTP MIDI TCP stream would not use the recovery
      journal.  To minimize transmission latency for short SysEx
      commands, senders may begin segmental transmission for all SysEx
      commands over the UDP stream and then cancel the UDP transmission
      of long commands (using tools described in Section 3.2) and resend
      the commands over the TCP stream.

   o  Selective protection.  Journal protection may not be necessary for
      all SysEx commands in a stream.  The ch_never parameter (Appendix
      C.2) may be used to communicate which SysEx commands are excluded
      from Chapter X.

B.5.3.  TCOUNT and COUNT Fields

   If the T header bit is set to 1, the 8-bit TCOUNT field appears in
   the command log.  If the C header bit is set to 1, the 8-bit COUNT
   field appears in the command log.  TCOUNT and COUNT are interpreted
   as unsigned integers.

   The TCOUNT field codes the total number of SysEx commands of the
   SysEx type coded by the log that appear in the session history at the
   moment after the (finished or unfinished) command coded by the log
   enters the session history.

   The COUNT field codes the total number of SysEx commands that appear
   in the session history, excluding commands that are excluded from
   Chapter X via the ch_never parameter (Appendix C.2) at the moment
   after the (finished or unfinished) command coded by the log enters
   the session history.

   Command counting for TCOUNT and COUNT uses modulo-256 arithmetic.
   MTC Full Frame command instances (Appendix B.4) are included in
   command counting if the TCOUNT and COUNT definitions warrant their
   inclusion, as are cancelled commands (Section 3.2).

   Senders use the TCOUNT and COUNT fields to track the identity and
   (for TCOUNT) the sequence position of a command instance.  Senders
   MUST use the TCOUNT or COUNT fields if identity or sequence

Top      Up      ToC       Page 100 
   information is necessary to protect the command type coded by the
   log.

   If a sender uses the COUNT field in a session, the final command log
   in every Chapter X in the stream MUST code the COUNT field.  This
   rule lets receivers resynchronize the COUNT value after a packet
   loss.



(page 100 continued on part 5)

Next RFC Part