Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4695

RTP Payload Format for MIDI

Pages: 169
Obsoleted by:  6295
Part 4 of 7 – Pages 71 to 95
First   Prev   Next

ToP   noToC   RFC4695 - Page 71   prevText

A.5. Chapter W: MIDI Pitch Wheel

A channel journal MUST contain Chapter W if a C-active MIDI Pitch Wheel (0xE) command appears in the checkpoint history. Figure A.5.1 shows the format for Chapter W. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| FIRST |R| SECOND | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A.5.1 -- Chapter W format The chapter has a fixed size of 16 bits. The FIRST and SECOND fields are the 7-bit values of the first and second data octets of the most recent active Pitch Wheel command in the session history. Note that Chapter W encodes C-active commands and thus does not encode active commands that are not C-active (see the second-to-last paragraph of Appendix A.1 for an explanation of chapter inclusion text in this regard). Chapter W does not encode "active but not C-active" commands because [RP015] declares that Control Change commands for controller number 121 (Reset All Controllers) act to reset the Pitch Wheel value to 0. If Chapter W encoded "active but not C-active" commands, a repair operation following a Reset All Controllers command could incorrectly repair the stream with a stale Pitch Wheel value.

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   noToC   RFC4695 - Page 72
       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   noToC   RFC4695 - Page 73

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   noToC   RFC4695 - Page 74

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   noToC   RFC4695 - Page 75
   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   noToC   RFC4695 - Page 76

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 appear 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. 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
ToP   noToC   RFC4695 - Page 77
   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   noToC   RFC4695 - Page 78
   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. 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
ToP   noToC   RFC4695 - Page 79
   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).

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. 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
ToP   noToC   RFC4695 - Page 80
   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 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.
ToP   noToC   RFC4695 - Page 81
   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.

   Chapter D 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
   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.
ToP   noToC   RFC4695 - Page 82
   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.

   Chapter D 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
   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.
ToP   noToC   RFC4695 - Page 83
   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. 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
ToP   noToC   RFC4695 - Page 84
   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 re-synchronize 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.

     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.
ToP   noToC   RFC4695 - Page 85
   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. 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.
ToP   noToC   RFC4695 - Page 86
   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. 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
ToP   noToC   RFC4695 - Page 87
   Chapter F holds information about recent MTC tape positions coded in
   the session history.  Receivers use Chapter F to re-synchronize 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
   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].
ToP   noToC   RFC4695 - Page 88
       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
   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

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.
ToP   noToC   RFC4695 - Page 89
   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 indicates the Message Type fields in the
   PARTIAL field 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 = 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
ToP   noToC   RFC4695 - Page 90
   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 log. 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. 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 F7" construction, and an STA value of 3 codes all other finished commands. Section 3.2 in the main text describes cancelled and "dropped F7" 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
ToP   noToC   RFC4695 - Page 91
   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

        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
ToP   noToC   RFC4695 - Page 92
   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 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
ToP   noToC   RFC4695 - Page 93
        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
   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.
ToP   noToC   RFC4695 - Page 94
   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 sub-optimal solution to Chapter X size
   issues.  As an alternative to stalls, senders SHOULD take preemptive
   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.
ToP   noToC   RFC4695 - Page 95
     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 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 95 continued on part 5)

Next Section