Summary

  • A lost command can create either a passing omission or a persistent error in an instrument. RTP MIDI recovery targets the latter without claiming a flawless reconstruction of the former.
  • The recovery journal supplies bounded historical information from which receivers generate corrective commands. It does not retransmit every missing packet, and a recovered attack may appropriately remain unplayed.
  • Silence, checkpoint coverage, late arrival and the initial state of new receivers all affect recovery. Shared semantics establish obligations while leaving room for different local rendering algorithms.

Five seconds with nothing more to say

A musician finishes a note and pauses. The packet carrying the NoteOff command disappears. For the next five seconds, there is no new gesture to transmit. Unless another RTP packet arrives, the receiver may not discover the sequence gap until the musician starts again. What was silence at the source can become an unwanted sustained note at the destination.

This is a design example in the November 2006 implementation guide RFC 4696, not a report of a particular concert. It exposes an awkward property of interactive systems. A sender can stop producing new events while an old, incorrectly maintained event continues to cause trouble elsewhere.

The guide discusses guard packets containing empty MIDI lists. They need not invent another musical action. Their arrival can reveal the missing sequence number and bring the journal information needed to correct the receiver. An empty list of new commands does not make the packet useless.

But ending the unwanted sound cannot undo the seconds already heard. The distinction between correcting a machine and recreating a performance was not an incidental limitation. It shaped the recovery system's purpose.

The duration of an error was part of its meaning

MIDI is a symbolic command language, not a recording of an audio waveform. Instructions start and end notes or change settings in a synthesizer or software instrument. The receiver produces sound using those instructions and the state it already holds. Losing a small command can therefore have consequences much longer than the command itself.

The November 2006 payload specification, RFC 4695, classified rendering defects as transient or indefinite. A lost NoteOn can leave a note unheard, but the omission ordinarily does not extend beyond that note's intended duration. A lost NoteOff may leave a note sounding. Losing a Channel Volume command can make every subsequent note on the channel too loud or too soft.

The word “may” matters. Instrument envelopes, pedal states and later commands influence the actual result. A missing release does not inevitably create an endless tone on every instrument. Nevertheless, a protocol cannot rely on a fortunate later event to repair a state that it has left wrong.

Two single-packet losses can thus have different musical consequences. One leaves a finite hole; another contaminates the future. Packet counts alone do not tell a receiver which kind of damage it needs to stop.

A transport framework could not infer the missing music

The July 2003 RTP specification, RFC 3550, supplies sequence numbers, timestamps, payload identification and reception monitoring. It explicitly does not guarantee delivery, timely arrival or arrival in order. These are tools for dealing with a fallible network, not evidence that the network has ceased to be fallible.

A sequence gap also says nothing by itself about an instrument's volume setting. That knowledge belongs to the application. The MIDI payload format therefore carries information with which an application can understand the consequences of the gap, rather than merely notice that one exists.

The June 2011 replacement specification, RFC 6295, retained the recovery journal's central mandate: a performance rendered from a stream sent over unreliable transport must not contain indefinite artifacts. The aim is not to prevent every momentary glitch. It is to prevent an error from remaining in force without a natural end.

The receiver compares its knowledge of the stream with the journal in the packet that ends a loss event. Differences can cause it to execute local repair commands. In this way, an indefinite error becomes a transient one. A locally generated release may stop a tone whose original remote release never arrived.

The journal does not accomplish this by retransmitting every missing packet. It delivers the historical information needed to put the instrument right, which is a different objective from reproducing the transport history byte for byte.

The journal was not a recording of the whole session

A checkpoint defines the beginning of the relevant history. If the arriving packet is I and its checkpoint is C, the checkpoint history covers commands from C through I−1. It excludes the commands in the current packet itself. When C equals I, that history is empty.

The specification's ability to recover losses of an arbitrary number of packets is bounded by this coverage. It does not make an arbitrarily long outage recoverable. The receiver can examine the checkpoint to determine whether the journal reaches back far enough to cover the gap it has seen.

Nor does a journal preserve every historical attack. Chapter N supports ordinary alternating NoteOn and NoteOff patterns for a pitch through a representation useful for recovery. More complicated overlapping note patterns need additional support from Chapter E. A simplified account suitable for a keyboard or drum pad is not automatically an algorithm for every guitar or wind controller.

A Chapter N NoteOn log does not encode the original command's exact execution time. Its Y bit offers a recommendation to play or skip the note. That is a hint about a useful present action, not an instruction to replay every recovered event.

The implementation guide illustrates a receiver that can skip a missing attack yet update its recovery records as if the attack had been accounted for. Its bookkeeping can become coherent without adding a sound that no longer belongs at the current musical moment. Information can be recovered without requiring the audience to hear it performed late.

A release command did not settle every acoustic question

There are finer limits as well. Chapter N does not preserve the release velocity of NoteOff; Chapter E can add support for that information. The journal may also fail to preserve the full relative ordering of a release and a damper-pedal change.

Sometimes the receiver can infer the order from its own history. When it cannot, the specification favors avoiding an incorrectly sustained pedal-held tone, even at the cost of an unpleasant transient. Sending NoteOff is not a universal statement that every instrument will instantly become silent regardless of pedal state.

These are not cosmetic exceptions. They show what is lost when a performance is represented by enough history to repair state rather than by a complete record of every action and its timing. The protocol provides rules for handling insufficient information; it does not pretend that insufficient information has become complete.

The pause had a network cost

Guard packets provide opportunities to detect and repair the last lost command before a silence. In a stream using the recovery journal, an empty MIDI list can accompany a journal with useful history. An empty command list, an empty journal and a stream configured not to journal are three different things.

The guide's sample guard schedules are implementation examples. They are not universal timers that every application must use. The guardtime parameter described in RFC 6295 expresses a maximum separation between consecutive packets in RTP timestamp units; even the document's typical range is expressly not a normative bound.

Congestion control takes precedence over the requested sending frequency. The audio/video profile in RFC 3551 explains the need for reasonable coexistence with other traffic. A music application does not acquire an unlimited claim on shared capacity because its errors are audible. More frequent recovery opportunities are not a straightforward improvement if they worsen the conditions producing loss.

There is also no requirement that every RTP MIDI stream everywhere use a journal. Unreliable transports such as UDP use it by default; reliable transports such as TCP do not. Session descriptions can override defaults within the recovery obligations, but the journalling method is fixed at the beginning of the session. A known-reliable local datagram environment is one example discussed by the specification, not a reason to assume that every local network is reliable.

Saving history created a duty to newcomers

The default closed-loop sending policy uses receiver feedback to reduce the history that must be carried repeatedly. Ordinarily, RTCP reports provide the extended highest sequence number received; another agreed feedback mechanism can serve that purpose. A smaller checkpoint history generally permits a smaller journal.

That economy assumes that receivers perform the required repairs. A report of sequence progress is not a report of a perfect musical experience. It supports a bounded decision about which past information remains necessary.

New receivers expose the limits of that decision. A channel volume set early in the stream may no longer appear in a short recent history. Existing receivers know it. A newcomer can receive subsequent packets while rendering them with the wrong volume. Once the sender becomes aware of the new receiver, it must ensure that the receiver begins without such indefinite artifacts, potentially protecting current controller state until receipt is reported.

In some multicast or other multiparty arrangements, a sender may not initially know who is listening. An unknown receiver can take precautions against stuck notes, but cannot deduce a volume value it has never received. Present connectivity does not certify adequate initialization.

The May 2017 design guide RFC 8088 singled out summarized-state recovery and RTCP-guided pruning as interesting features of RTP MIDI. It associated their usefulness with highly stateful symbolic media. That was a design observation, not a measurement of commercial adoption.

One example receiver was not the only permitted receiver

The NMP implementation discussed in RFC 4696 ignores out-of-order packets because an earlier recovery action may already have compensated for their absence. Executing the old command could duplicate a correction. On-time knowledge and late historical completeness are not interchangeable.

But RFC 4696 is explicitly non-normative. Its example protects a subset of MIDI commands and targets particular historical network characteristics. It uses no playout buffer; the guide itself notes that this does not completely satisfy a cited interoperability provision requiring buffer capability.

The normative rule is narrower than prescribing that implementation. A receiver must not introduce indefinite artifacts when handling an out-of-order packet. A receiver with a playout buffer may defer journal processing until rendering, since an apparently lost packet may arrive late but still in time to use.

Session entry and exit carry obligations too. The first packet is treated as if it ends a loss event, and a receiver leaving a session must not leave an indefinitely wrong rendered state behind. Recovery reaches beyond the receipt of bytes to the condition in which the application continues—or stops.

A registered format was not evidence of a flawless performance

The IANA registration for audio/rtp-midi supplies a common name, parameters and specification references for real-time MIDI streams. It helps implementations identify the format. It does not certify the sound of a particular performance or count the systems that have adopted it.

The 2011 revision corrected figures, syntax and configuration examples while retaining the recovery principle. Its authors' statements about having no known interoperability problems concern the errors being corrected, not all implementations everywhere. Their assessment of particular application domains in 2011 must likewise remain a dated assessment, not a claim about today's market.

The durable contribution was a careful definition of recovery. Some missing actions should not be performed once their moment has passed. Other missing actions must still be compensated for because their absence continues to act. RTP MIDI made that distinction available to machines. It could restore a usable present without claiming to restore the same past.