tech-invite   World Map     

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

RFC 4695

 
 
 

RTP Payload Format for MIDI

Part 3 of 7, p. 48 to 70
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 48 
A.  The Recovery Journal Channel Chapters

A.1.  Recovery Journal Definitions

   This appendix defines the terminology and the coding idioms that are
   used in the recovery journal bitfield descriptions in Section 5
   (journal header structure), Appendices A.2 to A.9 (channel journal
   chapters) and Appendices B.1 to B.5 (system journal chapters).

   We assume that the recovery journal resides in the journal section of
   an RTP packet with sequence number I ("packet I") and that the
   Checkpoint Packet Seqnum field in the top-level recovery journal
   header refers to a previous packet with sequence number C (an
   exception is the self-referential C = I case).  Unless stated
   otherwise, algorithms are assumed to use modulo 2^16 arithmetic for
   calculations on 16-bit sequence numbers and modulo 2^32 arithmetic
   for calculations on 32-bit extended sequence numbers.

   Several bitfield coding idioms appear throughout the recovery journal
   system, with consistent semantics.  Most recovery journal elements
   begin with an "S" (Single-packet loss) bit.  S bits are designed to
   help receivers efficiently parse through the recovery journal
   hierarchy in the common case of the loss of a single packet.

   As a rule, S bits MUST be set to 1.  However, an exception applies if
   a recovery journal element in packet I encodes data about a command
   stored in the MIDI command section of packet I - 1.  In this case,
   the S bit of the recovery journal element MUST be set to 0.  If a
   recovery journal element has its S bit set to 0, all higher-level
   recovery journal elements that contain it MUST also have S bits that
   are set to 0, including the top-level recovery journal header.

   Other consistent bitfield coding idioms are described below:

     o R flag bit.  R flag bits are reserved for future use.  Senders
       MUST set R bits to 0.  Receivers MUST ignore R bit values.

     o LENGTH field.  All fields named LENGTH (as distinct from LEN)
       code the number of octets in the structure that contains it,
       including the header it resides in and all hierarchical levels
       below it.  If a structure contains a LENGTH field, a receiver
       MUST use the LENGTH field value to advance past the structure
       during parsing, rather than use knowledge about the internal
       format of the structure.

Top      Up      ToC       Page 49 
   We now define normative terms used to describe recovery journal
   semantics.

     o Checkpoint history.  The checkpoint history of a recovery journal
       is the concatenation of the MIDI command sections of packets C
       through I - 1.  The final command in the MIDI command section for
       packet I - 1 is considered the most recent command; the first
       command in the MIDI command section for packet C is the oldest
       command.  If command X is less recent than command Y, X is
       considered to be "before Y".  A checkpoint history with no
       commands is considered to be empty.  The checkpoint history never
       contains the MIDI command section of packet I (the packet
       containing the recovery journal), so if C == I, the checkpoint
       history is empty by definition.

     o Session history.  The session history of a recovery journal is
       the concatenation of MIDI command sections from the first packet
       of the session up to packet I - 1.  The definitions of command
       recency and history emptiness follow those in the checkpoint
       history.  The session history never contains the MIDI command
       section of packet I, and so the session history of the first
       packet in the session is empty by definition.

     o Finished/unfinished commands.  If all octets of a MIDI command
       appear in the session history, the command is defined as being
       finished.  If some but not all octets of a command appear in the
       session history, the command is defined as being unfinished.
       Unfinished commands occur if segments of a SysEx command appear
       in several RTP packets.  For example, if a SysEx command is coded
       as 3 segments, with segment 1 in packet K, segment 2 in packet K
       + 1, and segment 3 in packet K + 2, the session histories for
       packets K + 1 and K + 2 contain unfinished versions of the
       command.  A session history contains a finished version of a
       cancelled SysEx command if the history contains the cancel
       sublist for the command.

     o Reset State commands.  Reset State (RS) commands reset renderers
       to an initialized "powerup" condition.  The RS commands are:
       System Reset (0xFF), General MIDI System Enable (0xF0 0x7E 0xcc
       0x09 0x01 0xF7), General MIDI 2 System Enable (0xF0 0x7E 0xcc
       0x09 0x03 0xF7), General MIDI System Disable (0xF0 0x7E 0xcc 0x09
       0x00 0xF7), Turn DLS On (0xF0 0x7E 0xcc 0x0A 0x01 0xF7), and Turn
       DLS Off (0xF0 0x7E 0xcc 0x0A 0x02 0xF7).  Registrations of
       subrender parameter token values (Appendix C.6.2) and IETF
       standards-track documents MAY specify additional RS commands.

     o Active commands.  Active command are MIDI commands that do not
       appear before a Reset State command in the session history.

Top      Up      ToC       Page 50 
     o N-active commands.  N-active commands are MIDI commands that do
       not appear 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), and any Reset State
       command.

     o C-active commands.  C-active commands are MIDI commands that do
       not appear before one of the following commands in the session
       history:  MIDI Control Change number 121 (Reset All Controllers)
       and any Reset State command.

     o Oldest-first ordering rule.  Several recovery journal chapters
       contain a list of elements, where each element is associated with
       a MIDI command that appears in the session history.  In most
       cases, the chapter definition requires that list elements be
       ordered in accordance with the "oldest-first ordering rule".
       Below, we normatively define this rule:

       Elements associated with the most recent command in the session
       history coded in the list MUST appear at the end of the list.

       Elements associated with the oldest command in the session
       history coded in the list MUST appear at the start of the list.

       All other list elements MUST be arranged with respect to these
       boundary elements, to produce a list ordering that strictly
       reflects the relative session history recency of the commands
       coded by the elements in the list.

     o Parameter system.  A MIDI feature that provides two sets of
       16,384 parameters to expand the 0-127 controller number space.
       The Registered Parameter Names (RPN) system and the Non-
       Registered Parameter Names (NRPN) system each provides 16,384
       parameters.

     o Parameter system transaction.  The value of RPNs and NRPNs are
       changed by a series of Control Change commands that form a
       parameter system transaction.  A canonical transaction begins
       with two Control Change commands to set the parameter number
       (controller numbers 99 and 98 for NRPNs, controller numbers 101
       and 100 for RPNs).  The transaction continues with an arbitrary
       number of Data Entry (controller numbers 6 and 38), Data
       Increment (controller number 96), and Data Decrement (controller
       number 97) Control Change commands to set the parameter value.
       The transaction ends with a second pair of (99, 98) or (101, 100)
       Control Change commands that specify the null parameter (MSB
       value 0x7F, LSB value 0x7F).

Top      Up      ToC       Page 51 
       Several variants of the canonical transaction sequence are
       possible.  Most commonly, the terminal pair of (99, 98) or (101,
       100) Control Change commands may specify a parameter other than
       the null parameter.  In this case, the command pair terminates
       the first transaction and starts a second transaction.  The
       command pair is considered to be a part of both transactions.
       This variant is legal and recommended in [MIDI].  We refer to
       this variant as a "type 1 variant".

       Less commonly, the MSB (99 or 101) or LSB (98 or 100) command of
       a (99, 98) or (101, 100) Control Change pair may be omitted.

       If the MSB command is omitted, the transaction uses the MSB value
       of the most recent C-active Control Change command for controller
       number 99 or 101 that appears in the session history.  We refer
       to this variant as a "type 2 variant".

       If the LSB command is omitted, the LSB value 0x00 is assumed.  We
       refer to this variant as a "type 3 variant".  The type 2 and type
       3 variants are defined as legal, but are not recommended, in
       [MIDI].

       System real-time commands may appear at any point during a
       transaction (even between octets of individual commands in the
       transaction).  More generally, [MIDI] does not forbid the
       appearance of unrelated MIDI commands during an open transaction.
       As a rule, these commands are considered to be "outside" the
       transaction and do not affect the status of the transaction in
       any way.  Exceptions to this rule are commands whose semantics
       act to terminate transactions:  Reset State commands, and Control
       Change (0xB) for controller number 121 (Reset All Controllers)
       [RP015].

     o Initiated parameter system transaction.  A canonical parameter
       system transaction whose (99, 98) or (101, 100) initial Control
       Change command pair appears in the session history is considered
       to be an initiated parameter system transaction.  This definition
       also holds for type 1 variants.  For type 2 variants (dropped
       MSB), a transaction whose initial LSB Control Change command
       appears in the session history is an initiated transaction.  For
       type 3 variants (dropped LSB), a transaction is considered to be
       initiated if at least one transaction command follows the initial
       MSB (99 or 101) Control Change command in the session history.
       The completion of a transaction does not nullify its "initiated"
       status.

Top      Up      ToC       Page 52 
     o Session history reference counts.  Several recovery journal
       chapters include a reference count field, which codes the total
       number of commands of a type that appear in the session history.
       Examples include the Reset and Tune Request command logs (Chapter
       D, Appendix B.1) and the Active Sense command (Chapter V,
       Appendix B.2).  Upon the detection of a loss event, reference
       count fields let a receiver deduce if any instances of the
       command have been lost, by comparing the journal reference count
       with its own reference count.  Thus, a reference count field
       makes sense, even for command types in which knowing the NUMBER
       of lost commands is irrelevant (as is true with all of the
       example commands mentioned above).

   The chapter definitions in Appendices A.2 to A.9 and B.1 to B.5
   reflect the default recovery journal behavior.  The ch_default,
   ch_never, and ch_anchor parameters modify these definitions, as
   described in Appendix C.2.3.

   The chapter definitions specify if data MUST be present in the
   journal.  Senders MAY also include non-required data in the journal.
   This optional data MUST comply with the normative chapter definition.
   For example, if a chapter definition states that a field codes data
   from the most recent active command in the session history, the
   sender MUST NOT code inactive commands or older commands in the
   field.

   Finally, we note that a channel journal only encodes information
   about MIDI commands appearing on the MIDI channel the journal
   protects.  All references to MIDI commands in Appendices A.2 to A.9
   should be read as "MIDI commands appearing on this channel."

A.2.  Chapter P: MIDI Program Change

   A channel journal MUST contain Chapter P if an active Program Change
   (0xC) command appears in the checkpoint history.  Figure A.2.1 shows
   the format for Chapter P.

                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
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |S|   PROGRAM   |B|   BANK-MSB  |X|  BANK-LSB   |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.2.1 -- Chapter P format

   The chapter has a fixed size of 24 bits.  The PROGRAM field indicates
   the data value of the most recent active Program Change command in
   the session history.  By default, the B, BANK-MSB, X, and BANK-LSB

Top      Up      ToC       Page 53 
   fields MUST be set to 0.  Below, we define exceptions to this default
   condition.

   If an active Control Change (0xB) command for controller number 0
   (Bank Select MSB) appears before the Program Change command in the
   session history, the B bit MUST be set to 1, and the BANK-MSB field
   MUST code the data value of the Control Change command.

   If B is set to 1, the BANK-LSB field MUST code the data value of the
   most recent Control Change command for controller number 32 (Bank
   Select LSB) that preceded the Program Change command coded in the
   PROGRAM field and followed the Control Change command coded in the
   BANK-MSB field.  If no such Control Change command exists, the BANK-
   LSB field MUST be set to 0.

   If B is set to 1, and if a Control Change command for controller
   number 121 (Reset All Controllers) appears in the MIDI stream between
   the Control Change command coded by the BANK-MSB field and the
   Program Change command coded by the PROGRAM field, the X bit MUST be
   set to 1.

   Note that [RP015] specifies that Reset All Controllers does not reset
   the values of controller numbers 0 (Bank Select MSB) and 32 (Bank
   Select LSB).  Thus, the X bit does not effect how receivers will use
   the BANK-LSB and BANK-MSB values when recovering from a lost Program
   Change command.  The X bit serves to aid recovery in MIDI
   applications where controller numbers 0 and 32 are used in a non-
   standard way.

A.3.  Chapter C: MIDI Control Change

   Figure A.3.1 shows the format for Chapter C.

       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|   NUMBER    |A|  VALUE/ALT  |S|   NUMBER    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|  VALUE/ALT  |  ....                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure A.3.1 -- Chapter C format

   The chapter consists of a 1-octet header, followed by a variable
   length list of 2-octet controller logs.  The list MUST contain at
   least one controller log.  The 7-bit LEN field codes the number of
   controller logs in the list, minus one.  We define the semantics of
   the controller log fields in Appendix A.3.2.

Top      Up      ToC       Page 54 
   A channel journal MUST contain Chapter C if the rules defined in this
   appendix require that one or more controller logs appear in the list.

A.3.1.  Log Inclusion Rules

   A controller log encodes information about a particular Control
   Change command in the session history.

   In the default use of the payload format, list logs MUST encode
   information about the most recent active command in the session
   history for a controller number.  Logs encoding earlier commands MUST
   NOT appear in the list.

   Also, as a rule, the list MUST contain a log for the most recent
   active command for a controller number that appears in the checkpoint
   history.  Below, we define exceptions to this rule:

     o  MIDI streams may transmit 14-bit controller values using paired
        Most Significant Byte (MSB, controller numbers 0-31, 99, 101)
        and Least Significant Byte (LSB, controller numbers 32-63, 98,
        100) Control Change commands [MIDI].

        If the most recent active Control Change command in the session
        history for a 14-bit controller pair uses the MSB number,
        Chapter C MAY omit the controller log for the most recent active
        Control Change command for the associated LSB number, as the
        command ordering makes this LSB value irrelevant.  However, this
        exception MUST NOT be applied if the sender is not certain that
        the MIDI source uses 14-bit semantics for the controller number
        pair.  Note that some MIDI sources ignore 14-bit controller
        semantics and use the LSB controller numbers as independent 7-
        bit controllers.

     o  If active Control Change commands for controller numbers 0 (Bank
        Select MSB) or 32 (Bank Select LSB) appear in the checkpoint
        history, and if the command instances are also coded in the
        BANK-MSB and BANK-LSB fields of the Chapter P (Appendix A.2),
        Chapter C MAY omit the controller logs for the commands.

     o  Several controller number pairs are defined to be mutually
        exclusive.  Controller numbers 124 (Omni Off) and 125 (Omni On)
        form a mutually exclusive pair, as do controller numbers 126
        (Mono) and 127 (Poly).

        If active Control Change commands for one or both members of a
        mutually exclusive pair appear in the checkpoint history, a log
        for the controller number of the most recent command for the
        pair in the checkpoint history MUST appear in the controller

Top      Up      ToC       Page 55 
        list.  However, the list MAY omit the controller log for the
        most recent active command for the other number in the pair.

        If active Control Change commands for one or both members of a
        mutually exclusive pair appear in the session history, and if a
        log for the controller number of the most recent command for the
        pair does not appear in the controller list, a log for the most
        recent command for the other number of the pair MUST NOT appear
        in the controller list.

     o  If an active Control Change command for controller number 121
        (Reset All Controllers) appears in the session history, the
        controller list MAY omit logs for Control Change commands that
        precede the Reset All Controllers command in the session
        history, under certain conditions.

        Namely, a log MAY be omitted if the sender is certain that a
        command stream follows the Reset All Controllers semantics
        defined in [RP015], and if the log codes a controller number for
        which [RP015] specifies a reset value.

        For example, [RP015] specifies that controller number 1
        (Modulation Wheel) is reset to the value 0, and thus a
        controller log for Modulation Wheel MAY be omitted from the
        controller log list.  In contrast, [RP015] specifies that
        controller number 7 (Channel Volume) is not reset, and thus a
        controller log for Channel Volume MUST NOT be omitted from the
        controller log list.

     o  Appendix A.3.4 defines exception rules for the MIDI Parameter
        System controller numbers 6, 38, and 96-101.

A.3.2.  Controller Log Format

   Figure A.3.2 shows the controller log structure of Chapter C.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |S|    NUMBER   |A|  VALUE/ALT  |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure A.3.2 -- Chapter C controller log

   The 7-bit NUMBER field identifies the controller number of the coded
   command.  The 7-bit VALUE/ALT field codes recovery information for
   the command.  The A bit sets the format of the VALUE/ALT field.

Top      Up      ToC       Page 56 
   A log encodes recovery information using one of the following tools:
   the value tool, the toggle tool, or the count tool.

   A log uses the value tool if the A bit is set to 0.  The value tool
   codes the 7-bit data value of a command in the VALUE/ALT field.  The
   value tool works best for controllers that code a continuous
   quantity, such as number 1 (Modulation Wheel).

   The A bit is set to 1 to code the toggle or count tool.  These tools
   work best for controllers that code discrete actions.  Figure A.3.3
   shows the controller log for these tools.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |S|    NUMBER   |1|T|    ALT    |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure A.3.3 -- Controller log for ALT tools

   A log uses the toggle tool if the T bit is set to 0.  A log uses the
   count tool if the T bit is set to 1.  Both methods use the 6-bit ALT
   field as an unsigned integer.

   The toggle tool works best for controllers that act as on/off
   switches, such as 64 (Damper Pedal (Sustain)).  These controllers
   code the "off" state with control values 0-63 and the "on" state with
   64-127.

   For the toggle tool, the ALT field codes the total number of toggles
   (off->on and on->off) due to Control Change commands in the session
   history, up to and including a toggle caused by the command coded by
   the log.  The toggle count includes toggles caused by Control Change
   commands for controller number 121 (Reset All Controllers).

   Toggle counting is performed modulo 64.  The toggle count is reset at
   the start of a session, and whenever a Reset State command (Appendix
   A.1) appears in the session history.  When these reset events occur,
   the toggle count for a controller is set to 0 (for controllers whose
   default value is 0-63) or 1 (for controllers whose default value is
   64-127).

   The Damper Pedal (Sustain) controller illustrates the benefits of the
   toggle tool over the value tool for switch controllers.  As often
   used in piano applications, the "on" state of the controller lets
   notes resonate, while the "off" state immediately damps notes to
   silence.  The loss of the "off" command in an "on->off->on" sequence
   results in ringing notes that should have been damped silent.  The

Top      Up      ToC       Page 57 
   toggle tool lets receivers detect this lost "off" command, but the
   value tool does not.

   The count tool is conceptually similar to the toggle tool.  For the
   count tool, the ALT field codes the total number of Control Change
   commands in the session history, up to and including the command
   coded by the log.  Command counting is performed modulo 64.  The
   command count is set to 0 at the start of the session and is reset to
   0 whenever a Reset State command (Appendix A.1) appears in the
   session history.

   Because the count tool ignores the data value, it is a good match for
   controllers whose controller value is ignored, such as number 123
   (All Notes Off).  More generally, the count tool may be used to code
   a (modulo 64) identification number for a command.

A.3.3.  Log List Coding Rules

   In this section, we describe the organization of controller logs in
   the Chapter C log list.

   A log encodes information about a particular Control Change command
   in the session history.  In most cases, a command SHOULD be coded by
   a single tool (and, thus, a single log).  If a number is coded with a
   single tool and this tool is the count tool, recovery Control Change
   commands generated by a receiver SHOULD use the default control value
   for the controller.

   However, a command MAY be coded by several tool types (and, thus,
   several logs, each using a different tool).  This technique may
   improve recovery performance for controllers with complex semantics,
   such as controller number 84 (Portamento Control) or controller
   number 121 (Reset All Controllers) when used with a non-zero data
   octet (with the semantics described in [DLS2]).

   If a command is encoded by multiple tools, the logs MUST be placed in
   the list in the following order: count tool log (if any), followed by
   value tool log (if any), followed by toggle tool log (if any).

   The Chapter C log list MUST obey the oldest-first ordering rule
   (defined in Appendix A.1).  Note that this ordering preserves the
   information necessary for the recovery of 14-bit controller values,
   without precluding the use of MSB and LSB controller pairs as
   independent 7-bit controllers.

Top      Up      ToC       Page 58 
   In the default use of the payload format, all logs that appear in the
   list for a controller number encode information about one Control
   Change command -- namely, the most recent active Control Change
   command in the session history for the number.

   This coding scheme provides good recovery performance for the
   standard uses of Control Change commands defined in [MIDI].  However,
   not all MIDI applications restrict the use of Control Change commands
   to those defined in [MIDI].

   For example, consider the common MIDI encoding of rotary encoders
   ("infinite" rotation knobs).  The mixing console MIDI convention
   defined in [LCP] codes the position of rotary encoders as a series of
   Control Change commands.  Each command encodes a relative change of
   knob position from the last update (expressed as a clockwise or
   counter-clockwise knob turning angle).

   As the knob position is encoded incrementally over a series of
   Control Change commands, the best recovery performance is obtained if
   the log list encodes all Control Change commands for encoder
   controller numbers that appear in the checkpoint history, not only
   the most recent command.

   To support application areas that use Control Change commands in this
   way, Chapter C may be configured to encode information about several
   Control Change commands for a controller number.  We use the term
   "enhanced" to describe this encoding method, which we describe below.

   In Appendix C.2.3, we show how to configure a stream to use enhanced
   Chapter C encoding for specific controller numbers.  In Section 5 in
   the main text, we show how the H bits in the recovery journal header
   (Figure 8) and in the channel journal header (Figure 9) indicate the
   use of enhanced Chapter C encoding.

   Here, we define how to encode a Chapter C log list that uses the
   enhanced encoding method.

   Senders that use the enhanced encoding method for a controller number
   MUST obey the rules below.  These rules let a receiver determine
   which logs in the list correspond to lost commands.  Note that these
   rules override the exceptions listed in Appendix A.3.1.

     o  If N commands for a controller number are encoded in the list,
        the commands MUST be the N most recent commands for the
        controller number in the session history.  For example, for N =
        2, the sender MUST encode the most recent command and the second
        most recent command, not the most recent command and the third
        most recent command.

Top      Up      ToC       Page 59 
     o  If a controller number uses enhanced encoding, the encoding of
        the least-recent command for the controller number in the log
        list MUST include a count tool log.  In addition, if commands
        are encoded for the controller number whose logs have S bits set
        to 0, the encoding of the least-recent command with S = 0 logs
        MUST include a count tool log.

        The count tool is OPTIONAL for the other commands for the
        controller number encoded in the list, as a receiver is able to
        efficiently deduce the count tool value for these commands, for
        both single-packet and multi-packet loss events.

     o  The use of the value and toggle tools MUST be identical for all
        commands for a controller number encoded in the list.  For
        example, a value tool log either MUST appear for all commands
        for the controller number coded in the list, or alternatively,
        value tool logs for the controller number MUST NOT appear in the
        list.  Likewise, a toggle tool log either MUST appear for all
        commands for the controller number coded in the list, or
        alternatively, toggle tool logs for the controller number MUST
        NOT appear in the list.

     o  If a command is encoded by multiple tools, the logs MUST be
        placed in the list in the following order: count tool log (if
        any), followed by value tool log (if any), followed by toggle
        tool log (if any).

   These rules permit a receiver recovering from a packet loss to use
   the count tool log to match the commands encoded in the list with its
   own history of the stream, as we describe below.  Note that the text
   below describes a non-normative algorithm; receivers are free to use
   any algorithm to match its history with the log list.

   In a typical implementation of the enhanced encoding method, a
   receiver computes and stores count, value, and toggle tool data field
   values for the most recent Control Change command it has received for
   a controller number.

   After a loss event, a receiver parses the Chapter C list and
   processes list logs for a controller number that uses enhanced
   encoding as follows.

   The receiver compares the count tool ALT field for the least-recent
   command for the controller number in the list against its stored
   count data for the controller number, to determine if recovery is
   necessary for the command coded in the list.  The value and toggle
   tool logs (if any) that directly follow the count tool log are
   associated with this least-recent command.

Top      Up      ToC       Page 60 
   To check more-recent commands for the controller, the receiver
   detects additional value and/or toggle tool logs for the controller
   number in the list and infers count tool data for the command coded
   by these logs.  This inferred data is used to determine if recovery
   is necessary for the command coded by the value and/or toggle tool
   logs.

   In this way, a receiver is able to execute only lost commands,
   without executing a command twice.  While recovering from a single
   packet loss, a receiver may skip through S = 1 logs in the list, as
   the first S = 0 log for an enhanced controller number is always a
   count tool log.

   Note that the requirements in Appendix C.2.2.2 for protective sender
   and receiver actions during session startup for multicast operation
   are of particular importance for enhanced encoding, as receivers need
   to initialize its count tool data structures with recovery journal
   data in order to match commands correctly after a loss event.

   Finally, we note in passing that in some applications of rotary
   encoders, a good user experience may be possible without the use of
   enhanced encoding.  These applications are distinguished by visual
   feedback of encoding position that is driven by the post-recovery
   rotary encoding stream, and relatively low packet loss.  In these
   domains, recovery performance may be acceptable for rotary encoders
   if the log list encodes only the most recent command, if both count
   and value logs appear for the command.

A.3.4.  The Parameter System

   Readers may wish to review the Appendix A.1 definitions of "parameter
   system", "parameter system transaction", and "initiated parameter
   system transaction" before reading this section.

   Parameter system transactions update a MIDI Registered Parameter
   Number (RPN) or Non-Registered Parameter Number (NRPN) value.  A
   parameter system transaction is a sequence of Control Change commands
   that may use the following controllers numbers:

     o  Data Entry MSB (6)
     o  Data Entry LSB (38)
     o  Data Increment (96)
     o  Data Decrement (97)
     o  Non-Registered Parameter Number (NRPN) LSB (98)
     o  Non-Registered Parameter Number (NRPN) MSB (99)
     o  Registered Parameter Number (RPN) LSB (100)
     o  Registered Parameter Number (RPN) MSB (101)

Top      Up      ToC       Page 61 
   Control Change commands that are a part of a parameter system
   transaction MUST NOT be coded in Chapter C controller logs.  Instead,
   these commands are coded in Chapter M, the MIDI Parameter chapter
   defined in Appendix A.4.

   However, Control Change commands that use the listed controllers as
   general-purpose controllers (i.e., outside of a parameter system
   transaction) MUST NOT be coded in Chapter M.

   Instead, the controllers are coded in Chapter C controller logs.  The
   controller logs follow the coding rules stated in Appendix A.3.2 and
   A.3.3.  The rules for coding paired LSB and MSB controllers, as
   defined in Appendix A.3.1, apply to the pairs (6, 38), (99, 98), and
   (101, 100) when coded in Chapter C.

   If active Control Change commands for controller numbers 6, 38, or
   96-101 appear in the checkpoint history, and these commands are used
   as general-purpose controllers, the most recent general-purpose
   command instance for these controller numbers MUST appear as entries
   in the Chapter C controller list.

   MIDI syntax permits a source to use controllers 6, 38, 96, and 97 as
   parameter-system controllers and general-purpose controllers in the
   same stream.  An RTP MIDI sender MUST deduce the role of each Control
   Change command for these controller numbers by noting the placement
   of the command in the stream and MUST use this information to code
   the command in Chapter C or Chapter M, as appropriate.

   Specifically, active Control Change commands for controllers 6, 38,
   96, and 97 act in a general-purpose way when

     o  no active Control Change commands that set an RPN or NRPN
        parameter number appear in the session history, or

     o  the most recent active Control Change commands in the session
        history that set an RPN or NRPN parameter number code the null
        parameter (MSB value 0x7F, LSB value 0x7F), or

     o  a Control Change command for controller number 121 (Reset All
        Controllers) appears more recently in the session history than
        all active Control Change commands that set an RPN or NRPN
        parameter number (see [RP015] for details).

   Finally, we note that a MIDI source that follows the recommendations
   of [MIDI] exclusively uses numbers 98-101 as parameter system
   controllers.  Alternatively, a MIDI source may exclusively use 98-101
   as general-purpose controllers and lose the ability perform parameter
   system transactions in a stream.

Top      Up      ToC       Page 62 
   In the language of [MIDI], the general-purpose use of controllers
   98-101 constitutes a non-standard controller assignment.  As most
   real-world MIDI sources use the standard controller assignment for
   controller numbers 98-101, an RTP MIDI sender SHOULD assume these
   controllers act as parameter system controllers, unless it knows that
   a MIDI source uses controller numbers 98-101 in a general-purpose
   way.

A.4.  Chapter M: MIDI Parameter System

   Readers may wish to review the Appendix A.1 definitions for
   "C-active", "parameter system", "parameter system transaction", and
   "initiated parameter system transaction" before reading this
   appendix.

   Chapter M protects parameter system transactions for Registered
   Parameter Number (RPN) and Non-Registered Parameter Number (NRPN)
   values.  Figure A.4.1 shows the format for Chapter M.

       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|P|E|U|W|Z|      LENGTH       |Q|  PENDING    |  Log list ... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure A.4.1 -- Top-level Chapter M format

   Chapter M begins with a 2-octet header.  If the P header bit is set
   to 1, a 1-octet field follows the header, coding the 7-bit PENDING
   value and its associated Q bit.

   The 10-bit LENGTH field codes the size of Chapter M and conforms to
   semantics described in Appendix A.1.

   Chapter M ends with a list of zero or more variable-length parameter
   logs.  Appendix A.4.2 defines the bitfield format of a parameter log.
   Appendix A.4.1 defines the inclusion semantics of the log list.

   A channel journal MUST contain Chapter M if the rules defined in
   Appendix A.4.1 require that one or more parameter logs appear in the
   list.

   A channel journal also MUST contain Chapter M if the most recent
   C-active Control Change command involved in a parameter system
   transaction in the checkpoint history is

     o  an RPN MSB (101) or NRPN MSB (99) controller, or

Top      Up      ToC       Page 63 
     o  an RPN LSB (100) or NRPN LSB (98) controller that completes the
        coding of the null parameter (MSB value 0x7F, LSB value 0x7F).

   This rule provides loss protection for partially transmitted
   parameter numbers and for the null parameter numbers.

   If the most recent C-active Control Change command involved in a
   parameter system transaction in the session history is for the RPN
   MSB or NRPN MSB controller, the P header bit MUST be set to 1, and
   the PENDING field (and its associated Q bit) MUST follow the Chapter
   M header.  Otherwise, the P header bit MUST be set to 0, and the
   PENDING field and Q bit MUST NOT appear in Chapter M.

   If PENDING codes an NRPN MSB, the Q bit MUST be set to 1.  If PENDING
   codes an RPN MSB, the Q bit MUST be set to 0.

   The E header bit codes the current transaction state of the MIDI
   stream.  If E = 1, an initiated transaction is in progress.  Below,
   we define the rules for setting the E header bit:

     o  If no C-active parameter system transaction Control Change
        commands appear in the session history, the E bit MUST be set to
        0.

     o  If the P header bit is set to 1, the E bit MUST be set to 0.

     o  If the most recent C-active parameter system transaction Control
        Change command in the session history is for the NRPN LSB or RPN
        LSB controller number, and if this command acts to complete the
        coding of the null parameter (MSB value 0x7F, LSB value 0x7F),
        the E bit MUST be set to 0.

     o  Otherwise, an initiated transaction is in progress, and the E
        bit MUST be set to 1.

   The U, W, and Z header bits code properties that are shared by all
   parameter logs in the list.  If these properties are set, parameter
   logs may be coded with improved efficiency (we explain how in A.4.1).

   By default, the U, W, and Z bits MUST be set to 0.  If all parameter
   logs in the list code RPN parameters, the U bit MAY be set to 1.  If
   all parameter logs in the list code NRPN parameters, the W bit MAY be
   set to 1.  If the parameter numbers of all RPN and NRPN logs in the
   list lie in the range 0-127 (and thus have an MSB value of 0), the Z
   bit MAY be set to 1.

Top      Up      ToC       Page 64 
   Note that C-active semantics appear in the preceding paragraphs
   because [RP015] specifies that pending Parameter System transactions
   are closed by a Control Change command for controller number 121
   (Reset All Controllers).

A.4.1.  Log Inclusion Rules

   Parameter logs code recovery information for a specific RPN or NRPN
   parameter.

   A parameter log MUST appear in the list if an active Control Change
   command that forms a part of an initiated transaction for the
   parameter appears in the checkpoint history.

   An exception to this rule applies if the checkpoint history only
   contains transaction Control Change commands for controller numbers
   98-101 that act to terminate the transaction.  In this case, a log
   for the parameter MAY be omitted from the list.

   A log MAY appear in the list if an active Control Change command that
   forms a part of an initiated transaction for the parameter appears in
   the session history.  Otherwise, a log for the parameter MUST NOT
   appear in the list.

   Multiple logs for the same RPN or NRPN parameter MUST NOT appear in
   the log list.

   The parameter log list MUST obey the oldest-first ordering rule
   (defined in Appendix A.1), with the phrase "parameter transaction"
   replacing the word "command" in the rule definition.

   Parameter logs associated with the RPN or NRPN null parameter (LSB =
   0x7F, MSB = 0x7F) MUST NOT appear in the log list.  Chapter M uses
   the E header bit (Figure A.4.1) and the log list ordering rules to
   code null parameter semantics.

   Note that "active" semantics (rather than "C-active" semantics)
   appear in the preceding paragraphs because [RP015] specifies that
   pending Parameter System transactions are not reset by a Control
   Change command for controller number 121 (Reset All Controllers).
   However, the rule that follows uses C-active semantics, because it
   concerns the protection of the transaction system itself, and [RP015]
   specifies that Reset All Controllers acts to close a transaction in
   progress.

Top      Up      ToC       Page 65 
   In most cases, parameter logs for RPN and NRPN parameters that are
   assigned to the ch_never parameter (Appendix C.2.3) MAY be omitted
   from the list.  An exception applies if

     o  the log codes the most recent initiated transaction in the
        session history, and

     o  a C-active command that forms a part of the transaction appears
        in the checkpoint history, and

     o  the E header bit for the top-level Chapter M header (Figure
        A.4.1) is set to 1.

   In this case, a log for the parameter MUST appear in the list.  This
   log informs receivers recovering from a loss that a transaction is in
   progress, so that the receiver is able to correctly interpret RPN or
   NRPN Control Change commands that follow the loss event.

A.4.2.  Log Coding Rules

   Figure A.4.2 shows the parameter log structure of Chapter M.

       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|  PNUM-LSB   |Q|  PNUM-MSB   |J|K|L|M|N|T|V|R|   Fields ...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure A.4.2 -- Parameter log format

   The log begins with a header, whose default size (as shown in Figure
   A.4.2) is 3 octets.  If the Q header bit is set to 0, the log encodes
   an RPN parameter.  If Q = 1, the log encodes an NRPN parameter.  The
   7-bit PNUM-MSB and PNUM-LSB fields code the parameter number and
   reflect the Control Change command data values for controllers 99 and
   98 (for NRPNs) or 101 and 100 (for RPNs).

   The J, K, L, M, and N header bits form a Table of Contents (TOC) for
   the log and signal the presence of fixed-sized fields that follow the
   header.  A header bit that is set to 1 codes the presence of a field
   in the log.  The ordering of fields in the log follows the ordering
   of the header bits in the TOC.  Appendices A.4.2.1-2 define the
   fields associated with each TOC header bit.

   The T and V header bits code information about the parameter log but
   are not part of the TOC.  A set T or V bit does not signal the
   presence of any parameter log field.

Top      Up      ToC       Page 66 
   If the rules in Appendix A.4.1 state that a log for a given parameter
   MUST appear in Chapter M, the log MUST code sufficient information to
   protect the parameter from the loss of active parameter transaction
   Control Change commands in the checkpoint history.

   This rule does not apply if the parameter coded by the log is
   assigned to the ch_never parameter (Appendix C.2.3).  In this case,
   senders MAY choose to set the J, K, L, M, and N TOC bits to 0, coding
   a parameter log with no fields.

   Note that logs to protect parameters that are assigned to ch_never
   are REQUIRED under certain conditions (see Appendix A.4.1).  The
   purpose of the log is to inform receivers recovering from a loss that
   a transaction is in progress, so that the receiver is able to
   correctly interpret RPN or NRPN Control Change commands that follow
   the loss event.

   Parameter logs provide two tools for parameter protection: the value
   tool and the count tool.  Depending on the semantics of the
   parameter, senders may use either tool, both tools, or neither tool
   to protect a given parameter.

   The value tool codes information a receiver may use to determine the
   current value of an RPN or NRPN parameter.  If a parameter log uses
   the value tool, the V header bit MUST be set to 1, and the semantics
   defined in Appendices A.4.2.1 for setting the J, K, L, and M TOC bits
   MUST be followed.  If a parameter log does not use the value tool,
   the V bit MUST be set to 0, and the J, K, L, and M TOC bits MUST also
   be set to 0.

   The count tool codes the number of transactions for an RPN or NRPN
   parameter.  If a parameter log uses the count tool, the T header bit
   MUST be set to 1, and the semantics defined in Appendices A.4.2.2 for
   setting the N TOC bit MUST be followed.  If a parameter log does not
   use the count tool, the T bit and the N TOC bit MUST be set to 0.

   Note that V and T are set if the sender uses value (V) or count (T)
   tool for the log on an ongoing basis.  Thus, V may be set even if J =
   K = L = M = 0, and T may be set even if N = 0.

   In many cases, all parameters coded in the log list are of one type
   (RPN and NRPN), and all parameter numbers lie in the range 0-127.  As
   described in Appendix A.4.1, senders MAY signal this condition by
   setting the top-level Chapter M header bit Z to 1 (to code the
   restricted range) and by setting the U or W bit to 1 (to code the
   parameter type).

Top      Up      ToC       Page 67 
   If the top-level Chapter M header codes Z = 1 and either U = 1 or
   W = 1, all logs in the parameter log list MUST use a modified header
   format.  This modification deletes bits 8-15 of the bitfield shown in
   Figure A.4.2, to yield a 2-octet header.  The values of the deleted
   PNUM-MSB and Q fields may be inferred from the U, W, and Z bit
   values.

A.4.2.1.  The Value Tool

   The value tool uses several fields to track the value of an RPN or
   NRPN parameter.

   The J TOC bit codes the presence of the octet shown in Figure A.4.3
   in the field list.

                             0
                             0 1 2 3 4 5 6 7
                            +-+-+-+-+-+-+-+-+
                            |X|  ENTRY-MSB  |
                            +-+-+-+-+-+-+-+-+

                      Figure A.4.3 -- ENTRY-MSB field

   The 7-bit ENTRY-MSB field codes the data value of the most recent
   active Control Change command for controller number 6 (Data Entry
   MSB) in the session history that appears in a transaction for the log
   parameter.

   The X bit MUST be set to 1 if the command coded by ENTRY-MSB precedes
   the most recent Control Change command for controller 121 (Reset All
   Controllers) in the session history.  Otherwise, the X bit MUST be
   set to 0.

   A parameter log that uses the value tool MUST include the ENTRY-MSB
   field if an active Control Change command for controller number 6
   appears in the checkpoint history.

   Note that [RP015] specifies that Control Change commands for
   controller 121 (Reset All Controllers) do not reset RPN and NRPN
   values, and thus the X bit would not play a recovery role for MIDI
   systems that comply with [RP015].

   However, certain renderers (such as DLS 2 [DLS2]) specify that
   certain RPN values are reset for some uses of Reset All Controllers.
   The X bit (and other bitfield features of this nature in this
   appendix) plays a role in recovery for renderers of this type.

Top      Up      ToC       Page 68 
   The K TOC bit codes the presence of the octet shown in Figure A.4.4
   in the field list.

                             0
                             0 1 2 3 4 5 6 7
                            +-+-+-+-+-+-+-+-+
                            |X|  ENTRY-LSB  |
                            +-+-+-+-+-+-+-+-+

                      Figure A.4.4 -- ENTRY-LSB field

   The 7-bit ENTRY-LSB field codes the data value of the most recent
   active Control Change command for controller number 38 (Data Entry
   LSB) in the session history that appears in a transaction for the log
   parameter.

   The X bit MUST be set to 1 if the command coded by ENTRY-LSB precedes
   the most recent Control Change command for controller 121 (Reset All
   Controllers) in the session history.  Otherwise, the X bit MUST be
   set to 0.

   As a rule, a parameter log that uses the value tool MUST include the
   ENTRY-LSB field if an active Control Change command for controller
   number 38 appears in the checkpoint history.  However, the ENTRY-LSB
   field MUST NOT appear in a parameter log if the Control Change
   command associated with the ENTRY-LSB precedes a Control Change
   command for controller number 6 (Data Entry MSB) that appears in a
   transaction for the log parameter in the session history.

   The L TOC bit codes the presence of the octets shown in Figure A.4.5
   in the field list.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |G|X|       A-BUTTON            |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure A.4.5 -- A-BUTTON field

   The 14-bit A-BUTTON field codes a count of the number of active
   Control Change commands for controller numbers 96 and 97 (Data
   Increment and Data Decrement) in the session history that appear in a
   transaction for the log parameter.

Top      Up      ToC       Page 69 
   The M TOC bit codes the presence of the octets shown in Figure A.4.6
   in the field list.

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |G|R|       C-BUTTON            |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure A.4.6 -- C-BUTTON field

   The 14-bit C-BUTTON field has semantics identical to A-BUTTON, except
   that Data Increment and Data Decrement Control Change commands that
   precede the most recent Control Change command for controller 121
   (Reset All Controllers) in the session history are not counted.

   For both A-BUTTON and C-BUTTON, Data Increment and Data Decrement
   Control Change commands are not counted if they precede Control
   Changes commands for controller numbers 6 (Data Entry MSB) or 38
   (Data Entry LSB) that appear in a transaction for the log parameter
   in the session history.

   The A-BUTTON and C-BUTTON fields are interpreted as unsigned
   integers, and the G bit associated the field codes the sign of the
   integer (G = 0 for positive or zero, G = 1 for negative).

   To compute and code the count value, initialize the count value to 0,
   add 1 for each qualifying Data Increment command, and subtract 1 for
   each qualifying Data Decrement command.  After each add or subtract,
   limit the count magnitude to 16383.  The G bit codes the sign of the
   count, and the A-BUTTON or C-BUTTON field codes the count magnitude.

   For the A-BUTTON field, if the most recent qualified Data Increment
   or Data Decrement command precedes the most recent Control Change
   command for controller 121 (Reset All Controllers) in the session
   history, the X bit associated with A-BUTTON field MUST be set to 1.
   Otherwise, the X bit MUST be set to 0.

   A parameter log that uses the value tool MUST include the A-BUTTON
   and C-BUTTON fields if an active Control Change command for
   controller numbers 96 or 97 appears in the checkpoint history.
   However, to improve coding efficiency, this rule has several
   exceptions:

     o  If the log includes the A-BUTTON field, and if the X bit of the
        A-BUTTON field is set to 1, the C-BUTTON field (and its
        associated R and G bits) MAY be omitted from the log.

Top      Up      ToC       Page 70 
     o  If the log includes the A-BUTTON field, and if the A-BUTTON and
        C-BUTTON fields (and their associated G bits) code identical
        values, the C-BUTTON field (and its associated R and G bits) MAY
        be omitted from the log.

A.4.2.2.  The Count Tool

   The count tool tracks the number of transactions for an RPN or NRPN
   parameter.  The N TOC bit codes the presence of the octet shown in
   Figure A.4.7 in the field list.

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

                     Figure A.4.7 -- COUNT field

   The 7-bit COUNT codes the number of initiated transactions for the
   log parameter that appear in the session history.  Initiated
   transactions are counted if they contain one or more active Control
   Change commands, including commands for controllers 98-101 that
   initiate the parameter transaction.

   If the most recent counted transaction precedes the most recent
   Control Change command for controller 121 (Reset All Controllers) in
   the session history, the X bit associated with the COUNT field MUST
   be set to 1.  Otherwise, the X bit MUST be set to 0.

   Transaction counting is performed modulo 128.  The transaction count
   is set to 0 at the start of a session and is reset to 0 whenever a
   Reset State command (Appendix A.1) appears in the session history.

   A parameter log that uses the count tool MUST include the COUNT field
   if an active command that increments the transaction count (modulo
   128) appears in the checkpoint history.


Next RFC Part