RFC4695 日本語訳
4695 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT=403808 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lazzaro
Request for Comments: 4695 J. Wawrzynek
Category: Standards Track UC Berkeley
November 2006
Lazzaroがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4695年のJ.Wawrzynekカテゴリ: 標準化過程UCバークレー2006年11月
RTP Payload Format for MIDI
ミディのためのRTP有効搭載量形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.
このメモはMIDI(ミディ)コマンド言語のためにレアル-時間Transportプロトコル(RTP)ペイロード形式について説明します。 形式はMIDI1.0DINケーブルの上に法的に現れるかもしれないすべてのコマンドをコード化します。 形式は対話型アプリケーション(ネットワーク演奏などの)と内容配送アプリケーション(ファイルストリーミングなどの)に適しています。 形式はユニキャスト、マルチキャストUDP、およびTCPの上で使用されるかもしれません、そして、それは優雅な回復のためにパケット損失からツールを定義します。 MIDIレンダリングメソッドを含むストリームの振舞いはセッションセットアップの間、カスタマイズされるかもしれません。 また、形式は、MPEGのMIDI司令官(Downloadable Sounds Level2)のための4Audio Object TypesとStructured Audioをサポートするためにmpeg4-ジェネリック形式のためのモードとして機能します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Bitfield Conventions .......................................6
2. Packet Format ...................................................6
2.1. RTP Header .................................................7
2.2. MIDI Payload ..............................................11
3. MIDI Command Section ...........................................12
3.1. Timestamps ...............................................14
3.2. Command Coding ...........................................16
1. 序論…4 1.1. 用語…5 1.2. Bitfieldコンベンション…6 2. パケット形式…6 2.1. RTPヘッダー…7 2.2. ミディ有効搭載量…11 3. ミディ指揮班…12 3.1. タイムスタンプ…14 3.2. コード化を命令してください…16
Lazzaro & Wawrzynek Standards Track [Page 1] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[1ページ]。
4. The Recovery Journal System ....................................22
5. Recovery Journal Format ........................................24
6. Session Description Protocol ...................................28
6.1. Session Descriptions for Native Streams ...................29
6.2. Session Descriptions for mpeg4-generic Streams ............30
6.3. Parameters ................................................33
7. Extensibility ..................................................34
8. Congestion Control .............................................35
9. Security Considerations ........................................35
10. Acknowledgements ..............................................36
11. IANA Considerations ...........................................37
11.1. rtp-midi Media Type Registration .........................37
11.1.1. Repository Request for "audio/rtp-midi" ...........40
11.2. mpeg4-generic Media Type Registration ....................41
11.2.1. Repository Request for Mode rtp-midi for
mpeg4-generic .....................................44
11.3. asc Media Type Registration ..............................46
A. The Recovery Journal Channel Chapters ..........................48
A.1. Recovery Journal Definitions ..............................48
A.2. Chapter P: MIDI Program Change ............................52
A.3. Chapter C: MIDI Control Change ............................53
A.3.1. Log Inclusion Rules ................................54
A.3.2. Controller Log Format ..............................55
A.3.3. Log List Coding Rules ..............................57
A.3.4. The Parameter System ...............................60
A.4. Chapter M: MIDI Parameter System ..........................62
A.4.1. Log Inclusion Rules ................................64
A.4.2. Log Coding Rules ...................................65
A.4.2.1. The Value Tool .............................67
A.4.2.2. The Count Tool .............................70
A.5. Chapter W: MIDI Pitch Wheel ...............................71
A.6. Chapter N: MIDI NoteOff and NoteOn ........................71
A.6.1. Header Structure ...................................73
A.6.2. Note Structures ....................................74
A.7. Chapter E: MIDI Note Command Extras .......................75
A.7.1. Note Log Format ....................................76
A.7.2. Log Inclusion Rules ................................76
A.8. Chapter T: MIDI Channel Aftertouch ........................77
A.9. Chapter A: MIDI Poly Aftertouch ...........................78
B. The Recovery Journal System Chapters ...........................79
B.1. System Chapter D: Simple System Commands ..................79
B.1.1. Undefined System Commands ..........................80
B.2. System Chapter V: Active Sense Command ....................83
B.3. System Chapter Q: Sequencer State Commands ................83
B.3.1. Non-compliant Sequencers ...........................85
B.4. System Chapter F: MIDI Time Code Tape Position ............86
B.4.1. Partial Frames .....................................88
4. 回復ジャーナルシステム…22 5. 回復ジャーナル形式…24 6. セッション記述プロトコル…28 6.1. ネイティブのストリームのためのセッション記述…29 6.2. mpeg4-ジェネリックStreamsのためのセッション記述…30 6.3. パラメタ…33 7. 伸展性…34 8. 混雑コントロール…35 9. セキュリティ問題…35 10. 承認…36 11. IANA問題…37 11.1. rtp-ミディメディアType Registration…37 11.1.1. 「rtpオーディオ/ミディ」を求める倉庫要求…40 11.2. mpeg4-ジェネリックメディアType Registration…41 11.2.1. mpeg4-ジェネリックのためのMode rtp-ミディのための倉庫Request…44 11.3. ascメディアType Registration…46 A. 回復ジャーナルチャンネル章…48 A.1。 回復ジャーナル定義…48 A.2。 章P: ミディプログラム変化…52 A.3。 章C: ミディコントロール変化…53 A.3.1。 包含規則を登録してください…54 A.3.2。 コントローラログ形式…55 A.3.3。 リストコード化規則を登録してください…57 A.3.4。 パラメタシステム…60 A.4。 章M: ミディパラメタシステム…62 A.4.1。 包含規則を登録してください…64 A.4.2。 コード化規則を登録してください…65 A.4.2.1。 値のツール…67 A.4.2.2。 カウントツール…70 A.5。 章W: ミディ大歯車…71 A.6。 第N章: ミディのNoteOffとNoteOn…71 A.6.1。 ヘッダー構造…73 A.6.2。 構造に注意してください…74 A.7。 章E: ミディ注意コマンドエキストラ…75 A.7.1。 ログ書式に注意してください…76 A.7.2。 包含規則を登録してください…76 A.8。 章T: ミディチャンネル残触覚…77 A.9。 章A: ミディポリー残触覚…78 B. 回復ジャーナルシステム章…79 B.1。 システム、章D: 簡単なシステムは命令します…79 B.1.1。 未定義のシステムは命令します…80 B.2。 システム章のV: 活発な感覚コマンド…83 B.3。 システム、章Q: シーケンサ状態は命令します…83 B.3.1。 不従順なシーケンサ…85 B.4。 システム、章F: ミディ時間コードテープ位置…86 B.4.1。 部分的なフレーム…88
Lazzaro & Wawrzynek Standards Track [Page 2] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[2ページ]。
B.5. System Chapter X: System Exclusive ........................89
B.5.1. Chapter Format .....................................90
B.5.2. Log Inclusion Semantics ............................92
B.5.3. TCOUNT and COUNT Fields ............................95
C. Session Configuration Tools ....................................95
C.1. Configuration Tools: Stream Subsetting ....................97
C.2. Configuration Tools: The Journalling System ..............101
C.2.1. The j_sec Parameter ...............................102
C.2.2. The j_update Parameter ............................103
C.2.2.1. The anchor Sending Policy .................104
C.2.2.2. The closed-loop Sending Policy ............104
C.2.2.3. The open-loop Sending Policy ..............108
C.2.3. Recovery Journal Chapter Inclusion Parameters .....110
C.3. Configuration Tools: Timestamp Semantics .................115
C.3.1. The comex Algorithm ...............................115
C.3.2. The async Algorithm ...............................116
C.3.3. The buffer Algorithm ..............................117
C.4. Configuration Tools: Packet Timing Tools .................118
C.4.1. Packet Duration Tools .............................119
C.4.2. The guardtime Parameter ...........................120
C.5. Configuration Tools: Stream Description ..................121
C.6. Configuration Tools: MIDI Rendering ......................128
C.6.1. The multimode Parameter ...........................129
C.6.2. Renderer Specification ............................129
C.6.3. Renderer Initialization ...........................131
C.6.4. MIDI Channel Mapping ..............................133
C.6.4.1. The smf_info Parameter ....................134
C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters ................................136
C.6.4.3. The chanmask Parameter ....................136
C.6.5. The audio/asc Media Type ..........................137
C.7. Interoperability .........................................139
C.7.1. MIDI Content Streaming Applications ...............139
C.7.2. MIDI Network Musical Performance Applications .....142
D. Parameter Syntax Definitions ..................................150
E. A MIDI Overview for Networking Specialists ....................156
E.1. Commands Types ...........................................159
E.2. Running Status ...........................................159
E.3. Command Timing ...........................................160
E.4. AudioSpecificConfig Templates for MMA Renderers ..........160
References .......................................................165
Normative References .............................................165
Informative References ...........................................166
B.5。 システム、章X: システム排他的…89 B.5.1。 章の形式…90 B.5.2。 包含意味論を登録してください…92 B.5.3。 TCOUNTとカウント分野…95 C.セッション構成ツール…95 C.1。 構成ツール: Subsettingを流してください…97 C.2。 構成ツール: Journallingシステム…101 C.2.1。 j_秒のParameter…102 C.2.2。 j_アップデートParameter…103 C.2.2.1。 アンカーSending Policy…104 C.2.2.2。 閉ループSending Policy…104 C.2.2.3。 転々流通Sending Policy…108 C.2.3。 回復ジャーナル章の包含パラメタ…110 C.3。 構成ツール: タイムスタンプ意味論…115 C.3.1。 comex Algorithm…115 C.3.2。 async Algorithm…116 C.3.3。 バッファAlgorithm…117 C.4。 構成ツール: パケットタイミングツール…118 C.4.1。 パケット持続時間ツール…119 C.4.2。 guardtime Parameter…120 C.5。 構成ツール: 記述を流してください…121 C.6。 構成ツール: ミディレンダリング…128 C.6.1。 マルチモードParameter…129 C.6.2。 レンダラー仕様…129 C.6.3。 レンダラー初期設定…131 C.6.4。 ミディチャンネルマッピング…133 C.6.4.1。 smf_インフォメーションParameter…134 C.6.4.2。 smf_インライン、smf_url、およびsmf_Cid Parameters…136 C.6.4.3。 chanmask Parameter…136 C.6.5。 オーディオ/ascメディアType…137 C.7。 相互運用性…139 C.7.1。 ミディ内容ストリーミング・アプリケーション…139 C.7.2。 ミディネットワーク演奏アプリケーション…142 D.パラメタ構文定義…150 E. ネットワーク専門家のためのミディ概要…156 E.1。 タイプを命令します…159 E.2。 実行している状態…159 E.3。 タイミングを命令してください…160 E.4。 MMAレンダラーのためのAudioSpecificConfigテンプレート…160の参照箇所…165 標準の参照…165 有益な参照…166
Lazzaro & Wawrzynek Standards Track [Page 3] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[3ページ]。
1. Introduction
1. 序論
The Internet Engineering Task Force (IETF) has developed a set of focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] [RFC2326]). These tools can be combined in different ways to support a variety of real-time applications over Internet Protocol (IP) networks.
インターネット・エンジニアリング・タスク・フォース(IETF)はマルチメディアネットワーク[RFC3550][RFC4566][RFC3261][RFC2326)のために1セットの集中しているツールを開発しました。 インターネットプロトコル(IP)ネットワークの上のさまざまなリアルタイムのアプリケーションをサポートする異なった方法でこれらのツールを結合できます。
For example, a telephony application might use the Session Initiation Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would include negotiations to agree on a common audio codec [RFC3264]. Negotiations would use the Session Description Protocol (SDP, [RFC4566]) to describe candidate codecs.
例えば、電話アプリケーションは、電話をセットアップするのに、Session Initiationプロトコル(SIP、[RFC3261])を使用するかもしれません。 呼び出しセットアップは、一般的なオーディオコーデック[RFC3264]に同意するために交渉を含んでいるでしょう。 交渉は、候補コーデックについて説明するのに、Session記述プロトコル(SDP、[RFC4566])を使用するでしょう。
After a call is set up, audio data would flow between the parties using the Real Time Protocol (RTP, [RFC3550]) under any applicable profile (for example, the Audio/Visual Profile (AVP, [RFC3551])). The tools used in this telephony example (SIP, SDP, RTP) might be combined in a different way to support a content streaming application, perhaps in conjunction with other tools, such as the Real Time Streaming Protocol (RTSP, [RFC2326]).
呼び出しがセットアップされた後に、オーディオデータは、パーティーの間をどんな適切なプロフィール(例えば、Audio/視覚のProfile(AVP、[RFC3551]))の下でもレアルTimeプロトコル(RTP、[RFC3550])を使用することで流れるでしょう。 この電話の例(SIP、SDP、RTP)で使用されるツールはアプリケーションを流す内容をサポートする異なった方法で結合されるかもしれません、恐らく他のツールに関連して、レアルTime Streamingプロトコル(RTSP、[RFC2326])などのように。
The MIDI (Musical Instrument Digital Interface) command language [MIDI] is widely used in musical applications that are analogous to the examples described above. On stage and in the recording studio, MIDI is used for the interactive remote control of musical instruments, an application similar in spirit to telephony. On web pages, Standard MIDI Files (SMFs, [MIDI]) rendered using the General MIDI standard [MIDI] provide a low-bandwidth substitute for audio streaming.
MIDI(ミディ)コマンド言語[MIDI]は上で説明された例に類似の音楽のアプリケーションで広く使用されます。 ステージの上と、そして、レコーディングスタジオでは、MIDIは楽器(精神において電話と同様のアプリケーション)の対話的な遠隔操作に使用されます。 ウェブページでは、ジェネラルミディ規格[MIDI]を使用することでレンダリングされたStandard MIDIファイル(SMFs、[MIDI])はオーディオストリーミングの低バンド幅代用品を提供します。
This memo is motivated by a simple premise: if MIDI performances could be sent as RTP streams that are managed by IETF session tools, a hybridization of the MIDI and IETF application domains may occur.
このメモは簡単な前提によって動機づけられています: IETFセッションツールによって管理されるRTPストリームとしてMIDI性能を送ることができるなら、MIDIとIETFアプリケーションドメインの交配は起こるかもしれません。
For example, interoperable MIDI networking may foster network music performance applications, in which a group of musicians, located at different physical locations, interact over a network to perform as they would if they were located in the same room [NMP]. As a second example, the streaming community may begin to use MIDI for low- bitrate audio coding, perhaps in conjunction with normative sound synthesis methods [MPEGSA].
例えば、共同利用できるMIDIネットワークはそれらが同じ部屋[NMP]に位置しているなら伸ばしているようにネットワーク音楽性能アプリケーションを伸ばすかもしれません。そこでは、異なった物理的な位置に位置するミュージシャンのグループがネットワークに上実行する相互作用します。 2番目の例として、ストリーミングの共同体は低いbitrateオーディオ符号化にMIDIを使用し始めるかもしれません、恐らく標準の音の合成法[MPEGSA]に関連して。
To enable MIDI applications to use RTP, this memo defines an RTP payload format and its media type. Sections 2-5 and Appendices A-B define the RTP payload format. Section 6 and Appendices C-D define the media types identifying the payload format, the parameters needed for configuration, and how the parameters are utilized in SDP.
MIDIアプリケーションがRTPを使用するのを可能にするために、このメモはRTPペイロード書式を定義します、そして、メディアはタイプされます。 セクション2-5とAppendices A-BはRTPペイロード書式を定義します。 セクション6とAppendices C-Dはペイロード形式を特定するメディアタイプと、構成に必要であるパラメタと、パラメタがSDPでどう利用されるかを定義します。
Lazzaro & Wawrzynek Standards Track [Page 4] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[4ページ]。
Appendix C also includes interoperability guidelines for the example applications described above: network musical performance using SIP (Appendix C.7.2) and content-streaming using RTSP (Appendix C.7.1).
また、付録Cは以下の上で説明された例のアプリケーションのための相互運用性ガイドラインを含んでいます。 RTSP(付録C.7.1)を使用することでSIP(付録C.7.2)と満足しているストリーミングを使用することで演奏をネットワークでつないでください。
Another potential application area for RTP MIDI is MIDI networking for professional audio equipment and electronic musical instruments. We do not offer interoperability guidelines for this application in this memo. However, RTP MIDI has been designed with stage and studio applications in mind, and we expect that efforts to define a stage and studio framework will rely on RTP MIDI for MIDI transport services.
RTP MIDIのための別の潜在的アプリケーション部はプロのオーディオ設備と電子楽器のためのMIDIネットワークです。 私たちはこのメモにおけるこのアプリケーションのために相互運用性ガイドラインを提供しません。 しかしながら、RTP MIDIはステージとスタジオアプリケーションで念頭に設計されています、そして、私たちはステージとスタジオフレームワークを定義する取り組みがMIDI輸送サービスのためにRTP MIDIを当てにすると予想します。
Some applications may require MIDI media delivery at a certain service quality level (latency, jitter, packet loss, etc). RTP itself does not provide service guarantees. However, applications may use lower-layer network protocols to configure the quality of the transport services that RTP uses. These protocols may act to reserve network resources for RTP flows [RFC2205] or may simply direct RTP traffic onto a dedicated "media network" in a local installation. Note that RTP and the MIDI payload format do provide tools that applications may use to achieve the best possible real-time performance at a given service level.
いくつかのアプリケーションが、あるサービス品質水準(潜在、ジター、パケット損失など)でMIDIメディア配送を必要とするかもしれません。 RTP自身はサービス保証を提供しません。 しかしながら、アプリケーションは、RTPが使用する輸送サービスの品質を構成するのに下層ネットワーク・プロトコルを使用するかもしれません。 これらのプロトコルは、RTP流れ[RFC2205]のためにネットワーク資源を予約するために行動するか、または現地搬入で単にひたむきな「マスメディア網」にRTPトラフィックを向けるかもしれません。 RTPとMIDIペイロード形式がアプリケーションが与えられたサービスレベルにおける可能な限り良いリアルタイムの性能を達成するのに使用するかもしれないツールを提供することに注意してください。
This memo normatively defines the syntax and semantics of the MIDI payload format. However, this memo does not define algorithms for sending and receiving packets. An ancillary document [RFC4696] provides informative guidance on algorithms. Supplemental information may be found in related conference publications [NMP] [GRAME].
このメモは標準にMIDIペイロード形式の構文と意味論を定義します。 しかしながら、このメモは送受信パケットのためにアルゴリズムを定義しません。 付属のドキュメント[RFC4696]はアルゴリズムで有益な指導を提供します。補足的情報は関連会議刊行物[NMP][GRAME]で当たられるかもしれません。
Throughout this memo, the phrase "native stream" refers to a stream that uses the rtp-midi media type. The phrase "mpeg4-generic stream" refers to a stream that uses the mpeg4-generic media type (in mode rtp-midi) to operate in an MPEG 4 environment [RFC3640]. Section 6 describes this distinction in detail.
このメモ中では、「ネイティブのストリーム」という句はrtp-ミディメディアタイプを使用するストリームについて言及します。 「mpeg4-ジェネリックストリーム」という句はMPEG4環境[RFC3640]で作動するのに、mpeg4-ジェネリックメディアタイプ(流行しているrtp-ミディ)を使用するストリームについて言及します。 セクション6は詳細にこの区別について説明します。
1.1. Terminology
1.1. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように解釈されることであるべきです。
Lazzaro & Wawrzynek Standards Track [Page 5] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[5ページ]。
1.2. Bitfield Conventions
1.2. Bitfieldコンベンション
In this document, the packet bitfields that share a common name often have identical semantics. As most of these bitfields appear in Appendices A-B, we define the common bitfield names in Appendix A.1.
本書では、一般名を共有するパケットbitfieldsがしばしば同じ意味論を持っています。 これらのbitfieldsの大部分がAppendices A-Bに現れるように、私たちはAppendix A.1の一般的なbitfield名を定義します。
However, a few of these common names also appear in the main text of this document. For convenience, we list these definitions 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 R旗に噛み付きました。 Rフラグビットは今後の使用のために予約されます。 SendersはRビットを0に設定しなければなりません。 受信機はR噛み付いている値を無視しなければなりません。
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.
o LENGTH分野。 すべての分野がLENGTH(LENと異なるとしての)コードをそれを含む構造の八重奏の数と命名しました、それが住んでいるヘッダーとそれの下のすべての階層レベルを含んでいて。 構造がLENGTH分野を含んでいるなら、受信機は、構文解析の間、構造の内部の形式に関して知識を利用するより構造の先をむしろ進むのにLENGTH分野価値を使用しなければなりません。
2. Packet Format
2. パケット・フォーマット
In this section, we introduce the format of RTP MIDI packets. The description includes some background information on RTP, for the benefit of MIDI implementors new to IETF tools. Implementors should consult [RFC3550] for an authoritative description of RTP.
このセクションでは、私たちはRTP MIDIパケットの形式を導入します。 記述はIETFツールに新しいMIDI作成者の利益のためのRTPに関する何らかの基礎的な情報を含んでいます。 作成者はRTPの正式の記述のために[RFC3550]に相談するべきです。
This memo assumes that the reader is familiar with MIDI syntax and semantics. Appendix E provides a MIDI overview, at a level of detail sufficient to understand most of this memo. Implementors should consult [MIDI] for an authoritative description of MIDI.
このメモは、読者がMIDI構文と意味論に詳しいと仮定します。 付録Eはこのメモの大部分を理解できるくらいの詳細のレベルでMIDI概要を提供します。 作成者はMIDIの正式の記述のために[MIDI]に相談するべきです。
The MIDI payload format maps a MIDI command stream (16 voice channels + systems) onto an RTP stream. An RTP media stream is a sequence of logical packets that share a common format. Each packet consists of two parts: the RTP header and the MIDI payload. Figure 1 shows this format (vertical space delineates the header and payload).
MIDIペイロード形式はMIDIコマンドストリーム(16台の音声チャンネル+システム)をRTPストリームに写像します。 RTPメディアストリームは一般的な形式を共有する論理的なパケットの系列です。 各パケットは2つの部品から成ります: RTPヘッダーとMIDIペイロード。 図1はこの書式を示しています(垂直なスペースはヘッダーとペイロードを図で表わします)。
We describe RTP packets as "logical" packets to highlight the fact that RTP itself is not a network-layer protocol. Instead, RTP packets are mapped onto network protocols (such as unicast UDP, multicast UDP, or TCP) by an application [ALF]. The interleaved mode of the Real Time Streaming Protocol (RTSP, [RFC2326]) is an example of an RTP mapping to TCP transport, as is [RFC4571].
私たちは、RTP自身がネットワーク層プロトコルでないという事実を目立たせるように「論理的な」パケットとしてRTPパケットを記述します。 代わりに、アプリケーション[ALF]でRTPパケットはネットワーク・プロトコル(ユニキャストUDP、マルチキャストUDP、またはTCPなどの)に写像されます。 レアルTime Streamingプロトコル(RTSP、[RFC2326])のはさみ込まれたモードは輸送をTCPに写像するRTPに関する例です、そのままです[RFC4571]。
Lazzaro & Wawrzynek Standards Track [Page 6] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[6ページ]。
2.1. RTP Header
2.1. RTPヘッダー
[RFC3550] provides a complete description of the RTP header fields. In this section, we clarify the role of a few RTP header fields for MIDI applications. All fields are coded in network byte order (big- endian).
[RFC3550]はRTPヘッダーフィールドの完全な記述を提供します。 このセクションでは、私たちはMIDIアプリケーションのためのいくつかのRTPヘッダーフィールドの役割をはっきりさせます。 すべての分野がネットワークバイトオーダー(大きいエンディアン)でコード化されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V|P|X| CC|M| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI command section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Journal section ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDIはセクションを命令します… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ジャーナル部… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 -- Packet format
図1--パケット・フォーマット
The behavior of the 1-bit M field depends on the media type of the stream. For native streams, the M bit MUST be set to 1 if the MIDI command section has a non-zero LEN field, and MUST be set to 0 otherwise. For mpeg4-generic streams, the M bit MUST be set to 1 for all packets (to conform to [RFC3640]).
Mがさばく1ビットの動きはストリームのメディアタイプに頼っています。 MIDI指揮班に非ゼロLEN分野があるなら、1に設定しなければなりません。ネイティブのストリームにおいて、別の方法で、Mビットを0に設定しなければなりません。 mpeg4-ジェネリックストリームにおいて、すべてのパケットのためにMビットを1に設定しなければなりません([RFC3640]に従う)。
In an RTP MIDI stream, the 16-bit sequence number field is initialized to a randomly chosen value and is incremented by one (modulo 2^16) for each packet sent in the stream. A related quantity, the 32-bit extended packet sequence number, may be computed by tracking rollovers of the 16-bit sequence number. Note that different receivers of the same stream may compute different extended packet sequence numbers, depending on when the receiver joined the session.
RTP MIDIストリームでは、16ビットの一連番号分野は、手当たりしだいに選ばれた値に初期化されて、ストリームで送られた各パケットあたり1つ(法2^16)増加されます。 関連する量(32ビットの拡張パケット一連番号)は16ビットの一連番号の追跡ロールオーバーによって計算されるかもしれません。 同じストリームの異なった受信機が異なった拡張パケット一連番号を計算するかもしれないことに注意してください、受信機がセッションに参加した時によって。
The 32-bit timestamp field sets the base timestamp value for the packet. The payload codes MIDI command timing relative to this value. The timestamp units are set by the clock rate parameter. For example, if the clock rate has a value of 44100 Hz, two packets whose base timestamp values differ by 2 seconds have RTP timestamp fields that differ by 88200.
32ビットのタイムスタンプ分野はベースタイムスタンプ価値をパケットに設定します。 ペイロードはこの値に比例してMIDIコマンドタイミングをコード化します。 タイムスタンプユニットはクロックレートパラメタによって設定されます。 例えば、クロックレートに44100Hzの値があるなら、ベースタイムスタンプ値が2秒までに異なる2つのパケットが88200異なるRTPタイムスタンプ分野を持っています。
Lazzaro & Wawrzynek Standards Track [Page 7] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[7ページ]。
Note that the clock rate parameter is not encoded within each RTP MIDI packet. A receiver of an RTP MIDI stream becomes aware of the clock rate as part of the session setup process. For example, if a session management tool uses the Session Description Protocol (SDP, [RFC4566]) to describe a media session, the clock rate parameter is set using the rtpmap attribute. We show examples of session setup in Section 6.
クロックレートパラメタがそれぞれのRTP MIDIパケットの中でコード化されないことに注意してください。 RTP MIDIストリームの受信機はセッションセットアッププロセスの一部としてクロックレートを意識するようになります。 例えば、セッション管理ツールがメディアセッションについて説明するのに、Session記述プロトコル(SDP、[RFC4566])を使用するなら、クロックレートパラメタはrtpmap属性を使用するように設定されます。 私たちはセクション6でのセッションセットアップに関する例を示しています。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be an audio sample rate of 32 KHz or higher. This recommendation is due to the sensitivity of human musical perception to small timing errors in musical note sequences, and due to the timbral changes that occur when two near-simultaneous MIDI NoteOns are rendered with a different timing than that desired by the content author due to clock rate quantization. RTP MIDI streams that are not destined for audio rendering (such as MIDI streams that control stage lighting) MAY use a lower clock rate but SHOULD use a clock rate high enough to avoid timing artifacts in the application.
ストリームがオーディオ、時計に翻訳されるように運命づけたRTP MIDIに関しては、32のオーディオの見本郵送料率がKHzか、より高かったなら、SHOULDを評定してください。 この推薦は音符系列における小さいタイミング誤りへの人間の音楽の知覚の感度のためと、2近く同時のMIDI NoteOnsが異なったタイミングでレンダリングされるとき起こるtimbral変化のためクロックレート量子化のため満足している作者によって望まれていたそれよりあります。 オーディオレンダリング(舞台照明を制御するMIDIストリームなどの)のために運命づけられていないRTP MIDIストリームは下側のクロックレートを使用するかもしれませんが、アプリケーションで人工物を調節するのを高く避けることができるくらいSHOULDはクロックレートを使用します。
For RTP MIDI streams destined to be rendered into audio, the clock rate SHOULD be chosen from rates in common use in professional audio applications or in consumer audio distribution. At the time of this writing, these rates include 32 KHz, 44.1 KHz, 48 KHz, 64 KHz, 88.2 KHz, 96 KHz, 176.4 KHz, and 192 KHz. If the RTP MIDI session is a part of a synchronized media session that includes another (non-MIDI) RTP audio stream with a clock rate of 32 KHz or higher, the RTP MIDI stream SHOULD use a clock rate that matches the clock rate of the other audio stream. However, if the RTP MIDI stream is destined to be rendered into audio, the RTP MIDI stream SHOULD NOT use a clock rate lower than 32 KHz, even if this second stream has a clock rate less than 32 KHz.
ストリームがオーディオ、クロックレートSHOULDに翻訳されるように運命づけたRTP MIDIに、プロのオーディオアプリケーションか消費者のオーディオの分配において共用のレートから選ばれてください。 この書くこと時点で、これらのレートは32KHz、44.1KHz、48KHz、64KHz、88.2KHz、96KHz、176.4KHz、および192KHzを含んでいます。 RTP MIDIセッションが連動しているメディアセッションの一部であるなら、それが32KHzのクロックレートで別の(非MIDI)RTPオーディオストリームを含んでいるか、または、より高く、RTP MIDIストリームSHOULDはもう片方のオーディオストリームのクロックレートに合っているクロックレートを使用します。 しかしながら、RTP MIDIストリームがオーディオに翻訳されるように運命づけられているなら、RTP MIDIストリームSHOULD NOTは32より低クロックレートにKHzを使用します、時計がこの2番目のストリームで32未満KHzを評定しても。
Timestamps of consecutive packets do not necessarily increment at a fixed rate, because RTP MIDI packets are not necessarily sent at a fixed rate. The degree of packet transmission regularity reflects the underlying application dynamics. Interactive applications may vary the packet sending rate to track the gestural rate of a human performer, whereas content-streaming applications may send packets at a fixed rate.
連続したパケットに関するタイムスタンプは定率で必ずどんな増分もしません、必ず定率でRTP MIDIパケットを送るというわけではないので。 パケット伝送の規則性の度合いは基本的なアプリケーション力学を反映します。 対話型アプリケーションは人間のパフォーマーのgesturalレートを追跡するためにパケット送付レートを変えるかもしれませんが、内容のストリーミングのアプリケーションは定率でパケットを送るかもしれません。
Therefore, the timestamps for two sequential RTP packets may be identical, or the second packet may have a timestamp arbitrarily larger than the first packet (modulo 2^32). Section 3 places additional restrictions on the RTP timestamps for two sequential RTP packets, as does the guardtime parameter (Appendix C.4.2).
したがって、2つの連続したRTPパケットのためのタイムスタンプが同じであるかもしれませんか、または2番目のパケットでタイムスタンプは最初のパケット(法2^32)より任意に大きくなるかもしれません。 セクション3は2つの連続したRTPパケットのためのRTPタイムスタンプに関して追加制限を課します、guardtimeパラメタ(付録C.4.2)のように。
We use the term "media time" to denote the temporal duration of the media coded by an RTP packet. The media time coded by a packet is
私たちは、RTPパケットによってコード化されたメディアの時の持続時間を指示するのに「メディア時間」用語を使用します。 パケットによってコード化されたメディア時間はそうです。
Lazzaro & Wawrzynek Standards Track [Page 8] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[8ページ]。
computed by subtracting the last command timestamp in the MIDI command section from the RTP timestamp (modulo 2^32). If the MIDI list of the MIDI command section of a packet is empty, the media time coded by the packet is 0 ms. Appendix C.4.1 discusses media time issues in detail.
RTPタイムスタンプ(法2^32)からMIDI指揮班における最後のコマンドタイムスタンプを引き算することによって、計算されます。 パケットのMIDI指揮班のMIDIリストが空であるなら、パケットによってコード化されたメディア時間は0原稿です。Appendix C.4.1は詳細にメディア時間問題について議論します。
We now define RTP session semantics, in the context of sessions
specified using the session description protocol [RFC4566]. A
session description media line ("m=") specifies an RTP session. An
RTP session has an independent space of 2^32 synchronization sources.
Synchronization source identifiers are coded in the SSRC header field
of RTP session packets. The payload types that may appear in the PT
header field of RTP session packets are listed at the end of the
media line.
私たちは現在、セッション記述プロトコル[RFC4566]を使用することで指定されたセッションの文脈でRTPセッション意味論を定義します。 セッション記述メディア系列(「m=」)はRTPセッションを指定します。 RTPセッションには、2^32の同期ソースの独立しているスペースがあります。 同期ソース識別子はRTPセッションパケットのSSRCヘッダーフィールドでコード化されます。 ヘッダーがさばくRTPセッションパケットの太平洋標準時に現れるかもしれないペイロードタイプはメディア行の終わりに記載されています。
Several RTP MIDI streams may appear in an RTP session. Each stream is distinguished by a unique SSRC value and has a unique sequence number and RTP timestamp space. Multiple streams in the RTP session may be sent by a single party. Multiple parties may send streams in the RTP session. An RTP MIDI stream encodes data for a single MIDI command name space (16 voice channels + Systems).
いくつかのRTP MIDI小川がRTPセッションのときに現れるかもしれません。 各ストリームは、ユニークなSSRC値によって区別されて、ユニーク配列番号とRTPタイムスタンプスペースを持っています。 RTPセッションにおける複数の小川が独身のパーティーによって送られるかもしれません。 複数のパーティーがRTPセッションのときにストリームを送るかもしれません。 RTP MIDIストリームはただ一つのMIDIコマンド名スペース(16台の音声チャンネル+システム)にデータを暗号化します。
Streams in an RTP session may use different payload types, or they may use the same payload type. However, each party may send, at most, one RTP MIDI stream for each payload type mapped to an RTP MIDI payload format in an RTP session. Recall that dynamic binding of payload type numbers in [RFC4566] lets a party map many payload type numbers to the RTP MIDI payload format; thus a party may send many RTP MIDI streams in a single RTP session. Pairs of streams (unicast or multicast) that communicate between two parties in an RTP session and that share a payload type have the same association as a MIDI cable pair that cross-connects two devices in a MIDI 1.0 DIN network.
RTPセッションにおけるストリームが異なったペイロードタイプを使用するかもしれませんか、または彼らは同じペイロードタイプを使用するかもしれません。 しかしながら、各当事者は発信するかもしれません、高々、RTPセッションのときにRTP MIDIペイロード形式に写像されたそれぞれのペイロードタイプあたり1つのRTP MIDIストリーム。 パーティーが[RFC4566]でのペイロード形式数のダイナミックな結合で多くのペイロード形式数をRTP MIDIペイロード形式に写像できると思い出してください。 したがって、パーティーはただ一つのRTPセッションのときに多くのRTP MIDIストリームを送るかもしれません。 RTPセッションのときに2回のパーティーの間で交信して、ペイロードタイプを共有するストリーム(ユニキャストかマルチキャスト)のペアで、MIDIと同じ協会はMIDI1.0DINネットワークでどんなその十字接続にも2台のデバイスに電報を打ちません。
The RTP session architecture described above is efficient in its use of network ports, as one RTP session (using a port pair per party) supports the transport of many MIDI name spaces (16 MIDI channels + systems). We define tools for grouping and labelling MIDI name spaces across streams and sessions in Appendix C.5 of this memo.
上で説明されたRTPセッション構造はネットワークポートを使用で効率的です、1つのRTPセッション(1パーティーあたり1ポート組を使用する)が多くのMIDI名前空間(16台のMIDIチャンネル+システム)の輸送を支持するとき。 私たちはこのメモのAppendix C.5を流れとセッションの向こう側にMIDI名前空間を分類して、ラベルするためのツールを定義します。
The RTP header timestamps for each stream in an RTP session have separately and randomly chosen initialization values. Receivers use the timing fields encoded in the RTP control protocol (RTCP, [RFC3550]) sender reports to synchronize the streams sent by a party. The SSRC values for each stream in an RTP session are also separately and randomly chosen, as described in [RFC3550]. Receivers use the CNAME field encoded in RTCP sender reports to verify that streams were sent by the same party, and to detect SSRC collisions, as described in [RFC3550].
RTPセッションにおける各流れのためのRTPヘッダータイムスタンプは別々に、手当たりしだいに初期化値を選びました。 受信機はパーティーによって送られた流れを同時にさせるためにRTP制御プロトコル(RTCP、[RFC3550])送付者レポートでコード化されたタイミング分野を使用します。 RTPセッションにおける各流れのためのSSRC値は[RFC3550]で説明されるように別々にも、手当たりしだいに選ばれています。 受信機は小川が同じパーティーによって送られたことを確かめて、SSRC衝突を検出するためにRTCP送付者レポートでコード化されたCNAME分野を使用します、[RFC3550]で説明されるように。
Lazzaro & Wawrzynek Standards Track [Page 9] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[9ページ]。
In some applications, a receiver renders MIDI commands into audio (or into control actions, such as the rewind of a tape deck or the dimming of stage lights). In other applications, a receiver presents a MIDI stream to software programs via an Application Programmer Interface (API). Appendix C.6 defines session configuration tools to specify what receivers should do with a MIDI command stream.
または、使用目的によっては、受信機がMIDIコマンドをオーディオに翻訳する、(動作を制御してください、あれほど、舞台照明をテープデッキか薄暗くすることの巻き戻し、) 他のアプリケーションでは、受信機はApplication Programmer Interface(API)を通してMIDIの流れをソフトウェアプログラムに示します。 付録C.6はどんな受信機がMIDIコマンドの流れを処理するはずであるかを指定するセッション構成ツールを定義します。
If a multimedia session uses different RTP MIDI streams to send different classes of media, the streams MUST be sent over different RTP sessions. For example, if a multimedia session uses one MIDI stream for audio and a second MIDI stream to control a lighting system, the audio and lighting streams MUST be sent over different RTP sessions, each with its own media line.
マルチメディアセッションが異なったクラスのメディアを送るのに異なったRTP MIDIの流れを使用するなら、異なったRTPセッションの間、小川を送らなければなりません。 例えば、オーディオと2番目のMIDIの流れが照明装置を制御するのにマルチメディアセッションが1つのMIDIの流れを使用するなら、異なったRTPセッションの間、オーディオと照明小川を送らなければなりません、それぞれそれ自身のメディア線で。
Session description tools defined in Appendix C.5 let a sending party split a single MIDI name space (16 voice channels + systems) over several RTP MIDI streams. Split transport of a MIDI command stream is a delicate task, because correct command stream reconstruction by a receiver depends on exact timing synchronization across the streams.
送付パーティーはいくつかのRTP MIDIの流れでAppendix C.5で定義されたセッション記述ツールでただ一つのMIDI名前スペースを分けることができます(16台の音声チャンネル+システム)。MIDIコマンドの流れの分裂輸送は扱いにくい仕事です、受信機による正しいコマンド流れの再建が小川の向こう側に正確なタイミング同期によるので。
To support split name spaces, we define the following requirements:
分裂名前空間を支持するために、私たちは以下の要件を定義します:
o A party MUST NOT send several RTP MIDI streams that share a MIDI
name space in the same RTP session. Instead, each stream MUST
be sent from a different RTP session.
o パーティーは同じRTPセッションのときにMIDI名前スペースを共有するいくつかのRTP MIDIの流れを送ってはいけません。 代わりに、異なったRTPセッションから各小川を送らなければなりません。
o If several RTP MIDI streams sent by a party share a MIDI name
space, all streams MUST use the same SSRC value and MUST use the
same randomly chosen RTP timestamp initialization value.
o パーティーによって送られたいくつかのRTP MIDI小川がMIDI名前スペースを共有するなら、すべての流れが、同じSSRC値を使用しなければならなくて、同じ手当たりしだいに選ばれたRTPタイムスタンプ初期化価値を使用しなければなりません。
These rules let a receiver identify streams that share a MIDI name space (by matching SSRC values) and also let a receiver accurately reconstruct the source MIDI command stream (by using RTP timestamps to interleave commands from the two streams). Care MUST be taken by senders to ensure that SSRC changes due to collisions are reflected in both streams. Receivers MUST regularly examine the RTCP CNAME fields associated with the linked streams, to ensure that the assumed link is legitimate and not the result of an SSRC collision by another sender.
これらの規則で、受信機にMIDI名前スペース(SSRC値を合わせるのによる)を共有する流れを特定させて、また、受信機は正確に、ソースMIDIコマンドの流れ(2つの流れからコマンドをはさみ込むのにRTPタイムスタンプを使用するのによる)を再建します。 送付者は、衝突によるSSRC変化が両方の流れに反映されるのを保証するために注意しなければなりません。受信機は定期的に別の送付者によるSSRC衝突の結果ではなく、想定されたリンクが確実に正統になるようにするために繋がっている流れに関連づけられたRTCP CNAME野原を調べなければなりません。
Except for the special cases described above, a party may send many RTP MIDI streams in the same session. However, it is sometimes advantageous for two RTP MIDI streams to be sent over different RTP sessions. For example, two streams may need different values for RTP session-level attributes (such as the sendonly and recvonly attributes). As a second example, two RTP sessions may be needed to send two unicast streams in a multimedia session that originate on
上で説明された特別なケースを除いて、パーティーは同じセッションにおける多くのRTP MIDIの流れを送るかもしれません。 しかしながら、異なったRTPセッションの間、2つのRTP MIDIの流れを送るのは時々有利です。 例えば、2つの流れがRTPセッションレベル属性(sendonlyであってrecvonlyな属性などの)に異価を必要とするかもしれません。 2番目の例、2つのRTPセッションが必要であるときに、2ユニキャストを送るのはそれが由来するマルチメディアセッションのときに流れます。
Lazzaro & Wawrzynek Standards Track [Page 10] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[10ページ]。
different computers (with different IP numbers). Two RTP sessions are needed in this case because transport addresses are specified on the RTP-session or multimedia-session level, not on a payload type level.
異なったコンピュータ(異なったIP番号がある)。 輸送アドレスがペイロードタイプレベルで指定されるのではなく、RTP-セッションかマルチメディアセッションレベルで指定されるので、2つのRTPセッションがこの場合必要です。
On a final note, in some uses of MIDI, parties send bidirectional traffic to conduct transactions (such as file exchange). These commands were designed to work over MIDI 1.0 DIN cable networks may be configured in a multicast topology, which use pure "party-line" signalling. Thus, if a multimedia session ensures a multicast connection between all parties, bidirectional MIDI commands will work without additional support from the RTP MIDI payload format.
最後通達に、MIDIのいくつかの用途で、パーティーは、取引(ファイル交換などの)を行うために双方向の交通を送ります。 これらのコマンドは、MIDI1.0の上で働くように設計されました。DINケーブルネットワークはマルチキャストトポロジーで構成されるかもしれなくて、どの使用が純粋な「共同回線」合図であるか。 したがって、マルチメディアセッションがすべてのパーティーの間のマルチキャスト接続を確実にすると、双方向のMIDIコマンドはRTP MIDIペイロード形式から追加的支援なしで働くでしょう。
2.2. MIDI Payload
2.2. ミディ有効搭載量
The payload (Figure 1) MUST begin with the MIDI command section. The MIDI command section codes a (possibly empty) list of timestamped MIDI commands, and provides the essential service of the payload format.
ペイロード(図1)はMIDI指揮班で始まらなければなりません。 MIDI指揮班は、timestamped MIDIコマンドの(ことによると空)のリストをコード化して、ペイロード形式の重要負荷を提供します。
The payload MAY also contain a journal section. The journal section provides resiliency by coding the recent history of the stream. A flag in the MIDI command section codes the presence of a journal section in the payload.
また、ペイロードはジャーナル部を含むかもしれません。 ジャーナル部は、流れの履歴をコード化することによって、弾性を提供します。 MIDI指揮班の旗はペイロードでのジャーナル部の存在をコード化します。
Section 3 defines the MIDI command section. Sections 4-5 and Appendices A-B define the recovery journal, the default format for the journal section. Here, we describe how these payload sections operate in a stream in an RTP session.
セクション3はMIDI指揮班を定義します。 セクション4-5とAppendices A-Bは回復ジャーナル、省略時書式をジャーナル部と定義します。 ここで、私たちはこれらのペイロード部分がRTPセッションのときにどう絶え間なく作動するかを説明します。
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. A stream may be set to use the recovery journal, to use an alternative journal format (none are defined in this memo), or not to use a journal.
流れのためのjournalling方法をセッションの始めに設定して、その後、変えてはいけません。 回復ジャーナルを使用しない、代替のジャーナル形式(なにもこのメモで定義されない)を使用しない、または流れがジャーナルを使用しないように設定されるかもしれません。
The default journalling method of a stream is inferred from its transport type. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal. Appendix C.2.1 defines session configuration tools for overriding these defaults. For all types of transport, a sender MUST transmit an RTP packet stream with consecutive sequence numbers (modulo 2^16).
流れのデフォルトjournalling方法は輸送タイプから推論されます。 頼り無い輸送(UDPなどの)を使用する流れが回復ジャーナルを使用するのをデフォルトとします。 信頼できる輸送(TCPなどの)を使用する流れがジャーナルを使用しないのをデフォルトとします。 付録C.2.1はこれらのデフォルトをくつがえすためのセッション構成ツールを定義します。 すべてのタイプの輸送のために、連続した一連番号(法2^16)で送付者はRTPパケットの流れを伝えなければなりません。
If a stream uses the recovery journal, every payload in the stream MUST include a journal section. If a stream does not use journalling, a journal section MUST NOT appear in a stream payload. If a stream uses an alternative journal format, the specification for the journal format defines an inclusion policy.
流れが回復ジャーナルを使用するなら、流れにおけるあらゆるペイロードがジャーナル部を含まなければなりません。 流れがjournallingを使用しないなら、ジャーナル部は流れのペイロードに現れてはいけません。 流れが代替のジャーナル形式を使用するなら、ジャーナル形式のための仕様は包含方針を定義します。
Lazzaro & Wawrzynek Standards Track [Page 11] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[11ページ]。
If a stream is sent over UDP transport, the Maximum Transmission Unit (MTU) of the underlying network limits the practical size of the payload section (for example, an Ethernet MTU is 1500 octets), for applications where predictable and minimal packet transmission latency is critical. A sender SHOULD NOT create RTP MIDI UDP packets whose size exceeds the MTU of the underlying network. Instead, the sender SHOULD take steps to keep the maximum packet size under the MTU limit.
UDP輸送の上に小川を送るなら、基本的なネットワークのMaximum Transmission Unit(MTU)はペイロード部分の実用的なサイズを制限します(例えば、イーサネットMTUは1500の八重奏です)、予測できて最小量のパケット伝送潜在が批判的であるアプリケーションのために。 送付者SHOULD NOTはサイズが基本的なネットワークのMTUを超えているRTP MIDI UDPパケットを作成します。 代わりに、送付者SHOULDは、MTU限界で最大のパケットサイズを保つために手を打ちます。
These steps may take many forms. The default closed-loop recovery journal sending policy (defined in Appendix C.2.2.2) uses RTP control protocol (RTCP, [RFC3550]) feedback to manage the RTP MIDI packet size. In addition, Section 3.2 and Appendix B.5.2 provide specific tools for managing the size of packets that code MIDI System Exclusive (0xF0) commands. Appendix C.5 defines session configuration tools that may be used to split a dense MIDI name space into several UDP streams (each sent in a different RTP session, per Section 2.1) so that the payload fits comfortably into an MTU. Another option is to use TCP. Section 4.3 of [RFC4696] provides non-normative advice for packet size management.
これらのステップは多くの形を取るかもしれません。RTPが制御するデフォルト閉ループ回復ジャーナル送付方針(Appendix C.2.2.2では、定義される)用途は、RTP MIDIパケットサイズを管理するために(RTCP、[RFC3550])フィードバックを議定書の中で述べます。 さらに、セクション3.2とAppendix B.5.2はコードMIDI System Exclusive(0xF0)が命令するパケットのサイズを管理するための特定のツールを提供します。 付録C.5が濃いMIDI名前スペースをいくつかのUDPの流れに分けるのに使用されるかもしれないセッション構成ツールを定義するので(それぞれが異なったRTPセッションのときに発信しました、セクション2.1単位で)、ペイロードはゆったりMTUに収まります。 別のオプションはTCPを使用することです。 [RFC4696]のセクション4.3は非標準のアドバイスをパケットサイズ管理に提供します。
3. MIDI Command Section
3. ミディ指揮班
Figure 2 shows the format of the MIDI command section.
図2はMIDI指揮班の書式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|J|Z|P|LEN... | MIDI list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|J|Z|P|レン… | MIDIは記載します… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 -- MIDI command section
図2--MIDI指揮班
The MIDI command section begins with a variable-length header.
MIDI指揮班は可変長のヘッダーと共に始まります。
The header field LEN codes the number of octets in the MIDI list that follow the header. If the header flag B is 0, the header is one octet long, and LEN is a 4-bit field, supporting a maximum MIDI list length of 15 octets.
ヘッダーフィールドLENはMIDIリストのヘッダーに続く八重奏の数をコード化します。 ヘッダー旗Bが0であるなら、長い間、ヘッダーは1つの八重奏です、そして、LENは4ビットの分野です、15の八重奏の最大のMIDIリストの長さを支持して。
If B is 1, the header is two octets long, and LEN is a 12-bit field, supporting a maximum MIDI list length of 4095 octets. LEN is coded in network byte order (big-endian): the 4 bits of LEN that appear in the first header octet code the most significant 4 bits of the 12-bit LEN value.
Bが1であるなら、長い間、ヘッダーは2つの八重奏です、そして、LENは12ビットの分野です、4095の八重奏の最大のMIDIリストの長さを支持して。 LENはネットワークバイトオーダー(ビッグエンディアン)でコード化されます: 最初のヘッダー八重奏に現れるLENの4ビットは12ビットのLEN価値の最も重要な4ビットをコード化します。
A LEN value of 0 is legal, and it codes an empty MIDI list.
0のLEN値は法的です、そして、それは空のMIDIリストをコード化します。
Lazzaro & Wawrzynek Standards Track [Page 12] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[12ページ]。
If the J header bit is set to 1, a journal section MUST appear after the MIDI command section in the payload. If the J header bit is set to 0, the payload MUST NOT contain a journal section.
Jヘッダービットが1に設定されるなら、ジャーナル部はペイロードのMIDI指揮班の後に現れなければなりません。 Jヘッダービットが0に設定されるなら、ペイロードはジャーナル部を含んではいけません。
We define the semantics of the P header bit in Section 3.2.
私たちはセクション3.2でPヘッダービットの意味論を定義します。
If the LEN header field is nonzero, the MIDI list has the structure shown in Figure 3.
LENヘッダーフィールドが非零であるなら、MIDIリストには、図3で見せられた構造があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command N (0 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | デルタTime0(1-4 八重奏が切望するか、または0つの八重奏がZであるなら1と等しいです)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command0(八重奏1長さ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | デルタTime1(1-4 八重奏長さ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command1(八重奏1長さ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | デルタTime N(1-4 八重奏長さ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command N(0以上八重奏長さ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 -- MIDI list structure
図3--MIDIリスト構造
If the header flag Z is 1, the MIDI list begins with a complete MIDI command (coded in the MIDI Command 0 field, in Figure 3) preceded by a delta time (coded in the Delta Time 0 field). If Z is 0, the Delta Time 0 field is not present in the MIDI list, and the command coded in the MIDI Command 0 field has an implicit delta time of 0.
ヘッダー旗Zが1であるなら、完全なMIDIコマンド(MIDI Command0分野、図3では、コード化される)がデルタ時間(デルタTime0分野では、コード化される)までに先行されている状態で、MIDIリストは始まります。 Zが0であるなら、デルタTime0分野はMIDIリストに存在していません、そして、MIDI Command0分野でコード化されたコマンドは0の暗黙のデルタ時間を過します。
The MIDI list structure may also optionally encode a list of N additional complete MIDI commands, each coded in a MIDI Command K field. Each additional command MUST be preceded by a Delta Time K field, which codes the command's delta time. We discuss exceptions to the "command fields code complete MIDI commands" rule in Section 3.2.
また、MIDIリスト構造は任意にN追加完全なMIDIコマンド(MIDI Command K分野でコード化されたそれぞれ)のリストをコード化するかもしれません。 デルタTime K分野はそれぞれの追加コマンドに先行しなければなりません。(それは、コマンドのデルタ時間をコード化します)。 私たちはセクション3.2の「完全なMIDIが命令するコマンド欄コード」規則への例外について議論します。
The final MIDI command field (i.e., the MIDI Command N field, shown in Figure 3) in the MIDI list MAY be empty. Moreover, a MIDI list MAY consist a single delta time (encoded in the Delta Time 0 field) without an associated command (which would have been encoded in the MIDI Command 0 field). These rules enable MIDI coding features that are explained in Section 3.1. We delay the explanations because an understanding of RTP MIDI timestamps is necessary to describe the features.
MIDIリストの最終的なMIDIコマンド欄(すなわち、図3に示されたMIDI Command N分野)は人影がないかもしれません。 そのうえ、MIDIリストは成るかもしれません。関連コマンド(MIDI Command0分野でコード化された)のないただ一つのデルタ時間(デルタTime0分野では、コード化されます)。 これらの規則はセクション3.1で説明されるMIDIコード化の特徴を可能にします。 RTP MIDIタイムスタンプの理解が特徴について説明するのに必要であるので、私たちは説明を遅らせます。
Lazzaro & Wawrzynek Standards Track [Page 13] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[13ページ]。
3.1. Timestamps
3.1. タイムスタンプ
In this section, we describe how RTP MIDI encodes a timestamp for each MIDI list command. Command timestamps have the same units as RTP packet header timestamps (described in Section 2.1 and [RFC3550]). Recall that RTP timestamps have units of seconds, whose scaling is set during session configuration (see Section 6.1 and [RFC4566]).
このセクションで、私たちはRTP MIDIがどうそれぞれのMIDIリストコマンドのためのタイムスタンプをコード化するかを説明します。 コマンドタイムスタンプには、RTPパケットのヘッダータイムスタンプ(セクション2.1と[RFC3550]では、説明される)と同じユニットがあります。 RTPタイムスタンプにはユニットの秒があると思い出してください(セクション6.1と[RFC4566]を見てください)。(秒のスケーリングはセッション構成の間、設定されます)。
As shown in Figure 3, the MIDI list encodes time using a compact delta-time format. The RTP MIDI delta time syntax is a modified form of the MIDI File delta time syntax [MIDI]. RTP MIDI delta times use 1-4 octet fields to encode 32-bit unsigned integers. Figure 4 shows the encoded and decoded forms of delta times. Note that delta time values may be legally encoded in multiple formats; for example, there are four legal ways to encode the zero delta time (0x00, 0x8000, 0x808000, 0x80808000).
図3に示されるように、MIDIリストはコンパクトなデルタ時間形式を使用することで時間をコード化します。 RTP MIDIデルタ時間構文はMIDIファイルデルタ時間構文[MIDI]の変更されたフォームです。 RTP MIDIデルタ回数は、32ビットの符号のない整数をコード化するのに1-4 八重奏分野を使用します。 図4はコード化されて解読されたフォームのデルタ倍を示しています。 デルタ時間的価値が複数の形式で法的にコード化されるかもしれないことに注意してください。 例えば、デルタが調節するゼロ(0×00、0×8000、0×808000、0×80808000)をコード化する4つの法的な方法があります。
RTP MIDI uses delta times to encode a timestamp for each MIDI command. The timestamp for MIDI Command K is the summation (modulo 2^32) of the RTP timestamp and decoded delta times 0 through K. This cumulative coding technique, borrowed from MIDI File delta time coding, is efficient because it reduces the number of multi-octet delta times.
RTP MIDIは、それぞれのMIDIコマンドのためのタイムスタンプをコード化するのにデルタ回を使用します。 MIDIファイルデルタ時間コード化から借りられたK.のThisの累積しているコーディング技法でMIDI Command KがRTPタイムスタンプと解読されたデルタ現代0の足し算(法2^32)でありマルチ八重奏デルタ回数の数を減少させるので、タイムスタンプは効率的です。
All command timestamps in a packet MUST be less than or equal to the RTP timestamp of the next packet in the stream (modulo 2^32).
パケットのすべてのコマンドタイムスタンプが流れ(法2^32)における次のパケットに関するRTPよりタイムスタンプ以下であるに違いありません。
This restriction ensures that a particular RTP MIDI packet in a stream is uniquely responsible for encoding time starting at the moment after the RTP timestamp encoded in the RTP packet header, and ending at the moment before the final command timestamp encoded in the MIDI list. The "moment before" and "moment after" qualifiers acknowledge the "less than or equal" semantics (as opposed to "strictly less than") in the sentence above this paragraph.
この制限は、流れの特定のRTP MIDIパケットがMIDIリストでコード化された最終的なコマンドタイムスタンプの前に現在唯一RTPパケットのヘッダーでコード化されたRTPタイムスタンプの後に現在始まって、時間をコード化するのに原因となって、終わっているのを確実にします。 と対照的に、「」 「後の瞬間」資格を与える人が「以下か等しい」意味論を承認する前の瞬間、(「厳密により少ない、」、)、このパラグラフより高い文で。
Note that it is possible to "pad" the end of an RTP MIDI packet with time that is guaranteed to be void of MIDI commands, by setting the "Delta Time N" field of the MIDI list to the end of the void time, and by omitting its corresponding "MIDI Command N" field (a syntactic construction the preamble of Section 3 expressly made legal).
RTP MIDIパケットの端が空になるように保証されるMIDIコマンドの時間で「水増し」であることが可能であることにMIDIリストの「デルタ時間N」分野を空の現代の終わりに設定して、対応する「ミディコマンドN」分野(セクション3に関する序文が明白に法的にした統語構造)を省略することによって、注意してください。
In addition, it is possible to code an RTP MIDI packet to express that a period of time in the stream is void of MIDI commands. The RTP timestamp in the header would code the start of the void time. The MIDI list of this packet would consist of a "Delta Time 0" field
さらに、それを言い表すためにRTP MIDIパケットをコード化するのは流れMIDIコマンドの空間が中である期間に可能です。 ヘッダーのRTPタイムスタンプは空の現代の始まりをコード化するでしょう。 このパケットのMIDIリストは「デルタの時間の0インチの分野」から成るでしょう。
Lazzaro & Wawrzynek Standards Track [Page 14] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[14ページ]。
that coded the end of the void time. No other fields would be present in the MIDI list (a syntactic construction the preamble of Section 3 also expressly made legal).
それは空の現代の終わりをコード化しました。 他のどんな分野もMIDIリスト(セクション3に関する序文がまた明白に法的にした統語構造)に存在していないでしょう。
By default, a command timestamp indicates the execution time for the command. The difference between two timestamps indicates the time delay between the execution of the commands. This difference may be zero, coding simultaneous execution. In this memo, we refer to this interpretation of timestamps as "comex" (COMmand EXecution) semantics. We formally define comex semantics in Appendix C.3.
デフォルトで、コマンドタイムスタンプはコマンドのために実行時間を示します。 2つのタイムスタンプの違いはコマンドの実行の間の時間遅れを示します。 同時実行をコード化して、この違いはゼロであるかもしれません。 このメモでは、私たちは"comex"(COMmand EXecution)意味論とタイムスタンプのこの解釈を呼びます。 私たちは正式にAppendix C.3のcomex意味論を定義します。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map (encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
タイムスタンプのcomex解釈はコード変換のために、Standard MIDIファイル(SMF)をRTP MIDIの流れの中をよく、扱います、SMFsがファイルに格納されたそれぞれのMIDIコマンドのためのタイムスタンプをコード化するとき。 「移-コード」へのメートル法の時間マーカー(SMF速度が秒ベースのRTPタイムスタンプユニットにメートル法のSMFタイムスタンプユニットを変換するために写像する(SMFでは、メタ出来事としてコード化されます)使用)を使用するSMF。
The comex interpretation also works well for MIDI hardware controllers that are coding raw sensor data directly onto an RTP MIDI stream. Note that this controller design is preferable to a design that converts raw sensor data into a MIDI 1.0 cable command stream and then transcodes the stream onto an RTP MIDI stream.
また、comex解釈は生のセンサデータを直接RTP MIDIの流れにコード化しているMIDIハードウェアコントローラにうまくいきます。 このコントローラデザインが生のセンサデータをMIDI1.0に変換するデザインより望ましいというメモは、コマンドに流れに電報を打って、RTP MIDIの流れへの流れに当時の「移-コード」に電報を打ちます。
The comex interpretation of timestamps is usually not the best timestamp interpretation for transcoding a MIDI source that uses implicit command timing (such as MIDI 1.0 DIN cables) into an RTP MIDI stream. Appendix C.3 defines alternatives to comex semantics and describes session configuration tools for selecting the timestamp interpretation semantics for a stream.
通常、タイムスタンプのcomex解釈は暗黙のコマンドタイミング(DINが電報を打つMIDI1.0などの)をRTP MIDIの流れの中に使用するコード変換a MIDIソースに、最も良いタイムスタンプ解釈ではありません。 付録C.3は、流れのためにタイムスタンプ解釈意味論を選択するためにcomex意味論への代替手段を定義して、セッション構成ツールについて説明します。
Lazzaro & Wawrzynek Standards Track [Page 15] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[15ページ]。
One-Octet Delta Time:
1八重奏のデルタ時間:
Encoded form: 0ddddddd
Decoded form: 00000000 00000000 00000000 0ddddddd
コード化されたフォーム: 0ddddddd Decodedは形成します: 00000000 00000000 00000000 0ddddddd
Two-Octet Delta Time:
2八重奏のデルタ時間:
Encoded form: 1ccccccc 0ddddddd
Decoded form: 00000000 00000000 00cccccc cddddddd
コード化されたフォーム: 1ccccccc 0ddddddd Decodedは形成します: 00000000 00000000 00cccccc cddddddd
Three-Octet Delta Time:
3八重奏のデルタ時間:
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 00000000 000bbbbb bbcccccc cddddddd
コード化されたフォーム: 1bbbbbbb 1ccccccc 0ddddddd Decodedは形成します: 00000000 000bbbbb bbcccccc cddddddd
Four-Octet Delta Time:
4八重奏のデルタ時間:
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
コード化されたフォーム: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decodedは形成します: 0000aaaa aaabbbbb bbcccccc cddddddd
Figure 4 -- Decoding delta time formats
図4--デルタ時間書式を解読すること。
3.2. Command Coding
3.2. コマンドコード化
Each non-empty MIDI Command field in the MIDI list codes one of the MIDI command types that may legally appear on a MIDI 1.0 DIN cable. Standard MIDI File meta-events do not fit this definition and MUST NOT appear in the MIDI list. As a rule, each MIDI Command field codes a complete command, in the binary command format defined in [MIDI]. In the remainder of this section, we describe exceptions to this rule.
MIDIリストのそれぞれの非人影のないMIDI Command分野はMIDI1.0DINケーブルの上に法的に現れるかもしれないMIDIコマンドタイプのひとりをコード化します。 一般的なMIDIファイルメタ出来事は、この定義に合わないで、MIDIリストに現れてはいけません。 原則として、それぞれのMIDI Command分野は[MIDI]で定義された2進のコマンド形式で完全なコマンドをコード化します。 このセクションの残りでは、私たちはこの規則に例外を説明します。
The first MIDI channel command in the MIDI list MUST include a status octet. Running status coding, as defined in [MIDI], MAY be used for all subsequent MIDI channel commands in the list. As in [MIDI], System Common and System Exclusive messages (0xF0 ... 0xF7) cancel the running status state, but System Real-time messages (0xF8 ... 0xFF) do not affect the running status state. All System commands in the MIDI list MUST include a status octet.
MIDIリストにおける最初のMIDIチャネル指令は状態八重奏を含まなければなりません。 [MIDI]で定義されるように状態コード化を走らせるのはリストのすべてのその後のMIDIチャネル指令に使用されるかもしれません。 [MIDI]のように、System CommonとSystem Exclusiveメッセージ(0xF0…0xF7)は走行状態状態を取り消します、しかし、Systemレアル-時間メッセージ(0xF8…0xFF)は走行状態状態に影響しません。 MIDIリストにおけるすべてのSystemコマンドが状態八重奏を含まなければなりません。
As we note above, the first channel command in the MIDI list MUST include a status octet. However, the corresponding command in the original MIDI source data stream might not have a status octet (in this case, the source would be coding the command using running status). If the status octet of the first channel command in the MIDI list does not appear in the source data stream, the P (phantom) header bit MUST be set to 1. In all other cases, the P bit MUST be set to 0.
私たちが上で注意するように、MIDIリストにおける最初のチャネル指令は状態八重奏を含まなければなりません。 しかしながら、元のMIDIソースデータ・ストリームにおける対応するコマンドには、状態八重奏がないかもしれません(この場合、ソースは走行状態を使用することでコマンドをコード化しているでしょう)。 MIDIリストにおける、最初のチャネル指令の状態八重奏がソースデータ・ストリームに現れないなら、P(幻)ヘッダービットを1に設定しなければなりません。 他のすべての場合では、Pビットを0に設定しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 16] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[16ページ]。
Note that the P bit describes the MIDI source data stream, not the MIDI list encoding; regardless of the state of the P bit, the MIDI list MUST include the status octet.
PビットがMIDIリストコード化ではなく、MIDIソースデータ・ストリームについて説明することに注意してください。 Pビットの状態にかかわらず、MIDIリストは状態八重奏を含まなければなりません。
As receivers MUST be able to decode running status, sender implementors should feel free to use running status to improve bandwidth efficiency. However, senders SHOULD NOT introduce timing jitter into an existing MIDI command stream through an inappropriate use or removal of running status coding. This warning primarily applies to senders whose RTP MIDI streams may be transcoded onto a MIDI 1.0 DIN cable [MIDI] by the receiver: both the timestamps and the command coding (running status or not) must comply with the physical restrictions of implicit time coding over a slow serial line.
受信機が状態を走らせるのにおいて解読できなければならないので、送付者作成者は帯域幅効率を高めるのに遠慮なく走行状態を使用するべきです。 しかしながら、送付者SHOULD NOTは走行状態コード化の誤用か取り外しで既存のMIDIコマンドの流れにタイミングジターを取り入れます。 この警告は主としてRTP MIDIの流れが受信機によるMIDI1.0DINケーブル[MIDI]に移コード化されるかもしれない送付者に適用されます: タイムスタンプとコマンドコード化の両方(状態を走らせる)が遅いシリアル・ラインでの暗黙の時間コード化の物理的な制限に従わなければなりません。
On a MIDI 1.0 DIN cable [MIDI], a System Real-time command may be embedded inside of another "host" MIDI command. This syntactic construction is not supported in the payload format: a MIDI Command field in the MIDI list codes exactly one MIDI command (partially or completely).
MIDI1.0DINケーブル[MIDI]の上では、Systemレアル-時間コマンドは別の「ホスト」MIDIコマンドの埋め込まれた内部であるかもしれません。 この統語構造はペイロード形式で支持されません: MIDIリストのMIDI Command分野はまさに1つのMIDIコマンド(部分的か完全である)をコード化します。
To encode an embedded System Real-time command, senders MUST extract the command from its host and code it in the MIDI list as a separate command. The host command and System Real-time command SHOULD appear in the same MIDI list. The delta time of the System Real-time command SHOULD result in a command timestamp that encodes the System Real-time command placement in its original embedded position.
送付者は、埋め込まれたSystemレアル-時間コマンドをコード化するために、ホストからコマンドを抜粋して、別々のコマンドとしてMIDIリストでそれをコード化しなければなりません。 ホストコマンドとSystemレアル-時間コマンドSHOULDは同じMIDIリストに現れます。 オリジナルでSystemレアル-時間コマンドプレースメントをコード化するコマンドタイムスタンプのSystemレアル-時間コマンドSHOULD結果のデルタ時間は位置を埋め込みました。
Two methods are provided for encoding MIDI System Exclusive (SysEx) commands in the MIDI list. A SysEx command may be encoded in a MIDI Command field verbatim: a 0xF0 octet, followed by an arbitrary number of data octets, followed by a 0xF7 octet.
2つの方法が、MIDIリストにおけるMIDI System Exclusive(SysEx)コマンドをコード化しながら、備えられます。 SysExコマンドはMIDI Command分野で逐語的にコード化されるかもしれません: 0xF7八重奏で0xF0八重奏は続きました、続いて、データ八重奏の特殊活字の数字に続きます。
Alternatively, a SysEx command may be encoded as multiple segments. The command is divided into two or more SysEx command segments; each segment is encoded in its own MIDI Command field in the MIDI list.
あるいはまた、SysExコマンドは複数のセグメントとしてコード化されるかもしれません。 コマンドは2つ以上のSysExコマンドセグメントに分割されます。 各セグメントはMIDIリストのそれ自身のMIDI Command分野でコード化されます。
The payload format supports segmentation in order to encode SysEx commands that encode information in the temporal pattern of data octets. By encoding these commands as a series of segments, each data octet may be associated with a distinct delta time. Segmentation also supports the coding of large SysEx commands across several packets.
ペイロード形式は、データ八重奏の時系列パターンの情報をコード化するSysExコマンドをコード化するために分割を支持します。 一連のセグメントとしてこれらのコマンドをコード化することによって、それぞれのデータ八重奏は異なったデルタ時間に関連しているかもしれません。 また、分割はいくつかのパケットの向こう側に大きいSysExコマンドのコード化を支持します。
To segment a SysEx command, first partition its data octet list into two or more sublists. The last sublist MAY be empty (i.e., contain no octets); all other sublists MUST contain at least one data octet. To complete the segmentation, add the status octets defined in Figure
セグメントへのSysExコマンド、最初に、データ八重奏が2つ以上のサブリストに記載するパーティション。 最後のサブリストは空であるかもしれません(すなわち、八重奏を全く含まないでください)。 他のすべてのサブリストが少なくとも1つのデータ八重奏を含まなければなりません。 分割を完成するには、図で定義された状態八重奏を加えてください。
Lazzaro & Wawrzynek Standards Track [Page 17] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[17ページ]。
5 to the head and tail of the first, last, and any "middle" sublists. Figure 6 shows example segmentations of a SysEx command.
5 1番目、最終、およびどんな「中央」のサブリストのヘッドとテールにも。 図6はSysExコマンドの例の分割を示しています。
A sender MAY cancel a segmented SysEx command transmission that is in progress, by sending the "cancel" sublist shown in Figure 5. A "cancel" sublist MAY follow a "first" or "middle" sublist in the transmission, but MUST NOT follow a "last" sublist. The cancel MUST be empty (thus, 0xF7 0xF4 is the only legal cancel sublist).
送付者は進行している区分されたSysExコマンド送信を中止するかもしれません、図5に示された「キャンセル」サブリストを送ることによって。 「キャンセル」サブリストは、トランスミッションにおける「1番目」の、または、「中央」のサブリストに従うかもしれませんが、「最後」のサブリストは従ってはいけません。 キャンセルは空であるに違いありません(その結果、0xF7 0xF4は唯一の法的なキャンセルサブリストです)。
The cancellation feature is needed because Appendix C.1 defines configuration tools that let session parties exclude certain SysEx commands in the stream. Senders that transcode a MIDI source onto an RTP MIDI stream under these constraints have the responsibility of excluding undesired commands from the RTP MIDI stream.
Appendix C.1がセッションパーティーが流れで、あるSysExコマンドを除くことができる構成ツールを定義するので、キャンセル機能が必要です。 望まれないことを除いてこれらの規制でのRTP MIDIの流れへのMIDIソースが責任を持っている「移-コード」がRTP MIDIから流れると命令する送付者。
The cancellation feature lets a sender start the transmission of a command before the MIDI source has sent the entire command. If a sender determines that the command whose transmission is in progress should not appear on the RTP stream, it cancels the command. Without a method for cancelling a SysEx command transmission, senders would be forced to use a high-latency store-and-forward approach to transcoding SysEx commands onto RTP MIDI packets, in order to validate each SysEx command before transmission.
MIDIソースが全体のコマンドを送る前にキャンセル機能は送付者にコマンドの送信を始めさせることができます。 送付者が、トランスミッションが進行しているコマンドがRTPの流れのときに現れるべきでないと決心しているなら、それはコマンドを中止します。 SysExコマンド送信を中止するための方法がなければ、送付者はコード変換SysExコマンドへの高潜在店とフォワードアプローチをRTP MIDIパケットにやむを得ず使用するでしょう、トランスミッションの前にそれぞれのSysExコマンドを有効にするために。
The recommended receiver reaction to a cancellation depends on the capabilities of the receiver. For example, a sound synthesizer that is directly parsing RTP MIDI packets and rendering them to audio will be aware of the fact that SysEx commands may be cancelled in RTP MIDI. These receivers SHOULD detect a SysEx cancellation in the MIDI list and act as if they had never received the SysEx command.
キャンセルへのお勧めの受信機反応は受信機の能力によります。例えば、直接RTP MIDIパケットを分析して、それらをオーディオに提供している音のシンセサイザはSysExコマンドがRTP MIDIで中止されるかもしれないという事実を知るでしょう。 まるで彼らがSysExコマンドを一度も受け取ったことがなかったかのようにこれらの受信機SHOULDはMIDIリストと行為におけるSysExキャンセルを検出します。
As a second example, a synthesizer may be receiving MIDI data from an RTP MIDI stream via a MIDI DIN cable (or a software API emulation of a MIDI DIN cable). In this case, an RTP-MIDI-aware system receives the RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its emulation). Upon the receipt of the cancel sublist, the RTP-MIDI- aware transcoder might have already sent the first part of the SysEx command on the MIDI DIN cable to the receiver.
2番目の例として、シンセサイザはMIDI DINケーブル(または、MIDI DINケーブルのソフトウェアAPIエミュレーション)を通してRTP MIDIの流れからMIDIデータを受け取っているかもしれません。 この場合、RTP-MIDI意識しているシステムは、MIDI DINケーブル(または、エミュレーション)にRTP MIDIの流れを受けて、それを移コード化します。 キャンセルサブリストの領収書で、RTP-MIDIの意識しているトランスコーダは既にMIDI DINケーブルにおけるSysExコマンドの最初の部分を受信機に送ったかもしれません。
Unfortunately, the MIDI DIN cable protocol cannot directly code "cancel SysEx in progress" semantics. However, MIDI DIN cable receivers begin SysEx processing after the complete command arrives. The receiver checks to see if it recognizes the command (coded in the first few octets) and then checks to see if the command is the correct length. Thus, in practice, a transcoder can cancel a SysEx command by sending an 0xF7 to (prematurely) end the SysEx command -- the receiver will detect the incorrect command length and discard the command.
残念ながら、MIDI DINケーブルプロトコルは直接「進行中のキャンセルSysEx」意味論をコード化できません。 しかしながら、完全なコマンドが到着した後にMIDI DINケーブル受信機はSysEx処理を始めます。 受信機は、それがコマンド(わずかな最初の八重奏では、コード化される)を認識するかどうか確認するためにチェックして、次に、コマンドが適度の長さであるかどうか確認するためにチェックします。 したがって、実際には、トランスコーダは(早まって)SysExコマンドを終わらせるために0xF7を送ることによって、SysExコマンドを中止できます--受信機は、不正確なコマンドの長さを検出して、コマンドを捨てるでしょう。
Lazzaro & Wawrzynek Standards Track [Page 18] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[18ページ]。
Appendix C.1 defines configuration tools that may be used to prohibit SysEx command cancellation.
付録C.1はSysExコマンドキャンセルを禁止するのに使用されるかもしれない構成ツールを定義します。
The relative ordering of SysEx command segments in a MIDI list must match the relative ordering of the sublists in the original SysEx command. By default, commands other than System Real-time MIDI commands MUST NOT appear between SysEx command segments (Appendix C.1 defines configuration tools to change this default, to let other commands types appear between segments). If the command segments of a SysEx command are placed in the MIDI lists of two or more RTP packets, the segment ordering rules apply to the concatenation of all affected MIDI lists.
MIDIリストにおける、SysExコマンドセグメントの相対的な注文はオリジナルのSysExコマンドにおける、サブリストの相対的な注文に合わなければなりません。 デフォルトで、Systemレアル-時間MIDIコマンド以外のコマンドはSysExコマンドセグメントの間に現れてはいけません(付録C.1はタイプがセグメントの間で見える他のコマンドをさせるためにこのデフォルトを変える構成ツールを定義します)。 SysExコマンドのコマンドセグメントが2つ以上のRTPパケットのMIDIリストに置かれるなら、セグメント注文規則はすべての影響を受けるMIDIリストの連結に適用されます。
-----------------------------------------------------------
| Sublist Position | Head Status Octet | Tail Status Octet |
|-----------------------------------------------------------|
| first | 0xF0 | 0xF0 |
|-----------------------------------------------------------|
| middle | 0xF7 | 0xF0 |
|-----------------------------------------------------------|
| last | 0xF7 | 0xF7 |
|-----------------------------------------------------------|
| cancel | 0xF7 | 0xF4 |
-----------------------------------------------------------
----------------------------------------------------------- | サブリスト位置| ヘッド状態八重奏| テール状態八重奏| |-----------------------------------------------------------| | 1番目| 0xF0| 0xF0| |-----------------------------------------------------------| | 中央| 0xF7| 0xF0| |-----------------------------------------------------------| | 最終| 0xF7| 0xF7| |-----------------------------------------------------------| | キャンセル| 0xF7| 0xF4| -----------------------------------------------------------
Figure 5 -- Command segmentation status octets
図5--コマンド分割状態八重奏
[MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair to appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no semantic meaning in MIDI, apart from cancelling running status.
[MIDI]は、1(0xF0、0xF7)組の一部でない0xF7八重奏がMIDI1.0DINケーブルの上に現れることを許可します。 走行状態を取り消すことは別として、Unpaired 0xF7八重奏はMIDIにどんな意味意味も持っていません。
Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI Command section. We impose this restriction to avoid interference with the command segmentation coding defined in Figure 5.
Unpaired 0xF7八重奏はMIDI Command部のMIDIリストに現れてはいけません。 私たちは、図5で定義されるコマンド分割コード化の干渉を避けるためにこの制限を課します。
SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped 0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is dropped from the end of the SysEx command, and the status octet of the next MIDI command acts both to terminate the SysEx command and start the next command. To encode this construction in the payload format, follow these steps:
MIDI1.0DINケーブルの上で運ばれたSysExコマンドは「低下している0xF7"工事[MIDI]」を使用するかもしれません。 このコード化方法で、0xF7八重奏はSysExコマンドの終わりから落とされて、次のMIDIコマンドの状態八重奏は、ともに、SysExコマンドを終えて、次のコマンドを始めるために行動します。 ペイロード形式でこの工事をコード化するには、これらの方法に従ってください:
o Determine the appropriate delta times for the SysEx command and
the command that follows the SysEx command.
o SysExコマンドに続くSysExコマンドとコマンドのために適切なデルタ時勢を決定してください。
o Insert the "dropped" 0xF7 octet at the end of the SysEx command,
to form the standard SysEx syntax.
o 「低下している」0xF7八重奏をSysExコマンドの終わりに挿入して、標準のSysEx構文を形成してください。
Lazzaro & Wawrzynek Standards Track [Page 19] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[19ページ]。
o Code both commands into the MIDI list using the rules above.
o コードは、上の規則を使用することでともにMIDIリストの中に命令します。
o Replace the 0xF7 octet that terminates the verbatim SysEx
encoding or the last segment of the segmented SysEx encoding
with a 0xF5 octet. This substitution informs the receiver of
the original dropped 0xF7 coding.
o 逐語的なSysExコード化を終える0xF7八重奏か区分されたSysExコード化の最後のセグメントを0xF5八重奏に取り替えてください。 この代替はオリジナルの低下している0xF7コード化の受信機を知らせます。
[MIDI] reserves the undefined System Common commands 0xF4 and 0xF5 and the undefined System Real-time commands 0xF9 and 0xFD for future use. By default, undefined commands MUST NOT appear in a MIDI Command field in the MIDI list, with the exception of the 0xF5 octets used to code the "dropped 0xF7" construction and the 0xF4 octets used by SysEx "cancel" sublists.
[MIDI]は未来の未定義のSystemレアル-時間コマンドの0xF4、0xF5、0xF9、および0xFDが使用する未定義のSystem Commonコマンドを控えます。 デフォルトで、未定義のコマンドはMIDIリストのMIDI Command分野に現れてはいけません、八重奏が「低下している0xF7"工事とSysExによって使用された0xF4八重奏が「取り消される」というサブリスト」をコード化するのに使用した0xF5を除いて。
During session configuration, a stream may be customized to transport undefined commands (Appendix C.1). For this case, we now define how senders encode undefined commands in the MIDI list.
セッション構成の間、流れは、未定義のコマンド(付録C.1)を輸送するためにカスタマイズされるかもしれません。 このような場合、私たちは現在、MIDIリストで送付者がどう未定義のコマンドをコード化するかを定義します。
An undefined System Real-time command MUST be coded using the System Real-time rules.
Systemレアル-時間規則を使用して、未定義のSystemレアル-時間コマンドをコード化しなければなりません。
If the undefined System Common commands are put to use in a future version of [MIDI], the command will begin with an 0xF4 or 0xF5 status octet, followed by an arbitrary number of data octets (i.e., zero or more data bytes). To encode these commands, senders MUST terminate the command with an 0xF7 octet and place the modified command into the MIDI Command field.
[MIDI]の将来のバージョンにおける使用に未定義のSystem Commonコマンドをつけると、コマンドはデータ八重奏(すなわち、ゼロか、より多くのデータ・バイト)の特殊活字の数字があとに続いた0xF4か0xF5状態八重奏で始まるでしょう。 送付者は、これらのコマンドをコード化するために、0xF7八重奏でコマンドを終えて、変更されたコマンドをMIDI Command分野に置かなければなりません。
Unfortunately, non-compliant uses of the undefined System Common commands may appear in MIDI implementations. To model these commands, we assume that the command begins with an 0xF4 or 0xF5 status octet, followed by zero or more data octets, followed by zero or more trailing 0xF7 status octets. To encode the command, senders MUST first remove all trailing 0xF7 status octets from the command. Then, senders MUST terminate the command with an 0xF7 octet and place the modified command into the MIDI Command field.
残念ながら、未定義のSystem Commonコマンドの不従順な用途はMIDI実現に現れるかもしれません。 これらのコマンドをモデル化するために、私たちは、コマンドが0xF4か0xF5状態八重奏で始まると思います、ゼロか、より多くのデータ八重奏があとに続いているか、ゼロがあとに続いているか、または0xF7状態八重奏をより引きずって。 コマンドをコード化するために、送付者は最初に、コマンドからすべての引きずっている0xF7状態八重奏を取り除かなければなりません。 次に、送付者は、0xF7八重奏でコマンドを終えて、変更されたコマンドをMIDI Command分野に置かなければなりません。
Note that we include the trailing octets in our model as a cautionary measure: if such commands appeared in a non-compliant use of an undefined System Common command, an RTP MIDI encoding of the command that did not remove trailing octets could be mistaken for an encoding of "middle" or "last" sublist of a segmented SysEx commands (Figure 5) under certain packet loss conditions.
私たちがモデルで用心のために引きずっている八重奏を入れることに注意してください: そのようなコマンドが未定義のSystem Commonコマンドの不従順な使用で現れるなら、引きずっている八重奏を取り除かなかったコマンドをコード化するRTP MIDIは「中央」のコード化に間違えることができるでしょうにか、または区分されたSysExの「最後」のサブリストはあるパケット損失条件のもとで(図5)を命令します。
Lazzaro & Wawrzynek Standards Track [Page 20] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[20ページ]。
Original SysEx command:
オリジナルのSysExは命令します:
0xF0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
0xF0 0x01 0×02、0×03、0×04、0×05、0×06、0×07、0×08 0xF7
A two-segment segmentation:
2セグメントの分割:
0xF0 0x01 0x02 0x03 0x04 0xF0
0xF0 0x01 0×02、0×03、0×04 0xF0
0xF7 0x05 0x06 0x07 0x08 0xF7
0xF7 0x05 0×06、0×07、0×08 0xF7
A different two-segment segmentation:
異なった2セグメントの分割:
0xF0 0x01 0xF0
0xF0 0x01 0xF0
0xF7 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0xF7
0xF7 0x02 0×03、0×04、0×05、0×06、0×07、0×08 0xF7
A three-segment segmentation:
3セグメントの分割:
0xF0 0x01 0x02 0xF0
0xF0 0x01 0×02 0xF0
0xF7 0x03 0x04 0xF0
0xF7 0x03 0×04 0xF0
0xF7 0x05 0x06 0x07 0x08 0xF7
0xF7 0x05 0×06、0×07、0×08 0xF7
The segmentation with the largest number of segments:
セグメントの最多数がある分割:
0xF0 0x01 0xF0
0xF0 0x01 0xF0
0xF7 0x02 0xF0
0xF7 0x02 0xF0
0xF7 0x03 0xF0
0xF7 0x03 0xF0
0xF7 0x04 0xF0
0xF7 0x04 0xF0
0xF7 0x05 0xF0
0xF7 0x05 0xF0
0xF7 0x06 0xF0
0xF7 0x06 0xF0
0xF7 0x07 0xF0
0xF7 0x07 0xF0
0xF7 0x08 0xF0
0xF7 0x08 0xF0
0xF7 0xF7
0xF7 0xF7
Figure 6 -- Example segmentations
図6--例の分割
Lazzaro & Wawrzynek Standards Track [Page 21] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[21ページ]。
4. The Recovery Journal System
4. 回復ジャーナルシステム
The recovery journal is the default resiliency tool for unreliable transport. In this section, we normatively define the roles that senders and receivers play in the recovery journal system.
回復ジャーナルは頼り無い輸送のためのデフォルト弾性ツールです。 このセクションで、私たちは標準に、送付者と受信機が回復ジャーナルシステムで果たす役割を定義します。
MIDI is a fragile code. A single lost command in a MIDI command stream may produce an artifact in the rendered performance. We normatively classify rendering artifacts into two categories:
MIDIはこわれやすいコードです。 MIDIコマンドの流れにおけるただ一つの無くなっているコマンドはレンダリングされた性能で人工物を生産するかもしれません。 私たちは標準に表現人工物を2つのカテゴリに分類します:
o Transient artifacts. Transient artifacts produce immediate but
short-term glitches in the performance. For example, a lost
NoteOn (0x9) command produces a transient artifact: one note
fails to play, but the artifact does not extend beyond the end of
that note.
o 一時的な人工物。 一時的な人工物は性能で即座の、しかし、短期的な不調を発生させます。 例えば、無くなっているNoteOn(0×9)コマンドは一時的な人工物を生産します: 1つの注意はプレーしませんが、人工物はその注意の終わりを超えたところまで広がっていません。
o Indefinite artifacts. Indefinite artifacts produce long-lasting
errors in the rendered performance. For example, a lost NoteOff
(0x8) command may produce an indefinite artifact: the note that
should have been ended by the lost NoteOff command may sustain
indefinitely. As a second example, the loss of a Control Change
(0xB) command for controller number 7 (Channel Volume) may
produce an indefinite artifact: after the loss, all notes on the
channel may play too softly or too loudly.
o 無期人工物。 無期人工物はレンダリングされた性能で持続的な誤りを起こします。 例えば、無くなっているNoteOff(0×8)コマンドは無期人工物を生産するかもしれません: コマンドが無期限に支えるかもしれない無くなっているNoteOffが終わらせるはずであった音。 2番目の例として、コントローラNo.7(チャンネルVolume)のためのControl Change(0xB)コマンドの損失は無期人工物を生産するかもしれません: 損失の後に、チャンネルに関するすべての音符があまりに柔らかいかあまりにやかましく演奏されるかもしれません。
The purpose of the recovery journal system is to satisfy the recovery journal mandate: the MIDI performance rendered from an RTP MIDI stream sent over unreliable transport MUST NOT contain indefinite artifacts.
回復ジャーナルシステムの目的は回復ジャーナル命令を満たすことです: 頼り無い輸送の上に送られたRTP MIDIの流れから表されたMIDI性能は無期人工物を含んではいけません。
The recovery journal system does not use packet retransmission to satisfy this mandate. Instead, each packet includes a special section, called the recovery journal.
回復ジャーナルシステムは、この命令を満たすのにパケット「再-トランスミッション」を使用しません。 代わりに、各パケットは回復ジャーナルと呼ばれる特別なセクションを含んでいます。
The recovery journal codes the history of the stream, back to an earlier packet called the checkpoint packet. The range of coverage for the journal is called the checkpoint history. The recovery journal codes the information necessary to recover from the loss of an arbitrary number of packets in the checkpoint history. Appendix A.1 normatively defines the checkpoint packet and the checkpoint history.
回復ジャーナルはチェックポイントパケットと呼ばれる以前のパケットに流れの歴史をコード化して戻します。 ジャーナルのための適用範囲の範囲はチェックポイント歴史と呼ばれます。 回復ジャーナルは、チェックポイント歴史における、パケットの特殊活字の数字の損失から回復するために必要情報をコード化します。 付録A.1 normativelyはチェックポイントパケットとチェックポイント歴史を定義します。
When a receiver detects a packet loss, it compares its own knowledge about the history of the stream with the history information coded in the recovery journal of the packet that ends the loss event. By noting the differences in these two versions of the past, a receiver is able to transform all indefinite artifacts in the rendered
受信機がパケット損失を検出するとき、それは損失出来事を終わらせるパケットの回復ジャーナルでコード化される履歴情報に流れの歴史に関するそれ自身の知識をたとえます。 過去のこれらの2つのバージョンの違いに注意することによって、受信機はレンダリングのすべての無期人工物を変えることができます。
Lazzaro & Wawrzynek Standards Track [Page 22] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[22ページ]。
performance into transient artifacts, by executing MIDI commands to repair the stream.
流れを修理するMIDIコマンドを実行するのによる一時的な人工物への性能。
We now state the normative role for senders in the recovery journal system.
私たちは現在、回復ジャーナルシステムの送付者のために標準の役割を述べます。
Senders prepare a recovery journal for every packet in the stream. In doing so, senders choose the checkpoint packet identity for the journal. Senders make this choice by applying a sending policy. Appendix C.2.2 normatively defines three sending policies: "closed- loop", "open-loop", and "anchor".
送付者はあらゆるパケットのために流れで回復ジャーナルを準備します。 そうする際に、送付者はジャーナルのためのチェックポイントパケットのアイデンティティを選びます。 送付者は、送付方針を適用することによって、この選択をします。 付録C.2.2 normativelyは3つの送付方針を定義します: 「閉じている輪」、「転々流通」、および「アンカー。」
By default, senders MUST use the closed-loop sending policy. If the session description overrides this default policy, by using the parameter j_update defined in Appendix C.2.2, senders MUST use the specified policy.
デフォルトで、送付者は閉ループ送付方針を使用しなければなりません。 セッション記述がこのデフォルト方針をくつがえすなら、Appendix C.2.2で定義されたパラメタj_最新版を使用することによって、送付者は特約保険証券を使用しなければなりません。
After choosing the checkpoint packet identity for a packet, the sender creates the recovery journal. By default, this journal MUST conform to the normative semantics in Section 5 and Appendices A-B in this memo. In Appendix C.2.3, we define parameters that modify the normative semantics for recovery journals. If the session description uses these parameters, the journal created by the sender MUST conform to the modified semantics.
パケットのためのチェックポイントパケットのアイデンティティを選んだ後に、送付者は回復ジャーナルを作成します。 デフォルトで、このジャーナルはこのメモでセクション5とAppendices A-Bの標準の意味論に従わなければなりません。 Appendix C.2.3では、私たちは回復ジャーナルのために標準の意味論を変更するパラメタを定義します。 セッション記述がこれらのパラメタを使用するなら、送付者によって作成されたジャーナルは変更された意味論に従わなければなりません。
Next, we state the normative role for receivers in the recovery journal system.
次に、私たちは回復ジャーナルシステムの受信機のために標準の役割を述べます。
A receiver MUST detect each RTP sequence number break in a stream. If the sequence number break is due to a packet loss event (as defined in [RFC3550]), the receiver MUST repair all indefinite artifacts in the rendered MIDI performance caused by the loss. If the sequence number break is due to an out-of-order packet (as defined in [RFC3550]), the receiver MUST NOT take actions that introduce indefinite artifacts (ignoring the out-of-order packet is a safe option).
受信機は絶え間なくそれぞれのRTP一連番号中断を検出しなければなりません。 一連番号中断がパケット損失出来事のため([RFC3550]で定義されるように)であるなら、受信機は損失で引き起こされたレンダリングされたMIDI性能ですべての無期人工物を修理しなければなりません。 一連番号中断が故障しているパケットのため([RFC3550]で定義されるように)であるなら、受信機は無期人工物を導入する行動を取ってはいけません(故障しているパケットを無視するのは、安全な選択です)。
Receivers take special precautions when entering or exiting a session. A receiver MUST process the first received packet in a stream as if it were a packet that ends a loss event. Upon exiting a session, a receiver MUST ensure that the rendered MIDI performance does not end with indefinite artifacts.
セッションを入るか、または出るとき、受信機は特別な注意を払います。 受信機はまるでそれが損失出来事を終わらせるパケットであるかのように絶え間なく最初の容認されたパケットを処理しなければなりません。 セッション、受信機がそうしなければならない出るときに、レンダリングされたMIDI性能が無期人工物で終わらないのを確実にしてください。
Receivers are under no obligation to perform indefinite artifact repairs at the moment a packet arrives. A receiver that uses a playout buffer may choose to wait until the moment of rendering before processing the recovery journal, as the "lost" packet may be a late packet that arrives in time to use.
受信機が無期人工物修理を実行するどんな義務の下にもありません、現在、パケットは到着します。 再生バッファを使用する受信機は、それが「無くなっている」パケットが遅いパケットであるかもしれないので回復ジャーナルを処理する前の表現の瞬間に費やす時間到着するまで待つのを選ぶかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 23] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[23ページ]。
Next, we state the normative role for the creator of the session description in the recovery journal system. Depending on the application, the sender, the receivers, and other parties may take part in creating or approving the session description.
次に、私たちは回復ジャーナルシステムにおけるセッション記述の創造者のために標準の役割を述べます。 アプリケーション、送付者、受信機、および相手に頼るのは、セッション記述を作成するか、または承認するのに参加するかもしれません。
A session description that specifies the default closed-loop sending policy and the default recovery journal semantics satisfies the recovery journal mandate. However, these default behaviors may not be appropriate for all sessions. If the creators of a session description use the parameters defined in Appendix C.2 to override these defaults, the creators MUST ensure that the parameters define a system that satisfies the recovery journal mandate.
方針を送る閉ループしていた状態でデフォルトを指定するセッション記述とデフォルト回復ジャーナル意味論は回復ジャーナル命令を満たします。 しかしながら、これらのデフォルトの振舞いはすべてのセッションのために適切でないかもしれません。 セッション記述の創造者がこれらのデフォルトをくつがえすためにAppendix C.2で定義されたパラメタを使用するなら、創造者は、パラメタが回復ジャーナル命令を満たすシステムを定義するのを保証しなければなりません。
Finally, we note that this memo does not specify sender or receiver recovery journal algorithms. Implementations are free to use any algorithm that conforms to the requirements in this section. The non-normative [RFC4696] discusses sender and receiver algorithm design.
最終的に、私たちは、このメモが送付者か受信機回復ジャーナルアルゴリズムを指定しないことに注意します。実現は無料でこのセクションで要件に従うどんなアルゴリズムも使用できます。 非標準の[RFC4696]は送付者と受信機アルゴリズムデザインについて議論します。
5. Recovery Journal Format
5. 回復ジャーナル形式
This section introduces the structure of the recovery journal and defines the bitfields of recovery journal headers. Appendices A-B complete the bitfield definition of the recovery journal.
このセクションは、回復ジャーナルの構造を紹介して、回復ジャーナルヘッダーのbitfieldsを定義します。 付録A-Bは回復ジャーナルのbitfield定義を終了します。
The recovery journal has a three-level structure:
回復ジャーナルには、3レベルの構造があります:
o Top-level header.
o ヘッダーを先端で平らにしてください。
o Channel and system journal headers. These headers encode
recovery information for a single voice channel (channel journal)
or for all systems commands (system journal).
o チャンネルとシステムジャーナルヘッダー。 これらのヘッダーは単独の音声チャンネル(チャンネルジャーナル)かすべてのシステムコマンド(システムジャーナル)のための回復情報をコード化します。
o Chapters. Chapters describe recovery information for a single
MIDI command type.
o 章。 章は単独のMIDIコマンドタイプのために回復情報について説明します。
Figure 7 shows the top-level structure of the recovery journal. The recovery journals consists of a 3-octet header, followed by an optional system journal (labeled S-journal in Figure 7) and an optional list of channel journals. Figure 8 shows the recovery journal header format.
図7は回復ジャーナルのトップレベル構造を示しています。 回復ジャーナルは任意のシステムジャーナル(図7のS-ジャーナルとラベルされる)があとに続いた3八重奏のヘッダーとチャンネルジャーナルの任意のリストから成ります。 エイト環は回復ジャーナルヘッダー形式を示しています。
Lazzaro & Wawrzynek Standards Track [Page 24] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[24ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery journal header | S-journal ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel journals ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-ジャーナル… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ジャーナルはチャネルを開設します… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 -- Top-level recovery journal format
図7--トップレベル回復ジャーナル形式
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|Y|A|H|TOTCHAN| Checkpoint Packet Seqnum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|Y|A|H|TOTCHAN| チェックポイントパケットSeqnum| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 -- Recovery journal header
エイト環--回復ジャーナルヘッダー
If the Y header bit is set to 1, the system journal appears in the recovery journal, directly following the recovery journal header.
Yヘッダービットが1に設定されるなら、システムジャーナルは回復ジャーナルに載っています、直接回復ジャーナルヘッダーに続いて。
If the A header bit is set to 1, the recovery journal ends with a list of (TOTCHAN + 1) channel journals (the 4-bit TOTCHAN header field is interpreted as an unsigned integer).
Aヘッダービットが1に設定されるなら、回復ジャーナルは(TOTCHAN+1)チャンネルジャーナルのリストで終わります(4ビットのTOTCHANヘッダーフィールドは符号のない整数として解釈されます)。
A MIDI channel MAY be represented by (at most) one channel journal in a recovery journal. Channel journals MUST appear in the recovery journal in ascending channel-number order.
MIDIチャンネルは(高々)回復ジャーナルの1冊のチャンネルジャーナルによって代理をされるかもしれません。 チャンネルジャーナルは回復ジャーナルに論理機番オーダーを昇る際に載らなければなりません。
If A and Y are both zero, the recovery journal only contains its 3- octet header and is considered to be an "empty" journal.
AとYがあるなら、ゼロ、両方の回復ジャーナルは、3八重奏ヘッダーを含むだけであり、「空」のジャーナルであると考えられます。
The S (single-packet loss) bit appears in most recovery journal structures, including the recovery journal header. The S bit helps receivers efficiently parse the recovery journal in the common case of the loss of a single packet. Appendix A.1 defines S bit semantics.
S(単一のパケット損失)ビットは回復ジャーナルヘッダーを含むほとんどの回復ジャーナル構造に現れます。 Sビットは、受信機が単一のパケットの損失のよくある例で効率的に回復ジャーナルを分析するのを助けます。 付録A.1はS噛み付いている意味論を定義します。
The H bit indicates if MIDI channels in the stream have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
Hビットは、流れのMIDIチャンネルが(付録A.3.3)をコード化しながら高められた章Cを使用するために構成されたかどうかを示します。
By default, the payload format does not use enhanced Chapter C encoding. In this default case, the H bit MUST be set to 0 for all packets in the stream.
デフォルトで、ペイロード形式は高められた章C コード化を使用しません。 この不履行格では、流れにおけるすべてのパケットのためにHビットを0に設定しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 25] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[25ページ]。
If the stream has been configured so that controller numbers for one or more MIDI channels use enhanced Chapter C encoding, the H bit MUST be set to 1 in all packets in the stream. In Appendix C.2.3, we show how to configure a stream to use enhanced Chapter C encoding.
流れが構成されたなら、したがって、1個以上のMIDIチャンネルの数が使用するそのコントローラは章C コード化を高めて、Hビットは流れにおけるすべてのパケットの1へのセットであるに違いありません。 Appendix C.2.3では、私たちは、使用する流れが章C コード化を高めたのをどのように構成するかを示します。
The 16-bit Checkpoint Packet Seqnum header field codes the sequence number of the checkpoint packet for this journal, in network byte order (big-endian). The choice of the checkpoint packet sets the depth of the checkpoint history for the journal (defined in Appendix A.1).
16ビットのCheckpoint Packet Seqnumヘッダーフィールドはこのジャーナルのためにチェックポイントパケットの一連番号をコード化します、ネットワークバイトオーダー(ビッグエンディアン)で。 チェックポイントパケットの選択はジャーナル(Appendix A.1では、定義される)のためのチェックポイント歴史の深さを設定します。
Receivers may use the Checkpoint Packet Seqnum field of the packet that ends a loss event to verify that the journal checkpoint history covers the entire loss event. The checkpoint history covers the loss event if the Checkpoint Packet Seqnum field is less than or equal to one plus the highest RTP sequence number previously received on the stream (modulo 2^16).
受信機はジャーナルチェックポイント歴史が全体の損失出来事を覆うことを確かめるために損失出来事を終わらせるパケットのCheckpoint Packet Seqnum分野を使用するかもしれません。 チェックポイント歴史はCheckpoint Packet Seqnum分野が1以下と流れ(法2^16)のときに以前に受け取られた中で最も高いRTP一連番号であるなら損失出来事を覆っています。
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| CHAN |H| LENGTH |P|C|M|W|N|E|T|A| Chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| チェン|H| 長さ|P|C|M|W|N|E|T|A| 章… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 -- Channel journal format
図9--チャンネルジャーナル形式
Figure 9 shows the structure of a channel journal: a 3-octet header, followed by a list of leaf elements called channel chapters. A channel journal encodes information about MIDI commands on the MIDI channel coded by the 4-bit CHAN header field. Note that CHAN uses the same bit encoding as the channel nibble in MIDI Channel Messages (the cccc field in Figure E.1 of Appendix E).
図9はチャンネルジャーナルの構造を示しています: チャンネル章と呼ばれる葉の要素のリストがあとに続いた3八重奏のヘッダー。 チャンネルジャーナルは4ビットのチェンヘッダーフィールドによってコード化されたMIDIチャンネルの上にMIDIコマンドの情報をコード化します。 チェンがチャンネル少量としてMIDI Channel Messagesで(Appendix Eの図E.1のcccc分野)をコード化する同じビットを使用することに注意してください。
The 10-bit LENGTH field codes the length of the channel journal. The semantics for LENGTH fields are uniform throughout the recovery journal, and are defined in Appendix A.1.
10ビットのLENGTH分野はチャンネルジャーナルの長さをコード化します。 LENGTH分野への意味論は、回復ジャーナル中で一定であり、Appendix A.1で定義されます。
The third octet of the channel journal header is the Table of Contents (TOC) of the channel journal. The TOC is a set of bits that encode the presence of a chapter in the journal. Each chapter contains information about a certain class of MIDI channel command:
チャンネルジャーナルヘッダーの3番目の八重奏はチャンネルジャーナルの目次(TOC)です。 TOCはジャーナルでの章の存在をコード化する1セットのビットです。 各章はあるクラスのMIDIチャネル指令の情報を含んでいます:
o Chapter P: MIDI Program Change (0xC)
o Chapter C: MIDI Control Change (0xB)
o Chapter M: MIDI Parameter System (part of 0xB)
o Chapter W: MIDI Pitch Wheel (0xE)
o Chapter N: MIDI NoteOff (0x8), NoteOn (0x9)
o Chapter E: MIDI Note Command Extras (0x8, 0x9)
o 章P: MIDI Program Change(0xC)○章のC: MIDI Control Change(0xB)○章のM: MIDI Parameter System(0xBの一部)○章のW: MIDI Pitch Wheel(0xE)○章のN: MIDI NoteOff(0×8)、NoteOn○(0×9)章のE: ミディ注意コマンドエキストラ(0×8、0×9)
Lazzaro & Wawrzynek Standards Track [Page 26] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[26ページ]。
o Chapter T: MIDI Channel Aftertouch (0xD)
o Chapter A: MIDI Poly Aftertouch (0xA)
o 章T: MIDI Channel Aftertouch(0xD)o章のA: ミディポリー残触覚(0xA)
Chapters appear in a list following the header, in order of their appearance in the TOC. Appendices A.2-9 describe the bitfield format for each chapter, and define the conditions under which a chapter type MUST appear in the recovery journal. If any chapter types are required for a channel, an associated channel journal MUST appear in the recovery journal.
TOCのそれらの外観の順にヘッダーに続いて、章はリストに現れます。 付録A.2-9は各章のためにbitfield形式について説明して、章タイプが回復ジャーナルに載らなければならない状態を定義します。 何か章タイプがチャンネルに必要であるなら、関連チャンネルジャーナルは回復ジャーナルに載らなければなりません。
The H bit indicates if controller numbers on a MIDI channel have been configured to use the enhanced Chapter C encoding (Appendix A.3.3).
Hビットは、MIDIチャンネルのコントローラ番号が(付録A.3.3)をコード化しながら高められた章Cを使用するために構成されたかどうかを示します。
By default, controller numbers on a MIDI channel do not use enhanced Chapter C encoding. In this default case, the H bit MUST be set to 0 for all channel journal headers for the channel in the recovery journal, for all packets in the stream.
デフォルトで、MIDIチャンネルのコントローラ番号は高められた章C コード化を使用しません。 この不履行格では、Hビットは回復ジャーナルのチャンネルのためのオール・チャンネルジャーナルヘッダーのための0へのセットであるに違いありません、流れにおけるすべてのパケットのために。
However, if at least one controller number for a MIDI channel has been configured to use the enhanced Chapter C encoding, the H bit for its channel journal MUST be set to 1, for all packets in the stream.
しかしながら、MIDIチャンネルの少なくとも1つのコントローラ番号が高められた章のCコード化を使用するために構成されたなら、チャンネルジャーナルのためのHビットを1に設定しなければなりません、流れにおけるすべてのパケットのために。
In Appendix C.2.3, we show how to configure a controller number to use enhanced Chapter C encoding.
Appendix C.2.3では、私たちは、使用するコントローラ番号が章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 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|V|Q|F|X| LENGTH | System chapters ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|D|V|Q|F|X| 長さ| システム章… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 -- System journal format
図10--システムジャーナル形式
Figure 10 shows the structure of the system journal: a 2-octet header, followed by a list of system chapters. Each chapter codes information about a specific class of MIDI Systems command:
図10はシステムジャーナルの構造を示しています: システム章のリストがあとに続いた2八重奏のヘッダー。 各章は特定のクラスのMIDI Systemsコマンドの情報をコード化します:
o Chapter D: Song Select (0xF3), Tune Request (0xF6), Reset
(0xFF), undefined System commands (0xF4, 0xF5, 0xF9,
0xFD)
o Chapter V: Active Sense (0xFE)
o Chapter Q: Sequencer State (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC)
o Chapter F: MTC Tape Position (0xF1, 0xF0 0x7F 0xcc 0x01 0x01)
o Chapter X: System Exclusive (all other 0xF0)
o 章D: 歌のSelect(0xF3)、Tune Request(0xF6)、Reset(0xFF)、未定義のSystemは(0xF4、0xF5、0xF9、0xFD)○章Vを命令します: アクティブなSense(0xFE)○章のQ: シーケンサ州(0xF2、0xF8、0xF9、0xFA、0xFB、0xFC)○章のF: MTC Tape Position(0xF1、0xF0 0x7F 0xcc0x01 0×01)○章のX: システム排他的です。(他のすべての0xF0)
The 10-bit LENGTH field codes the size of the system journal and conforms to semantics described in Appendix A.1.
10ビットのLENGTH分野は、システムジャーナルのサイズをコード化して、Appendix A.1で説明された意味論に従います。
Lazzaro & Wawrzynek Standards Track [Page 27] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[27ページ]。
The D, V, Q, F, and X header bits form a Table of Contents (TOC) for the system journal. A TOC bit that is set to 1 codes the presence of a chapter in the journal. Chapters appear in a list following the header, in the order of their appearance in the TOC.
D、V、Q、F、およびXヘッダービットはシステムジャーナルのために、目次(TOC)を形成します。 1に設定されるTOCビットはジャーナルでの章の存在をコード化します。 TOCのそれらの外観の注文でヘッダーに続いて、章はリストに現れます。
Appendix B describes the bitfield format for the system chapters and defines the conditions under which a chapter type MUST appear in the recovery journal. If any system chapter type is required to appear in the recovery journal, the system journal MUST appear in the recovery journal.
付録Bは、システム章のためにbitfield形式について説明して、章タイプが回復ジャーナルに載らなければならない状態を定義します。 何かシステム章タイプが回復ジャーナルに載るのに必要であるなら、システムジャーナルは回復ジャーナルに載らなければなりません。
6. Session Description Protocol
6. セッション記述プロトコル
RTP does not perform session management. Instead, RTP works together with session management tools, such as the Session Initiation Protocol (SIP, [RFC3261]) and the Real Time Streaming Protocol (RTSP, [RFC2326]).
RTPはセッション管理を実行しません。 代わりに、RTPはセッション管理ツールと共に働いています、Session Initiationプロトコル(SIP、[RFC3261])やレアルTime Streamingプロトコル(RTSP、[RFC2326])のように。
RTP payload formats define media type parameters for use in session management (for example, this memo defines "rtp-midi" as the media type for native RTP MIDI streams).
RTPペイロード形式はセッション管理における使用のためのメディア型引数を定義します(例えば、このメモは「rtp-ミディ」を自然なRTP MIDIの流れのためのメディアタイプと定義します)。
In most cases, session management tools use the media type parameters via another standard, the Session Description Protocol (SDP, [RFC4566]).
多くの場合、別の規格、Session記述プロトコル(SDP、[RFC4566])でセッション管理ツールはメディア型引数を使用します。
SDP is a textual format for specifying session descriptions. Session
descriptions specify the network transport and media encoding for RTP
sessions. Session management tools coordinate the exchange of
session descriptions between participants ("parties").
SDPは、セッション記述を指定するための原文の形式です。 セッション記述はRTPのためにセッションをコード化するネットワーク輸送とメディアを指定します。 セッション管理ツールは関係者(「パーティー」)の間のセッション記述の交換を調整します。
Some session management tools use SDP to negotiate details of media transport (network addresses, ports, etc.). We refer to this use of SDP as "negotiated usage". One example of negotiated usage is the Offer/Answer protocol ([RFC3264] and Appendix C.7.2 in this memo) as used by SIP.
いくつかのセッション管理ツールが、メディア輸送(ネットワーク・アドレス、ポートなど)の詳細を交渉するのにSDPを使用します。 私たちは「交渉された用法」とSDPのこの使用を呼びます。 SIPによって使用されるように交渉された用法に関する1つの例がOffer/答えプロトコル(このメモによる[RFC3264]とAppendix C.7.2)です。
Other session management tools use SDP to declare the media encoding for the session but use other techniques to negotiate network transport. We refer to this use of SDP as "declarative usage". One example of declarative usage is RTSP ([RFC2326] and Appendix C.7.1 in this memo).
他のセッション管理ツールは、セッションのためにメディアコード化を宣言しますが、ネットワーク輸送を交渉するのに他のテクニックを使用するのにSDPを使用します。 私たちは「叙述的な用法」とSDPのこの使用を呼びます。 叙述的な用法に関する1つの例がRTSP(このメモによる[RFC2326]とAppendix C.7.1)です。
Below, we show session description examples for native (Section 6.1) and mpeg4-generic (Section 6.2) streams. In Section 6.3, we introduce session configuration tools that may be used to customize streams.
以下では、私たちがネイティブ(セクション6.1)の、そして、mpeg4一般的な(セクション6.2)流れのためのセッション記述の例を示しています。セクション6.3では、流れをカスタマイズするのに使用されるかもしれないセッション構成ツールを紹介します。
Lazzaro & Wawrzynek Standards Track [Page 28] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[28ページ]。
6.1. Session Descriptions for Native Streams
6.1. 自然な流れのためのセッション記述
The session description below defines a unicast UDP RTP session (via
a media ("m=") line) whose sole payload type (96) is mapped to a
minimal native RTP MIDI stream.
以下でのセッション記述は唯一のペイロードタイプ(96)が最小量の自然なRTP MIDIの流れに写像されるユニキャストUDP RTPセッション(メディア(「m=」)線を通した)を定義します。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap: 96rtp-ミディ/44100
The rtpmap attribute line uses the "rtp-midi" media type to specify an RTP MIDI native stream. The clock rate specified on the rtpmap line (in the example above, 44100 Hz) sets the scaling for the RTP timestamp header field (see Section 2.1, and also [RFC3550]).
rtpmap属性線は、RTP MIDIの自然な流れを指定するのに「rtp-ミディ」メディアタイプを使用します。 クロックレートはrtpmap線(上記の例の44100Hz)セットでRTPタイムスタンプヘッダーフィールドにスケーリングを指定しました(セクション2.1を見て、また、[RFC3550]を見てください)。
Note that this document does not specify a default clock rate value for RTP MIDI. When RTP MIDI is used with SDP, parties MUST use the rtpmap line to communicate the clock rate. Guidance for selecting the RTP MIDI clock rate value appears in Section 2.1.
このドキュメントがデフォルトクロックレート価値をRTP MIDIに指定しないことに注意してください。 RTP MIDIがSDPと共に使用されるとき、パーティーは、クロックレートを伝えるのにrtpmap線を使用しなければなりません。 RTP MIDIクロックレート価値を選択するための指導はセクション2.1に現れます。
We consider the RTP MIDI stream shown above to be "minimal" because the session description does not customize the stream with parameters. Without such customization, a native RTP MIDI stream has these characteristics:
私たちは、セッション記述がパラメタがある流れをカスタマイズしないので上で見せられたRTP MIDIの流れが「最小量である」と考えます。 そのような改造がなければ、自然なRTP MIDIの流れには、これらの特性があります:
1. If the stream uses unreliable transport (unicast UDP, multicast
UDP, etc.), the recovery journal system is in use, and the RTP
payload contains both the MIDI command section and the journal
section. If the stream uses reliable transport (such as TCP),
the stream does not use journalling, and the payload contains
only the MIDI command section (Section 2.2).
1. ストリームが頼り無い輸送(ユニキャストUDP、マルチキャストUDPなど)を使用するなら、回復ジャーナルシステムは使用中です、そして、RTPペイロードはMIDI指揮班とジャーナル部の両方を含んでいます。 ストリームが信頼できる輸送(TCPなどの)を使用するなら、ストリームはjournallingを使用しません、そして、ペイロードはMIDI指揮班(セクション2.2)だけを含みます。
2. If the stream uses the recovery journal system, the recovery
journal system uses the default sending policy and the default
journal semantics (Section 4).
2. ストリームが回復ジャーナルシステムを使用するなら、回復ジャーナルシステムはデフォルト送付方針とデフォルトジャーナル意味論(セクション4)を使用します。
3. In the MIDI command section of the payload, command timestamps
use the default "comex" semantics (Section 3).
3. ペイロードのMIDI指揮班では、コマンドタイムスタンプはデフォルト"comex"意味論(セクション3)を使用します。
4. The recommended temporal duration ("media time") of an RTP
packet ranges from 0 to 200 ms, and the RTP timestamp difference
between sequential packets in the stream may be arbitrarily
large (Section 2.1).
4. RTPパケットのお勧めの時の持続時間(「メディア時間」)は0〜200msから変化します、そして、ストリームにおける連続したパケットのRTPタイムスタンプ差は任意に大きいかもしれません(セクション2.1)。
Lazzaro & Wawrzynek Standards Track [Page 29] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[29ページ]。
5. If more than one minimal rtp-midi stream appears in a session,
the MIDI name spaces for these streams are independent: channel
1 in the first stream does not reference the same MIDI channel
as channel 1 in the second stream (see Appendix C.5 for a
discussion of the independence of minimal rtp-midi streams).
5. 1つ以上の最小量のrtp-ミディ小川がセッションのときに現れるなら、これらのストリームのためのMIDI名前空間は独立しています: 2番目のチャンネル1が流れるとき(最小量のrtp-ミディストリームからの独立の議論に関してAppendix C.5を見てください)、最初のストリームにおけるチャンネル1は同じMIDIが向けるどんな参照もしません。
6. The rendering method for the stream is not specified. What the
receiver "does" with a minimal native MIDI stream is "out of
scope" of this memo. For example, in content creation
environments, a user may manually configure client software to
render the stream with a specific software package.
6. ストリームのためのレンダリングメソッドは指定されません。 受信機が最小量のネイティブのMIDIストリームで「する」ことはこのメモの「範囲」です。 例えば、内容作成環境で、ユーザは、特定のソフトウェアパッケージでストリームをレンダリングするために手動でクライアントソフトウェアを構成するかもしれません。
As in standard in RTP, RTP sessions managed by SIP are sendrecv by default (parties send and receive MIDI), and RTP sessions managed by RTSP are recvonly by default (server sends and client receives).
RTPの規格のように、SIPによって管理されたRTPセッションはデフォルトでsendrecv(パーティーは、MIDIを送って、受け取る)です、そして、RTSPによって管理されたRTPセッションはデフォルトでrecvonlyです(サーバが発信します、そして、クライアントは受信します)。
In sendrecv RTP MIDI sessions for the session description shown above, the 16 voice channel + systems MIDI name space is unique for each sender. Thus, in a two-party session, the voice channel 0 sent by one party is distinct from the voice channel 0 sent by the other party.
上に示されたセッション記述のためのsendrecv RTP MIDIセッションのときに、各送付者にとって、スペースという16声のチャンネル+システムMIDI名はユニークです。 したがって、2パーティーのセッションでは、1回のパーティーによって送られた音声チャンネル0は相手によって送られた音声チャンネル0と異なっています。
This behavior corresponds to what occurs when two MIDI 1.0 DIN devices are cross-connected with two MIDI cables (one cable routing MIDI Out from the first device into MIDI In of the second device, a second cable routing MIDI In from the first device into MIDI Out of the second device). We define this "association" formally in Section 2.1.
この振舞いは2MIDI1.0DINデバイスが十字によって2本のMIDIケーブル(最初のデバイスからの最初のデバイスからの2番目のデバイスのMIDI Inへの1ケーブルルーティングMIDI Out、2番目のデバイスのMIDI Outへの第2のケーブルルーティングMIDI In)に接続されているとき起こることに対応しています。 私たちはセクション2.1で正式にこの「協会」を定義します。
MIDI 1.0 DIN networks may be configured in a "party-line" multicast topology. For these networks, the MIDI protocol itself provides tools for addressing specific devices in transactions on a multicast network, and for device discovery. Thus, apart from providing a 1- to-many forward path and a many-to-1 reverse path, IETF protocols do not need to provide any special support for MIDI multicast networking.
DINがネットワークでつなぐMIDI1.0は「共同回線」マルチキャストトポロジーで構成されるかもしれません。 これらのネットワークのために、MIDIプロトコル自体はマルチキャストネットワークでトランザクションで特定のデバイスを扱う、およびデバイス発見にツールを提供します。 1を提供することは別としてこのようにして、-、多く、フォワードパスと1への多くの逆の経路、IETFプロトコルはMIDIマルチキャストネットワークのどんな特別なサポートも提供する必要はありません。
6.2. Session Descriptions for mpeg4-generic Streams
6.2. mpeg4-ジェネリックStreamsのためのセッション記述
An mpeg4-generic [RFC3640] RTP MIDI stream uses an MPEG 4 Audio Object Type to render MIDI into audio. Three Audio Object Types accept MIDI input:
mpeg4-ジェネリック[RFC3640]RTP MIDIストリームは、オーディオにMIDIを翻訳するのにMPEG4Audio Object Typeを使用します。 3Audio Object TypesがMIDI入力を受け入れます:
o General MIDI (Audio Object Type ID 15), based on the General MIDI
rendering standard [MIDI].
o ジェネラルミディレンダリング規格に基づいたジェネラルミディ(オーディオObject Type ID15)[MIDI]。
o Wavetable Synthesis (Audio Object Type ID 14), based on the
Downloadable Sounds Level 2 (DLS 2) rendering standard [DLS2].
o Downloadable Sounds Level2(DLS2)レンダリング規格に基づいたWavetable Synthesis(オーディオObject Type ID14)[DLS2]。
Lazzaro & Wawrzynek Standards Track [Page 30] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[30ページ]。
o Main Synthetic (Audio Object Type ID 13), based on Structured
Audio and the programming language SAOL [MPEGSA].
o Structured Audioに基づいた主なSynthetic(オーディオObject Type ID13)とプログラミング言語SAOL[MPEGSA]。
The primary service of an mpeg4-generic stream is to code Access Units (AUs). We define the mpeg4-generic RTP MIDI AU as the MIDI payload shown in Figure 1 of Section 2.1 of this memo: a MIDI command section optionally followed by a journal section.
mpeg4-ジェネリックストリームの一次業務はAccess Units(AUs)をコード化することです。 私たちはこのメモのセクション2.1の図1で見せられたMIDIペイロードとmpeg4-ジェネリックRTP MIDI AUを定義します: MIDI指揮班はジャーナル部のそばで任意に従いました。
Exactly one RTP MIDI AU MUST be mapped to one mpeg4-generic RTP MIDI packet. The mpeg4-generic options for placing several AUs in an RTP packet MUST NOT be used with RTP MIDI. The mpeg4-generic options for fragmenting and interleaving AUs MUST NOT be used with RTP MIDI. The mpeg4-generic RTP packet payload (Figure 1 in [RFC3640]) MUST contain empty AU Header and Auxiliary sections. These rules yield mpeg4- generic packets that are structurally identical to native RTP MIDI packets, an essential property for the correct operation of the payload format.
ちょうど1RTP MIDI AU MUST、1つのmpeg4-ジェネリックRTP MIDIパケットに写像されてください。 RTP MIDIと共に数個のAUsをRTPパケットに置くためのmpeg4-ジェネリックオプションを使用してはいけません。 RTP MIDIと共にAUsを断片化して、はさみ込むためのmpeg4-ジェネリックオプションを使用してはいけません。 mpeg4-ジェネリックRTPパケットペイロード([RFC3640]の図1)は空のAU HeaderとAuxiliary部を含まなければなりません。 これらの規則は構造的にネイティブのRTP MIDIパケット(ペイロード形式の正しい操作のための不可欠の特性)と同じmpeg4ジェネリックパケットをもたらします。
The session description that follows defines a unicast UDP RTP
session (via a media ("m=") line) whose sole payload type (96) is
mapped to a minimal mpeg4-generic RTP MIDI stream. This example uses
the General MIDI Audio Object Type under Synthesis Profile @ Level 2.
続くセッション記述は唯一のペイロードタイプ(96)が最小量のmpeg4-ジェネリックRTP MIDIストリームに写像されるユニキャストUDP RTPセッション(メディア(「m=」)系列を通した)を定義します。 この例はSynthesis Profile@Level2の下でジェネラルミディAudio Object Typeを使用します。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; config=7A0A0000001A4D546864000000060000000100604D54726B0000 000600FF2F000
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 プロフィール平らなイドの=12。 コンフィグは7A0A0000001A4D546864000000060000000100604D54726B0000 000600FF2F000と等しいです。
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it comprises a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それはSDPの単線を包括します。)
The fmtp attribute line codes the four parameters (streamtype, mode, profile-level-id, and config) that are required in all mpeg4-generic session descriptions [RFC3640]. For RTP MIDI streams, the streamtype parameter MUST be set to 5, the "mode" parameter MUST be set to "rtp-midi", and the "profile-level-id" parameter MUST be set to the MPEG-4 Profile Level for the stream. For the Synthesis Profile, legal profile-level-id values are 11, 12, and 13, coding low (11), medium (12), or high (13) decoder computational complexity, as defined by MPEG conformance tests.
fmtp属性系列はすべてのmpeg4-ジェネリックセッション記述[RFC3640]で必要である4つのパラメタ(streamtype、モード、プロフィールレベルイド、およびコンフィグ)をコード化します。 RTP MIDIストリームにおいて、streamtypeパラメタを5に設定しなければならなくて、「rtp-ミディ」に「モード」パラメタを設定しなければならなくて、「平らなイドの輪郭を描いてください」というパラメタをストリームのためのMPEG-4Profile Levelに設定しなければなりません。 Synthesis Profileに関しては、法的な平らなイドの輪郭を描いている値は、11と、12と、13です、安値(11)、媒体(12)、または高い(13)デコーダ計算量をコード化して、MPEG順応テストで定義されるように。
Lazzaro & Wawrzynek Standards Track [Page 31] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[31ページ]。
In a minimal RTP MIDI session description, the config value MUST be a hexadecimal encoding [RFC3640] of the AudioSpecificConfig data block [MPEGAUDIO] for the stream. AudioSpecificConfig encodes the Audio Object Type for the stream and also encodes initialization data (SAOL programs, DLS 2 wave tables, etc.). Standard MIDI Files encoded in AudioSpecificConfig in a minimal session description MUST be ignored by the receiver.
最小量のRTP MIDIセッション記述では、コンフィグ値はストリームのために、AudioSpecificConfigデータ・ブロックの[RFC3640][MPEGAUDIO]をコード化する16進でなければなりません。 AudioSpecificConfigはストリームのためにAudio Object Typeをコード化して、また、初期化データ(SAOLプログラム、DLS2波のテーブルなど)をコード化します。 受信機でAudioSpecificConfigで最小量のセッション記述でコード化された標準のMIDIファイルを無視しなければなりません。
Receivers determine the rendering algorithm for the session by interpreting the first 5 bits of AudioSpecificConfig as an unsigned integer that codes the Audio Object Type. In our example above, the leading config string nibbles "7A" yield the Audio Object Type 15 (General MIDI). In Appendix E.4, we derive the config string value in the session description shown above; the starting point of the derivation is the MPEG bitstreams defined in [MPEGSA] and [MPEGAUDIO].
受信機は、Audio Object Typeをコード化する符号のない整数としてAudioSpecificConfigの最初の5ビットを解釈することによって、セッションのためのレンダリングアルゴリズムを決定します。 私たちの例では、上では、主なコンフィグストリング少量"7A"がオーディオオブジェクト・タイプ15(ジェネラルミディ)をもたらします。 Appendix E.4では、私たちは上でのセッション記述におけるコンフィグストリング価値を引き出します。 派生の出発点は[MPEGSA]と[MPEGAUDIO]で定義されたMPEG bitstreamsです。
We consider the stream to be "minimal" because the session description does not customize the stream through the use of parameters, other than the 4 required mpeg4-generic parameters described above. In Section 6.1, we describe the behavior of a minimal native stream, as a numbered list of characteristics. Items 1-4 on that list also describe the minimal mpeg4-generic stream, but items 5 and 6 require restatements, as listed below:
私たちは、セッション記述がパラメタの使用でストリームをカスタム設計しないのでストリームが「最小量である」と考えます、上で説明された4つの必要なmpeg4-ジェネリックパラメタを除いて。 セクション6.1では、私たちは、最小量のネイティブのストリームの振舞いを特性の番号付のリストと説明します。 また、そのリストの上の項目1-4は最小量のmpeg4-ジェネリックストリームについて説明しますが、項目5と6は再声明を必要とします、以下に記載されているように:
5. If more than one minimal mpeg4-generic stream appears in a
session, each stream uses an independent instance of the Audio
Object Type coded in the config parameter value.
5. 1つ以上の最小量のmpeg4-ジェネリック小川がセッションのときに現れるなら、各ストリームはコンフィグパラメタ価値でコード化されたAudio Object Typeの独立しているインスタンスを使用します。
6. A minimal mpeg4-generic stream encodes the AudioSpecificConfig
as an inline hexadecimal constant. If a session description is
sent over UDP, it may be impossible to transport large
AudioSpecificConfig blocks within the Maximum Transmission Size
(MTU) of the underlying network (for Ethernet, the MTU is 1500
octets). In some cases, the AudioSpecificConfig block may
exceed the maximum size of the UDP packet itself.
6. 最小量のmpeg4-ジェネリックストリームはインライン16進定数としてAudioSpecificConfigをコード化します。 セッション記述をUDPの上に送るなら、基本的なネットワークのMaximum Transmission Size(MTU)の中で大きいAudioSpecificConfigブロックを輸送するのは不可能であるかもしれません(イーサネットのために、MTUは1500の八重奏です)。 いくつかの場合、AudioSpecificConfigブロックはUDPパケット自体の最大サイズを超えるかもしれません。
The comments in Section 6.1 on SIP and RTSP stream directional defaults, sendrecv MIDI channel usage, and MIDI 1.0 DIN multicast networks also apply to mpeg4-generic RTP MIDI sessions.
SIPとRTSPの上のセクション6.1におけるコメントはまたマルチキャストネットワークがmpeg4-ジェネリックRTP MIDIセッションに適用する方向のデフォルト、sendrecv MIDIチャンネル用法、およびMIDI1.0DINを流します。
In sendrecv sessions, each party's session description MUST use identical values for the mpeg4-generic parameters (including the required streamtype, mode, profile-level-id, and config parameters). As a consequence, each party uses an identically configured MPEG 4 Audio Object Type to render MIDI commands into audio. The preamble to Appendix C discusses a way to create "virtual sendrecv" sessions that do not have this restriction.
sendrecvセッションのときに、各当事者のセッション記述はmpeg4-ジェネリックパラメタ(必要なstreamtype、モード、プロフィールレベルイド、およびコンフィグパラメタを含んでいる)に同じ値を使用しなければなりません。 結果として、各当事者は、MIDIコマンドをオーディオに翻訳するのに同様に構成されたMPEG4Audio Object Typeを使用します。 Appendix Cへの序文はこの制限を持っていない「仮想のsendrecv」セッションを作成する方法について議論します。
Lazzaro & Wawrzynek Standards Track [Page 32] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[32ページ]。
6.3. Parameters
6.3. パラメタ
This section introduces parameters for session configuration for RTP MIDI streams. In session descriptions, parameters modify the semantics of a payload type. Parameters are specified on an fmtp attribute line. See the session description example in Section 6.2 for an example of a fmtp attribute line.
このセクションはRTP MIDIストリームのためにセッション構成のためのパラメタを紹介します。セッション記述では、パラメタはペイロードタイプの意味論を変更します。 パラメタはfmtp属性系列で指定されます。 セクション6.2でfmtp属性系列の例に関してセッション記述の例を見てください。
The parameters add features to the minimal streams described in Sections 6.1-2, and support several types of services:
パラメタは、セクション6.1-2で説明された最小量のストリームに特徴を加えて、いくつかのタイプのサービスをサポートします:
o Stream subsetting. By default, all MIDI commands that are legal
to appear on a MIDI 1.0 DIN cable may appear in an RTP MIDI
stream. The cm_unused parameter overrides this default by
prohibiting certain commands from appearing in the stream. The
cm_used parameter is used in conjunction with cm_unused, to
simplify the specification of complex exclusion rules. We
describe cm_unused and cm_used in Appendix C.1.
o 副設定を流してください。 デフォルトで、すべてのMIDI1.0DINケーブルの上に現れるように法的なMIDIコマンドがRTP MIDIストリームに現れるかもしれません。 _の未使用のパラメタがストリームに現れるのからあるコマンドを禁じながらこのデフォルトをくつがえすcm。 cm_は、複雑な除外規則の仕様を簡素化するのにcm_に関連して未使用で使用されるパラメタを使用しました。 私たちは未使用とcm_がAppendix C.1で使用したcm_について説明します。
o Journal customization. The j_sec and j_update parameters
configure the use of the journal section. The ch_default,
ch_never, and ch_anchor parameters configure the semantics of
the recovery journal chapters. These parameters are described
in Appendix C.2 and override the default stream behaviors 1 and
2, listed in Section 6.1 and referenced in Section 6.2.
o ジャーナル改造。 j_秒とj_アップデートパラメタはジャーナル部の使用を構成します。 __ch_デフォルトであり、chに、chに、アンカーパラメタは回復ジャーナル章の意味論を決して構成しません。 これらのパラメタは、Appendix C.2で説明されて、セクション6.1に記載されていて、セクション6.2で参照をつけられるデフォルトストリームの振舞い1と2をくつがえします。
o MIDI command timestamp semantics. The tsmode, octpos, mperiod,
and linerate parameters customize the semantics of timestamps in
the MIDI command section. These parameters let RTP MIDI
accurately encode the implicit time coding of MIDI 1.0 DIN
cables. These parameters are described in Appendix C.3 and
override default stream behavior 3, listed in Section 6.1 and
referenced in Section 6.2
o MIDIはタイムスタンプ意味論を命令します。 tsmode、octpos、mperiod、およびlinerateパラメタはMIDI指揮班のタイムスタンプの意味論をカスタム設計します。 これらのパラメタで、RTP MIDIは正確にDINが電報を打つMIDI1.0の暗黙の時間コード化をコード化します。 これらのパラメタは、Appendix C.3とオーバーライドデフォルトストリーム振舞い3で説明されて、セクション6.1に記載されていて、セクション6.2で参照をつけられます。
o Media time. The rtp_ptime and rtp_maxptime parameters define
the temporal duration ("media time") of an RTP MIDI packet. The
guardtime parameter sets the minimum sending rate of stream
packets. These parameters are described in Appendix C.4 and
override default stream behavior 4, listed in Section 6.1 and
referenced in Section 6.2.
o メディア時間。 rtp_ptimeとrtp_maxptimeパラメタはRTP MIDIパケットの時の持続時間(「メディア時間」)を定義します。 guardtimeパラメタはストリームパケットの最小の送付レートを設定します。 これらのパラメタは、Appendix C.4とオーバーライドデフォルトストリーム振舞い4で説明されて、セクション6.1に記載されていて、セクション6.2で参照をつけられます。
o Stream description. The musicport parameter labels the MIDI
name space of RTP streams in a multimedia session. Musicport is
described in Appendix C.5. The musicport parameter overrides
default stream behavior 5, in Sections 6.1 and 6.2.
o 記述を流してください。 musicportパラメタはマルチメディアセッションのときにRTPストリームの名前スペースとMIDIをラベルします。 MusicportはAppendix C.5で説明されます。 musicportパラメタはセクション6.1と6.2でデフォルトストリーム振舞い5をくつがえします。
Lazzaro & Wawrzynek Standards Track [Page 33] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[33ページ]。
o MIDI rendering. Several parameters specify the MIDI rendering
method of a stream. These parameters are described in Appendix
C.6 and override default stream behavior 6, in Sections 6.1 and
6.2.
o MIDIレンダリング。 いくつかのパラメタがストリームのMIDIレンダリングメソッドを指定します。 これらのパラメタはAppendix C.6とオーバーライドデフォルトストリーム振舞い6、セクション6.1と6.2で説明されます。
In Appendix C.7, we specify interoperability guidelines for two RTP MIDI application areas: content-streaming using RTSP (Appendix C.7.1) and network musical performance using SIP (Appendix C.7.2).
Appendix C.7では、私たちは2つのRTP MIDI応用分野のための相互運用性ガイドラインを指定します: SIP(付録C.7.2)を使用することでRTSP(付録C.7.1)とネットワーク演奏を使用する満足しているストリーミング。
7. Extensibility
7. 伸展性
The payload format defined in this memo exclusively encodes all commands that may legally appear on a MIDI 1.0 DIN cable.
このメモで排他的に定義されたペイロード書式はMIDI1.0DINケーブルの上に法的に現れるかもしれないすべてのコマンドをコード化します。
Many worthy uses of MIDI over RTP do not fall within the narrow scope of the payload format. For example, the payload format does not support the direct transport of Standard MIDI File (SMF) meta-event and metric timing data. As a second example, the payload format does not define transport tools for user-defined commands (apart from tools to support System Exclusive commands [MIDI]).
RTPの上のMIDIの多くのふさわしい用途はペイロード形式の狭い範囲の中に下がりません。 例えば、ペイロード形式はStandard MIDIファイル(SMF)のメタイベントとメートル法のタイミングデータの直航運送をサポートしません。 2番目の例には、ペイロード形式はユーザによって定義されたコマンド(System Exclusiveコマンドが[MIDI]であるとサポートするツールは別として)のために輸送ツールを定義しません。
The payload format does not provide an extension mechanism to support new features of this nature, by design. Instead, we encourage the development of new payload formats for specialized musical applications. The IETF session management tools [RFC3264] [RFC2326] support codec negotiation, to facilitate the use of new payload formats in a backward-compatible way.
ペイロード形式は、デザインでこの種の新機能をサポートするために拡張機能を提供しません。 代わりに、私たちは専門化している音楽のアプリケーションのための新しいペイロード形式の開発を奨励します。 IETFセッション管理ツール[RFC3264][RFC2326]は、後方コンパチブル道における新しいペイロード形式の使用を容易にするためにコーデック交渉をサポートします。
However, the payload format does provide several extensibility tools, which we list below:
しかしながら、ペイロード形式はいくつかの伸展性ツールを提供します:(私たちは以下にツールを記載します)。
o Journalling. As described in Appendix C.2, new token values for
the j_sec and j_update parameters may be defined in IETF
standards-track documents. This mechanism supports the design
of new journal formats and the definition of new journal sending
policies.
o Journalling。 Appendix C.2で説明されるように、新しいトークンはjのために_秒を評価します、そして、j_アップデートパラメタはIETF標準化過程文書で定義されるかもしれません。 このメカニズムは新しいジャーナル形式のデザインと新しいジャーナル送付方針の定義をサポートします。
o Rendering. The payload format may be extended to support new
MIDI renderers (Appendix C.6.2). Certain general aspects of the
RTP MIDI rendering process may also be extended, via the
definition of new token values for the render (Appendix C.6) and
smf_info (Appendix C.6.4.1) parameters.
o レンダリング。 ペイロード形式は、新しいMIDIレンダラーが(付録C.6.2)であるとサポートするために広げられるかもしれません。 また、RTP MIDIレンダリングプロセスのある一定の一般的な局面は広げられるかもしれません、新しいトークン値の定義でインフォメーション(付録C.6.4.1)パラメタを(付録C.6)とsmf_に表してください。
o Undefined commands. [MIDI] reserves 4 MIDI System commands for
future use (0xF4, 0xF5, 0xF9, 0xFD). If updates to [MIDI]
define the reserved commands, IETF standards-track documents may
be defined to provide resiliency support for the commands.
o 未定義のコマンド。 [MIDI]は今後の使用(0xF4、0xF5、0xF9、0xFD)のために4つのMIDI Systemコマンドを控えます。 [MIDI]へのアップデートが予約されたコマンドを定義するなら、IETF標準化過程文書は、コマンドの弾性サポートを提供するために定義されるかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 34] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[34ページ]。
Opaque LEGAL fields appear in System Chapter D for this purpose
(Appendix B.1.1).
不透明なLEGAL野原はSystemに現れます。章D このために(付録B.1.1)。
A final form of extensibility involves the inclusion of the payload format in framework documents. Framework documents describe how to combine protocols to form a platform for interoperable applications. For example, a stage and studio framework might define how to use SIP [RFC3261], RTSP [RFC2326], SDP [RFC4566], and RTP [RFC3550] to support media networking for professional audio equipment and electronic musical instruments.
最終形態の伸展性はフレームワークドキュメントでのペイロード形式の包含にかかわります。 フレームワークドキュメントは共同利用できるアプリケーションのためにプラットホームを形成するためにプロトコルを結合する方法を説明します。 例えば、ステージとスタジオフレームワークは、メディアがプロのオーディオ設備と電子楽器のためのネットワークであるとサポートするためにSIP[RFC3261]、RTSP[RFC2326]、SDP[RFC4566]、およびRTP[RFC3550]を使用する方法を定義するかもしれません。
8. Congestion Control
8. 輻輳制御
The RTP congestion control requirements defined in [RFC3550] apply to RTP MIDI sessions, and implementors should carefully read the congestion control section in [RFC3550]. As noted in [RFC3550], all transport protocols used on the Internet need to address congestion control in some way, and RTP is not an exception.
[RFC3550]で定義されたRTP輻輳制御要件はRTP MIDIセッションに適用されます、そして、作成者は[RFC3550]の混雑制御セクションを注意して読み込むべきです。 [RFC3550]に述べられるように、インターネットで使用されるすべてのトランスポート・プロトコルが、混雑がコントロールであると何らかの方法で扱う必要があります、そして、RTPは例外ではありません。
In addition, the congestion control requirements defined in [RFC3551] applies to RTP MIDI sessions run under applicable profiles. The basic congestion control requirement defined in [RFC3551] is that RTP sessions that use UDP transport should monitor packet loss (via RTCP or other means) to ensure that the RTP stream competes fairly with TCP flows that share the network.
さらに、要件が[RFC3551]で定義した輻輳制御は適切なプロフィールの下で実行されたRTP MIDIセッションに申請されます。 [RFC3551]で定義された基本の輻輳制御要件はUDP輸送を使用するRTPセッションがRTPストリームがネットワークを共有するTCP流れと公正に競争するのを保証するために、パケット損失(RTCPか他の手段を通した)をモニターするべきであるということです。
Finally, RTP MIDI has congestion control issues that are unique for an audio RTP payload format. In applications such as network musical performance [NMP], the packet rate is linked to the gestural rate of a human performer. Senders MUST monitor the MIDI command source for patterns that result in excessive packet rates and take actions during RTP transcoding to reduce the RTP packet rate. [RFC4696] offers implementation guidance on this issue.
最終的に、RTP MIDIには、オーディオRTPペイロード形式に、ユニークな輻輳制御問題があります。 ネットワーク演奏[NMP]などの応用では、パケットレートは人間のパフォーマーのgesturalレートにリンクされます。 Sendersは、過度のパケットレートをもたらすパターンのためにMIDIコマンドソースをモニターして、RTPパケットレートを低下させるためにRTPコード変換の間、行動を取らなければなりません。 [RFC4696]はこの問題で実施要項を提供します。
9. Security Considerations
9. セキュリティ問題
Implementors should carefully read the Security Considerations sections of the RTP [RFC3550], AVP [RFC3551], and other RTP profile documents, as the issues discussed in these sections directly apply to RTP MIDI streams. Implementors should also review the Secure Real-time Transport Protocol (SRTP, [RFC3711]), an RTP profile that addresses the security issues discussed in [RFC3550] and [RFC3551].
作成者はRTP[RFC3550]、AVP[RFC3551]、および他のRTPプロフィールドキュメントのSecurity Considerations部を注意して読むべきです、これらのセクションで議論した問題が直接RTP MIDIストリームに適用されるとき。また、作成者はSecureレアル-時間Transportプロトコル(SRTP、[RFC3711])を見直すべきです、セキュリティが[RFC3550]と[RFC3551]で議論した問題であると扱うRTPプロフィール。
Here, we discuss security issues that are unique to the RTP MIDI payload format.
ここで、私たちはRTP MIDIペイロード形式にユニークな安全保障問題について議論します。
When using RTP MIDI, authentication of incoming RTP and RTCP packets is RECOMMENDED. Per-packet authentication may be provided by SRTP or
RTP MIDIを使用するとき、入って来るRTPとRTCPパケットの認証はRECOMMENDEDです。 または1パケットあたりの認証がSRTPによって提供されるかもしれない。
Lazzaro & Wawrzynek Standards Track [Page 35] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[35ページ]。
by other means. Without the use of authentication, attackers could forge MIDI commands into an ongoing stream, damaging speakers and eardrums. An attacker could also craft RTP and RTCP packets to exploit known bugs in the client and take effective control of a client machine.
他の手段で。 認証の使用がなければ、攻撃者は進行中のストリームにMIDIコマンドを作り出すことができました、スピーカーと鼓膜を損なって。攻撃者が取ることができて、また、工芸品のRTPと利用するRTCPパケットは、クライアントでバグを知って、クライアントマシンの有効なコントロールを取ります。
Session management tools (such as SIP [RFC3261]) SHOULD use authentication during the transport of all session descriptions containing RTP MIDI media streams. For SIP, the Security Considerations section in [RFC3261] provides an overview of possible authentication mechanisms. RTP MIDI session descriptions should use authentication because the session descriptions may code initialization data using the parameters described in Appendix C. If an attacker inserts bogus initialization data into a session description, he can corrupt the session or forge an client attack.
セッション管理ツール(SIP RFC3261などの)SHOULDはRTP MIDIメディアストリームを含むすべてのセッション記述の輸送の間、認証を使用します。SIPのために、RFC3261のSecurity Considerations部は可能な認証機構の概要を提供します; セッション記述がパラメタを使用することで初期化データをコード化するかもしれないので記述が認証を使用するべきであるRTP MIDIセッションはAppendix C.Ifの攻撃者のために差し込みについて説明しました。セッション記述へのにせの初期化データ、彼はセッションを崩壊させるか、またはクライアント攻撃を鍛造できます。
Session descriptions may also code renderer initialization data by reference, via the url (Appendix C.6.3) and smf_url (Appendix C.6.4.2) parameters. If the coded URL is spoofed, both session and client are open to attack, even if the session description itself is authenticated. Therefore, URLs specified in url and smf_url parameters SHOULD use [RFC2818].
また、セッション記述は参照でurl(付録C.6.3)とsmf_url(付録C.6.4.2)パラメタでレンダラー初期化データをコード化するかもしれません。 コード化されたURLが偽造されるなら、セッションとクライアントの両方が攻撃するためにオープンです、セッション記述自体が認証されても。 したがって、URLはurlパラメタSHOULDが使用するurlとsmf_[RFC2818]で指定しました。
Section 2.1 allows streams sent by a party in two RTP sessions to have the same SSRC value and the same RTP timestamp initialization value, under certain circumstances. Normally, these values are randomly chosen for each stream in a session, to make plaintext guessing harder to do if the payloads are encrypted. Thus, Section 2.1 weakens this aspect of RTP security.
2つのRTPセッションのときにパーティーによって送られたストリームはセクション2.1で同じSSRC値と同じRTPタイムスタンプ初期化価値を持つことができます、ある状況で。 通常、これらの値は、ペイロードが暗号化されているなら平文推測がそうするのをより困難にするように手当たりしだいにセッションにおける各ストリームに選ばれています。 したがって、セクション2.1はRTPセキュリティのこの局面を弱めます。
10. Acknowledgements
10. 承認
We thank the networking, media compression, and computer music community members who have commented or contributed to the effort, including Kurt B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, Tobias Erichsen, Nicolas Falquet, Dominique Fober, Philippe Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Michel Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, Dave Singer, Martijn Sipkema, William Stewart, Kent Terry, Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We also thank the members of the San Francisco Bay Area music and audio community for creating the context for the work, including Don Buchla, Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave Smith, Julius Smith, David Wessel, and Matt Wright.
私たちは取り組みにコメントするか、または貢献したネットワーク、メディア圧縮、およびコンピュータミュージック共同体のメンバーに感謝します、カートBを含んでいて、シンシアBruyns、スティーブCasner、ポール・デイヴィス、ロビン・デイヴィース、ジョアンDow、トビアス・エリクセン、ニコラスFalquet、ドミニクFober、フィリップGentric、マイケル・ゴッドフリィ; クリス・グリッグ、トッド・ヘーガー、ミシェル・ジュリアン、フィル・カー、ヤング-Kwonリム、ジェシカ・リトル、ジャン・バンderミーア、コリン・パーキンス、チャーリー・リッチモンド、ハービー・ロビンソン、ラリー・ロー、エリックScheirer、デーヴSinger、マーティンSipkema、ウィリアム・スチュワート、ケントテリー、マグヌスWesterlund、トム・ホワイト、ジム・ライト、ダグ・ワイアット、およびジョルジオZoia。 また、私たちは仕事のための文脈を作成して頂いて、サンフランシスコ湾岸地帯音楽とオーディオ共同体のメンバーに感謝します、ドンBuchla、クリスChafe、リチャード・ドゥダ、ダン・エリス、エードリアン・フリード、ベンGold、Jaronラニア、ロジャー・リン、リチャード・リヨン、ダナ・マッシー、マックス・マシューズ、キースMcMillen、Carver Mead、ネルソン・モーガン、トムOberheim、マルコム・スレイニー、デーヴ・スミス、ジューリアス・スミス、デヴィッド・ウェッセル、およびマット・ライトを含んでいて。
Lazzaro & Wawrzynek Standards Track [Page 36] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[36ページ]。
11. IANA Considerations
11. IANA問題
This section makes a series of requests to IANA. The IANA has completed registration/assignments of the below requests.
このセクションは一連の要求をIANAにします。 IANAは以下の要求の登録/課題を終了しました。
The sub-sections that follow hold the actual, detailed requests. All registrations in this section are in the IETF tree and follow the rules of [RFC4288] and [RFC3555], as appropriate.
続く小区分は実際の、そして、詳細な要求を保持します。 このセクションのすべての登録証明書が、IETF木にあって、適宜[RFC4288]と[RFC3555]の規則に従います。
In Section 11.1, we request the registration of a new media type: "audio/rtp-midi". Paired with this request is a request for a repository for new values for several parameters associated with "audio/rtp-midi". We request this repository in Section 11.1.1.
セクション11.1では、私たちはニューメディアタイプの登録を要求します: 「rtpオーディオ/ミディ。」 「rtpオーディオ/ミディ」に関連しているいくつかのパラメタのための新しい値のための倉庫を求めてこの要求と対にされているのは、要求です。 私たちはセクション11.1.1でこの倉庫を要求します。
In Section 11.2, we request the registration of a new value ("rtp-
midi") for the "mode" parameter of the "mpeg4-generic" media type.
The "mpeg4-generic" media type is defined in [RFC3640], and [RFC3640]
defines a repository for the "mode" parameter. However, we believe
we are the first to request the registration of a "mode" value, so we
believe the registry for "mode" has not yet been created by IANA.
セクション11.2では、私たちは「mpeg4-ジェネリック」メディアタイプの「モード」パラメタのために新しい価値(「rtpミディ」)の登録を要求します。 「mpeg4-ジェネリック」メディアタイプは[RFC3640]で定義されます、そして、[RFC3640]は「モード」パラメタのために倉庫を定義します。 しかしながら、私たちが「モード」価値の登録を要求する1番目であると信じていて、私たちは、「モード」のための登録がIANAによってまだ作成されていないと信じています。
Paired with our "mode" parameter value request for "mpeg4-generic" is a request for a repository for new values for several parameters we have defined for use with the "rtp-midi" mode value. We request this repository in Section 11.2.1.
私たちが使用のために「rtp-ミディ」最頻値で定義したいくつかのパラメタのための新しい値のための倉庫を求めて「mpeg4-ジェネリック」を求める私たちの「モード」パラメタ値の要求と対にされているのは、要求です。 私たちはセクション11.2.1でこの倉庫を要求します。
In Section 11.3, we request the registration of a new media type: "audio/asc". No repository request is associated with this request.
セクション11.3では、私たちはニューメディアタイプの登録を要求します: 「オーディオ/asc。」 どんな倉庫要求もこの要求に関連していません。
11.1. rtp-midi Media Type Registration
11.1. rtp-ミディメディアType Registration
This section requests the registration of the "rtp-midi" subtype for the "audio" media type. We request the registration of the parameters listed in the "optional parameters" section below (both the "non-extensible parameters" and the "extensible parameters" lists). We also request the creation of repositories for the "extensible parameters"; the details of this request appear in Section 11.1.1, below.
このセクションは「オーディオ」メディアタイプのために「rtp-ミディ」「副-タイプ」の登録を要求します。 私たちは、パラメタの登録が(「非広げることができるパラメタ」と「広げることができるパラメタ」リストの両方)の下の「任意のパラメタ」セクションで記載したよう要求します。 また、私たちは「広げることができるパラメタ」のために倉庫の作成を要求します。 この要求の詳細はセクション11.1.1未満に現れます。
Media type name:
メディア型名:
audio
オーディオ
Subtype name:
Subtypeは以下を命名します。
rtp-midi
rtp-ミディ
Lazzaro & Wawrzynek Standards Track [Page 37] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[37ページ]。
Required parameters:
必要なパラメタ:
rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1
for usage details.
以下を評価してください。 RTPタイムスタンプクロックレート。 利用明細に関してセクション2.1と6.1を見てください。
Optional parameters:
任意のパラメタ:
Non-extensible parameters:
非広げることができるパラメタ:
ch_anchor: See Appendix C.2.3 for usage details.
ch_default: See Appendix C.2.3 for usage details.
ch_never: See Appendix C.2.3 for usage details.
cm_unused: See Appendix C.1 for usage details.
cm_used: See Appendix C.1 for usage details.
chanmask: See Appendix C.6.4.3 for usage details.
cid: See Appendix C.6.3 for usage details.
guardtime: See Appendix C.4.2 for usage details.
inline: See Appendix C.6.3 for usage details.
linerate: See Appendix C.3 for usage details.
mperiod: See Appendix C.3 for usage details.
multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.
ch_アンカー: 利用明細ch_デフォルトに関してAppendix C.2.3を見てください: 利用明細chに関してAppendix C.2.3を決して見ないでください: 利用明細cm_Appendix C.2.3が未使用であることを見てください: 利用明細cm_Appendix C.1が使用されるのを見てください: 利用明細chanmaskに関してAppendix C.1を見てください: 利用明細Cidに関してAppendix C.6.4.3を見てください: 利用明細guardtimeに関してAppendix C.6.3を見てください: 利用明細インラインに関してAppendix C.4.2を見てください: 利用明細linerateに関してAppendix C.6.3を見てください: 利用明細mperiodに関してAppendix C.3を見てください: 利用明細マルチモードに関してAppendix C.3を見てください: 利用明細musicportに関してAppendix C.6.1を見てください: 利用明細octposに関してAppendix C.5を見てください: 利用明細rinitに関してAppendix C.3を見てください: 利用明細rtp_maxptimeに関してAppendix C.6.3を見てください: 利用明細rtp_ptimeに関してAppendix C.4.1を見てください: 利用明細smf_Cidに関してAppendix C.4.1を見てください: 利用明細smf_のためのAppendix C.6.4.2がインラインであることを見てください: 利用明細smf_urlに関してAppendix C.6.4.2を見てください: 利用明細tsmodeに関してAppendix C.6.4.2を見てください: 利用明細urlに関してAppendix C.3を見てください: 利用明細に関してAppendix C.6.3を見てください。
Extensible parameters:
広げることができるパラメタ:
j_sec: See Appendix C.2.1 for usage details. See
Section 11.1.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.1.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.1.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.1.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.1.1 for repository details.
j_秒: 利用明細に関してAppendix C.2.1を見てください。 倉庫の詳細j_のためのセクション11.1.1が以下をアップデートするのを見てください。 利用明細に関してAppendix C.2.2を見てください。 倉庫の詳細に関してセクション11.1.1を見てください。以下をレンダリングしてください。 利用明細に関してAppendix C.6を見てください。 倉庫の詳細subrenderに関してセクション11.1.1を見てください: 利用明細に関してAppendix C.6.2を見てください。 倉庫の詳細smf_インフォメーションに関してセクション11.1.1を見てください: 利用明細に関してAppendix C.6.4.1を見てください。 倉庫の詳細に関してセクション11.1.1を見てください。
Encoding considerations:
問題をコード化します:
The format for this type is framed and binary.
このタイプのための形式は、縁どられて2進です。
Lazzaro & Wawrzynek Standards Track [Page 38] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[38ページ]。
Restrictions on usage:
用法における制限:
This type is only defined for real-time transfers of MIDI
streams via RTP. Stored-file semantics for rtp-midi may
be defined in the future.
このタイプはMIDIストリームのリアルタイムの転送のためにRTPを通して定義されるだけです。 rtp-ミディのための保存されたファイル意味論は将来、定義されるかもしれません。
Security considerations:
セキュリティ問題:
See Section 9 of this memo.
このメモのセクション9を見てください。
Interoperability considerations:
相互運用性問題:
None.
なし。
Published specification:
広められた仕様:
This memo and [MIDI] serve as the normative specification. In
addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
このメモと[MIDI]は標準の仕様として機能します。 さらに、参照の[NMP]、[GRAME]、および[RFC4696]は非標準の実施要項を提供します。
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Audio content-creation hardware, such as MIDI controller piano
keyboards and MIDI audio synthesizers. Audio content-creation
software, such as music sequencers, digital audio workstations,
and soft synthesizers. Computer operating systems, for network
support of MIDI Application Programmer Interfaces. Content
distribution servers and terminals may use this media type for
low bit-rate music coding.
MIDIコントローラピアノキーボードやMIDIオーディオシンセサイザなどのオーディオ内容作成ハードウェア。 音楽シーケンサや、デジタル・オーディオワークステーションや、柔らかいシンセサイザなどのオーディオ内容作成ソフトウェア。 MIDI Application Programmer Interfacesのネットワークサポートのためのコンピュータオペレーティングシステム。 満足している分配サーバと端末は低いビット伝送速度音楽コード化にこのメディアタイプを使用するかもしれません。
Additional information:
追加情報:
None.
なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Intended usage:
意図している用法:
COMMON.
一般的。
Author:
以下を書いてください。
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Lazzaro & Wawrzynek Standards Track [Page 39] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[39ページ]。
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport Working Group delegated
from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
11.1.1. Repository Request for "audio/rtp-midi"
11.1.1. 「rtpオーディオ/ミディ」を求める倉庫要求
For the "rtp-midi" subtype, we request the creation of repositories for extensions to the following parameters (which are those listed as "extensible parameters" in Section 11.1).
「rtp-ミディ」「副-タイプ」に関しては、私たちは拡大のために以下のパラメタに倉庫の作成を要求します(どれがものであるかはセクション11.1の「広げることができるパラメタ」として記載しました)。
j_sec:
j_秒:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of this memo describes appropriate registrations for this
repository.
この倉庫のための登録証明書はIETF標準化過程文書で起こるだけであるかもしれません。 このメモの付録C.2.1はこの倉庫のための適切な登録証明書について説明します。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.
「なにも」: このメモのAppendix C.2.1では、定義されます。 "recj": このメモのAppendix C.2.1では、定義されます。
j_update:
j_アップデート:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.
この倉庫のための登録証明書はIETF標準化過程文書で起こるだけであるかもしれません。 このメモの付録C.2.2はこの倉庫のための適切な登録証明書について説明します。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.
「投錨してください」: このメモのAppendix C.2.2では、定義されます。 「開いている輪」: このメモのAppendix C.2.2では、定義されます。 「閉ループする」: このメモのAppendix C.2.2では、定義されます。
render:
レンダリングします:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in the preamble of Appendix C.6 for details
(the paragraph that begins "Other render token ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 それは始まります。詳細のためのAppendix C.6に関する序文のテキストを見てください、(パラグラフ、「もう一方はトークンをレンダリングする」…、)
Lazzaro & Wawrzynek Standards Track [Page 40] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[40ページ]。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 of this memo.
"api": Defined in Appendix C.6 of this memo.
"null": Defined in Appendix C.6 of this memo.
「未知」: このメモのAppendix C.6では、定義されます。 「合成」: このメモのAppendix C.6では、定義されます。 "api": このメモのAppendix C.6では、定義されます。 「ヌル」: このメモのAppendix C.6では、定義されます。
subrender:
subrender:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 詳細(「他のsubrenderトークン」を始めるパラグラフ)に関してテキストAppendix C.6.2を見てください。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"default": Defined in Appendix C.6.2 of this memo.
「デフォルトとしてください」: このメモのAppendix C.6.2では、定義されます。
smf_info:
smf_インフォメーション:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in Appendix C.6.4.1 for details (the
paragraph that begins "Other smf_info token ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 詳細(「他のsmf_インフォメーショントークン」を始めるパラグラフ)に関してAppendix C.6.4.1のテキストを見てください。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"ignore": Defined in Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.
「無視します」: このメモのAppendix C.6.4.1では、定義されます。 「sdp_始め」: このメモのAppendix C.6.4.1では、定義されます。 「アイデンティティ」: このメモのAppendix C.6.4.1では、定義されます。
11.2. mpeg4-generic Media Type Registration
11.2. mpeg4-ジェネリックメディアType Registration
This section requests the registration of the "rtp-midi" value for the "mode" parameter of the "mpeg4-generic" media type. The "mpeg4- generic" media type is defined in [RFC3640], and [RFC3640] defines a repository for the "mode" parameter. We are registering mode rtp- midi to support the MPEG Audio codecs [MPEGSA] that use MIDI.
このセクションは「mpeg4-ジェネリック」メディアタイプの「モード」パラメタのために「rtp-ミディ」価値の登録を要求します。 「mpeg4ジェネリック」メディアタイプは[RFC3640]で定義されます、そして、[RFC3640]は「モード」パラメタのために倉庫を定義します。 私たちは、MPEGがMIDIを使用するAudioコーデック[MPEGSA]であるとサポートするためにモードrtpミディを登録しています。
In conjunction with this registration request, we request the registration of the parameters listed in the "optional parameters" section below (both the "non-extensible parameters" and the "extensible parameters" lists). We also request the creation of repositories for the "extensible parameters"; the details of this request appear in Appendix 11.2.1, below.
この登録要求に関連して、私たちは、パラメタの登録が(「非広げることができるパラメタ」と「広げることができるパラメタ」リストの両方)の下の「任意のパラメタ」セクションで記載したよう要求します。 また、私たちは「広げることができるパラメタ」のために倉庫の作成を要求します。 この要求の詳細はAppendix11.2.1未満に現れます。
Lazzaro & Wawrzynek Standards Track [Page 41] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[41ページ]。
Media type name:
メディア型名:
audio
オーディオ
Subtype name:
Subtypeは以下を命名します。
mpeg4-generic
mpeg4-ジェネリック
Required parameters:
必要なパラメタ:
The "mode" parameter is required by [RFC3640]. [RFC3640]
requests a repository for "mode", so that new values for mode
may be added. We request that the value "rtp-midi" be
added to the "mode" repository.
「モード」パラメタは[RFC3640]によって必要とされます。 モードのための新しい値が加えられるかもしれなくて、[RFC3640]は「モード」のために倉庫を要求します。 私たちは、値の「rtp-ミディ」が「モード」倉庫に加えられるよう要求します。
In mode rtp-midi, the mpeg4-generic parameter rate is
a required parameter. Rate specifies the RTP timestamp
clock rate. See Sections 2.1 and 6.2 for usage details
of rate in mode rtp-midi.
モードrtp-ミディでは、mpeg4-ジェネリックパラメタレートは必要なパラメタです。 レートはRTPタイムスタンプクロックレートを指定します。 モードrtp-ミディのレートの利用明細に関してセクション2.1と6.2を見てください。
Optional parameters:
任意のパラメタ:
We request registration of the following parameters
for use in mode rtp-midi for mpeg4-generic.
私たちはモードrtp-ミディにおける、mpeg4-ジェネリックの使用のための以下のパラメタの登録を要求します。
Non-extensible parameters:
非広げることができるパラメタ:
ch_anchor: See Appendix C.2.3 for usage details.
ch_default: See Appendix C.2.3 for usage details.
ch_never: See Appendix C.2.3 for usage details.
cm_unused: See Appendix C.1 for usage details.
cm_used: See Appendix C.1 for usage details.
chanmask: See Appendix C.6.4.3 for usage details.
cid: See Appendix C.6.3 for usage details.
guardtime: See Appendix C.4.2 for usage details.
inline: See Appendix C.6.3 for usage details.
linerate: See Appendix C.3 for usage details.
mperiod: See Appendix C.3 for usage details.
multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
ch_アンカー: 利用明細ch_デフォルトに関してAppendix C.2.3を見てください: 利用明細chに関してAppendix C.2.3を決して見ないでください: 利用明細cm_Appendix C.2.3が未使用であることを見てください: 利用明細cm_Appendix C.1が使用されるのを見てください: 利用明細chanmaskに関してAppendix C.1を見てください: 利用明細Cidに関してAppendix C.6.4.3を見てください: 利用明細guardtimeに関してAppendix C.6.3を見てください: 利用明細インラインに関してAppendix C.4.2を見てください: 利用明細linerateに関してAppendix C.6.3を見てください: 利用明細mperiodに関してAppendix C.3を見てください: 利用明細マルチモードに関してAppendix C.3を見てください: 利用明細musicportに関してAppendix C.6.1を見てください: 利用明細octposに関してAppendix C.5を見てください: 利用明細rinitに関してAppendix C.3を見てください: 利用明細rtp_maxptimeに関してAppendix C.6.3を見てください: 利用明細rtp_ptimeに関してAppendix C.4.1を見てください: 利用明細smf_Cidに関してAppendix C.4.1を見てください: 利用明細smf_のためのAppendix C.6.4.2がインラインであることを見てください: 利用明細に関してAppendix C.6.4.2を見てください。
Lazzaro & Wawrzynek Standards Track [Page 42] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[42ページ]。
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.
smf_url: 利用明細tsmodeに関してAppendix C.6.4.2を見てください: 利用明細urlに関してAppendix C.3を見てください: 利用明細に関してAppendix C.6.3を見てください。
Extensible parameters:
広げることができるパラメタ:
j_sec: See Appendix C.2.1 for usage details. See
Section 11.2.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.2.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.2.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.2.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.2.1 for repository details.
j_秒: 利用明細に関してAppendix C.2.1を見てください。 倉庫の詳細j_のためのセクション11.2.1が以下をアップデートするのを見てください。 利用明細に関してAppendix C.2.2を見てください。 倉庫の詳細に関してセクション11.2.1を見てください。以下をレンダリングしてください。 利用明細に関してAppendix C.6を見てください。 倉庫の詳細subrenderに関してセクション11.2.1を見てください: 利用明細に関してAppendix C.6.2を見てください。 倉庫の詳細smf_インフォメーションに関してセクション11.2.1を見てください: 利用明細に関してAppendix C.6.4.1を見てください。 倉庫の詳細に関してセクション11.2.1を見てください。
Encoding considerations:
問題をコード化します:
The format for this type is framed and binary.
このタイプのための形式は、縁どられて2進です。
Restrictions on usage:
用法における制限:
Only defined for real-time transfers of audio/mpeg4-generic
RTP streams with mode=rtp-midi.
モード=rtp-ミディによるmpeg4オーディオ/ジェネリックRTPストリームのリアルタイムの転送のために定義されているだけです。
Security considerations:
セキュリティ問題:
See Section 9 of this memo.
このメモのセクション9を見てください。
Interoperability considerations:
相互運用性問題:
Except for the marker bit (Section 2.1), the packet formats
for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi)
are identical. The formats differ in use: audio/mpeg4-generic
is for MPEG work, and audio/rtp-midi is for all other work.
マーカービット(セクション2.1)を除いて、rtpオーディオ/ミディとmpeg4オーディオ/ジェネリック(モードrtp-ミディ)のためのパケット・フォーマットは同じです。 形式は使用中に異なります: mpeg4オーディオ/ジェネリックはMPEG仕事のためのものです、そして、rtpオーディオ/ミディは他のすべての仕事のためのものです。
Published specification:
広められた仕様:
This memo, [MIDI], and [MPEGSA] are the normative references.
In addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
このメモであり、[MIDI]、および[MPEGSA]は引用規格です。 さらに、参照の[NMP]、[GRAME]、および[RFC4696]は非標準の実施要項を提供します。
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
MPEG 4 servers and terminals that support [MPEGSA].
MPEG4サーバと[MPEGSA]をサポートする端末。
Lazzaro & Wawrzynek Standards Track [Page 43] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[43ページ]。
Additional information:
追加情報:
None.
なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Intended usage:
意図している用法:
COMMON.
一般的。
Author:
以下を書いてください。
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport Working Group delegated
from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
11.2.1. Repository Request for Mode rtp-midi for mpeg4-generic
11.2.1. mpeg4-ジェネリックのためのMode rtp-ミディのための倉庫Request
For mode rtp-midi of the mpeg4-generic subtype, we request the creation of repositories for extensions to the following parameters (which are those listed as "extensible parameters" in Section 11.2).
mpeg4-ジェネリック「副-タイプ」のモードrtp-ミディに関しては、私たちは拡大のために以下のパラメタに倉庫の作成を要求します(どれがものであるかはセクション11.2の「広げることができるパラメタ」として記載しました)。
j_sec:
j_秒:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of this memo describes appropriate registrations for this
repository.
この倉庫のための登録証明書はIETF標準化過程文書で起こるだけであるかもしれません。 このメモの付録C.2.1はこの倉庫のための適切な登録証明書について説明します。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.
「なにも」: このメモのAppendix C.2.1では、定義されます。 "recj": このメモのAppendix C.2.1では、定義されます。
j_update:
j_アップデート:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.
この倉庫のための登録証明書はIETF標準化過程文書で起こるだけであるかもしれません。 このメモの付録C.2.2はこの倉庫のための適切な登録証明書について説明します。
Lazzaro & Wawrzynek Standards Track [Page 44] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[44ページ]。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.
「投錨してください」: このメモのAppendix C.2.2では、定義されます。 「開いている輪」: このメモのAppendix C.2.2では、定義されます。 「閉ループする」: このメモのAppendix C.2.2では、定義されます。
render:
レンダリングします:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in the preamble of Appendix C.6 for details
(the paragraph that begins "Other render token ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 それは始まります。詳細のためのAppendix C.6に関する序文のテキストを見てください、(パラグラフ、「もう一方はトークンをレンダリングする」…、)
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 of this memo.
"null": Defined in Appendix C.6 of this memo.
「未知」: このメモのAppendix C.6では、定義されます。 「合成」: このメモのAppendix C.6では、定義されます。 「ヌル」: このメモのAppendix C.6では、定義されます。
subrender:
subrender:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ..." and
subsequent paragraphs). Note that the text in
Appendix C.6.2 contains restrictions on subrender
registrations for mpeg4-generic ("Registrations
for mpeg4-generic subrender values ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 詳細(「他のsubrenderトークン」を始めるパラグラフ、およびその後のパラグラフ)に関してテキストAppendix C.6.2を見てください。 Appendix C.6.2のテキストがmpeg4-ジェネリック(「mpeg4-ジェネリックsubrender値のための登録証明書」)のためのsubrender登録証明書に制限を含むことに注意してください。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"default": Defined in Appendix C.6.2 of this memo.
「デフォルトとしてください」: このメモのAppendix C.6.2では、定義されます。
smf_info:
smf_インフォメーション:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in Appendix C.6.4.1 for details (the
paragraph that begins "Other smf_info token ...").
この倉庫のための登録証明書は提案された価値の用法の仕様を含まなければなりません。 詳細(「他のsmf_インフォメーショントークン」を始めるパラグラフ)に関してAppendix C.6.4.1のテキストを見てください。
Initial values for this repository appear below:
この倉庫への初期の値は以下に現れます:
"ignore": Defined in Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.
「無視します」: このメモのAppendix C.6.4.1では、定義されます。 「sdp_始め」: このメモのAppendix C.6.4.1では、定義されます。 「アイデンティティ」: このメモのAppendix C.6.4.1では、定義されます。
Lazzaro & Wawrzynek Standards Track [Page 45] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[45ページ]。
11.3. asc Media Type Registration
11.3. ascメディアType Registration
This section registers "asc" as a subtype for the "audio" media type. We register this subtype to support the remote transfer of the "config" parameter of the mpeg4-generic media type [RFC3640] when it is used with mpeg4-generic mode rtp-midi (registered in Appendix 11.2 above). We explain the mechanics of using "audio/asc" to set the config parameter in Section 6.2 and Appendix C.6.5 of this document.
このセクションは「オーディオ」メディアタイプのための「副-タイプ」として"asc"を登録します。 私たちは、それがmpeg4-ジェネリックモードrtp-ミディ(上のAppendix11.2では、登録される)と共に使用されるとき、mpeg4-ジェネリックメディアタイプ[RFC3640]の「コンフィグ」パラメタのリモート転送をサポートするためにこの「副-タイプ」を登録します。 私たちはこのドキュメントのセクション6.2とAppendix C.6.5にコンフィグパラメタをはめ込むのに「オーディオ/asc」を使用する整備士について説明します。
Note that this registration is a new subtype registration and is not an addition to a repository defined by MPEG-related memos (such as [RFC3640]). Also note that this request for "audio/asc" does not register parameters, and does not request the creation of a repository.
この登録が新しい「副-タイプ」登録であり、MPEG関連のメモ([RFC3640]などの)で定義された倉庫への追加でないことに注意してください。 また、「オーディオ/asc」を求めるこの要求がパラメタを示さないで、また倉庫の作成を要求しないことに注意してください。
Media type name:
メディア型名:
audio
オーディオ
Subtype name:
Subtypeは以下を命名します。
asc
asc
Required parameters:
必要なパラメタ:
None.
なし。
Optional parameters:
任意のパラメタ:
None.
なし。
Encoding considerations:
問題をコード化します:
The native form of the data object is binary data,
zero-padded to an octet boundary.
データ・オブジェクトのネイティブのフォームはバイナリ・データ、八重奏に無そっと歩いている境界です。
Restrictions on usage:
用法における制限:
This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and SMTP.
このタイプはデータ・オブジェクト(ファイルを保存する)転送のために定義されるだけです。 タイプのための最も一般的な輸送は、HTTPとSMTPです。
Security considerations:
セキュリティ問題:
See Section 9 of this memo.
このメモのセクション9を見てください。
Lazzaro & Wawrzynek Standards Track [Page 46] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[46ページ]。
Interoperability considerations:
相互運用性問題:
None.
なし。
Published specification:
広められた仕様:
The audio/asc data object is the AudioSpecificConfig
binary data structure, which is normatively defined in
[MPEGAUDIO].
オーディオ/ascデータ・オブジェクトはAudioSpecificConfigバイナリ・データ構造です。(その構造は[MPEGAUDIO]で標準に定義されます)。
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
MPEG 4 Audio servers and terminals that support
audio/mpeg4-generic RTP streams for mode rtp-midi.
MPEG4Audioサーバとモードrtp-ミディのためにmpeg4オーディオ/ジェネリックRTPストリームをサポートする端末。
Additional information:
追加情報:
None.
なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Intended usage:
意図している用法:
COMMON.
一般的。
Author:
以下を書いてください。
John Lazzaro <lazzaro@cs.berkeley.edu>
ジョン Lazzaro <lazzaro@cs.berkeley.edu 、gt。
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport Working Group delegated
from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
Lazzaro & Wawrzynek Standards Track [Page 47] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[47ページ]。
A. The Recovery Journal Channel Chapters
A。 回復ジャーナルチャンネル章
A.1. Recovery Journal Definitions
A.1。 回復ジャーナル定義
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).
この付録はセクション5における回復ジャーナルbitfield記述(ジャーナルヘッダー構造)、A.9へのAppendices A.2(チャンネルジャーナル章)、およびB.5へのAppendices B.1(システムジャーナル章)で使用される用語とコード化熟語を定義します。
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.
私たちは、回復ジャーナルがRTPパケットのジャーナル部に一連番号I(「パケットI」)であって、一連番号Cでトップレベル回復ジャーナルヘッダーのCheckpoint Packet Seqnum分野が前のパケットについて言及すると思います(例外は私がケースに入れる自己参考のC=です)。 別の方法で述べられない場合、アルゴリズムが計算のための16ビットの一連番号と法2^32演算における計算に32ビットの拡張配列番号で法2^16演算を使用すると思われます。
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.
いくつかのbitfieldコード化熟語が一貫した意味論と共に回復ジャーナルシステム中に現れます。 ほとんどの回復ジャーナル要素が「S」(単一のパケット損失)ビットで始まります。 Sビットは、受信機が単一のパケットの損失のよくある例における回復ジャーナル階層構造を通して効率的に分析されるのを助けるように設計されています。
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.
原則として、Sビットを1に設定しなければなりません。 しかしながら、パケットIの回復ジャーナル要素がパケットIのMIDI指揮班に保存されたコマンドに関してデータを暗号化するなら、例外は適用されます--1。 この場合、回復ジャーナル要素のSビットを0に設定しなければなりません。 また、回復ジャーナル要素でSビットを0に設定するなら、それを含むすべての、よりハイレベルの回復ジャーナル要素が0に設定されるSビットを持たなければなりません、トップレベル回復ジャーナルヘッダーを含んでいて。
Other consistent bitfield coding idioms are described below:
他の一貫したbitfieldコード化熟語は以下で説明されます:
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 R旗に噛み付きました。 Rフラグビットは今後の使用のために予約されます。 SendersはRビットを0に設定しなければなりません。 受信機はR噛み付いている値を無視しなければなりません。
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.
o LENGTH分野。 すべての分野がLENGTH(LENと異なるとしての)コードをそれを含む構造の八重奏の数と命名しました、それが住んでいるヘッダーとそれの下のすべての階層レベルを含んでいて。 構造がLENGTH分野を含んでいるなら、受信機は、構文解析の間、構造の内部の形式に関して知識を利用するより構造の先をむしろ進むのにLENGTH分野価値を使用しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 48] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[48ページ]。
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 チェックポイント歴史。 回復ジャーナルのチェックポイント歴史はIを通したパケットCのMIDI指揮班の連結です--1。 パケットIのためのMIDI指揮班の最終的なコマンド--1は最新のコマンドであると考えられます。 パケットCのためのMIDI指揮班における最初のコマンドは最も古いコマンドです。 コマンドXがコマンドYほど最近でないなら、「Yの前」のときに、Xがあると考えられます。 コマンドのないチェックポイント歴史が空であると考えられます。 チェックポイント歴史がパケットI(回復ジャーナルを含むパケット)のMIDI指揮班を決して含まないので、チェックポイント歴史はC=私であるなら、定義上空しいです。
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 セッション歴史。 回復ジャーナルのセッション歴史はパケットIまでのセッションの最初のパケットからのMIDI指揮班の連結です--1。 コマンド新鮮と歴史空虚の定義はチェックポイント歴史のそれらに続きます。 セッション歴史がパケットIのMIDI指揮班を決して含まないので、セッションにおける、最初のパケットのセッション歴史は定義上空しいです。
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 終わっているか未完成のコマンド。 MIDIコマンドのすべての八重奏がセッション歴史に現れるなら、コマンドは終わっていると定義されます。 すべての八重奏ではなく、コマンドのいくつかがセッション歴史に現れるなら、コマンドは未完成であると定義されます。 SysExコマンドのセグメントがいくつかのRTPパケットに現れるなら、未完成のコマンドは起こります。 例えば、SysExコマンドが3つのセグメントとしてコード化されるなら、パケットKのセグメント1、パケットK+1のセグメント2、およびセグメント3がパケットK+2にある状態で、パケットK+1とK+2のためのセッション歴史はコマンドの未完成のバージョンを含んでいます。 歴史がコマンドのためのキャンセルサブリストを含んでいるなら、セッション歴史は取り消されたSysExコマンドの終わっているバージョンを含んでいます。
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 州コマンドをリセットしてください。 リセット州(RS)命令は初期化している"powerup"状態にレンダラーをリセットしました。 RSコマンドは以下の通りです。 システムは(0xFF)をリセットしました、ジェネラルミディシステム、可能にする、(0xF0 0x7E 0xcc、0×09、0×01 0xF7、)、2システムが可能にするジェネラルミディ、(0xF0 0x7E 0xcc、0×09、0×03 0xF7、)、ジェネラルミディシステムが無効にする、(0xF0 0x7E 0xcc、0×09、0×00 0xF7、)、dlをつけてください、そして、(0xF0 0x7E 0xcc 0x0A0×01 0xF7)dlをオフにしてください(0xF0 0x7E 0xcc 0x0A0×02 0xF7)。 subrenderパラメタトークン値(付録C.6.2)とIETF標準化過程文書の登録証明書は追加RSコマンドを指定するかもしれません。
o Active commands. Active command are MIDI commands that do not
appear before a Reset State command in the session history.
o 活発なコマンド。 活発なコマンドはセッション歴史におけるReset州コマンドの前に現れないMIDIコマンドです。
Lazzaro & Wawrzynek Standards Track [Page 49] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[49ページ]。
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 N活発なコマンド。 N活発なコマンドはセッション歴史における以下のコマンドの1つの前に現れないMIDIコマンドです: 123-127(All Notes Off意味論がある数)か120(すべてのSound Off)のMIDI Control Change番号、およびどんなReset州コマンド。
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 C活発なコマンド。 C活発なコマンドはセッション歴史における以下のコマンドの1つの前に現れないMIDIコマンドです: MIDI Control Change No.121(リセットAll Controllers)とどんなReset州も命令します。
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:
o 最も古い1番目の注文規則。 いくつかの回復ジャーナル章が要素のリストを含んでいます。(そこでは、それぞれの要素がセッション歴史に現れるMIDIコマンドに関連しています)。 多くの場合、章定義は、「最も古い最初の注文規則」に従ってリスト要素が注文されるのを必要とします。 以下では、私たちが標準にこの規則を定義します:
Elements associated with the most recent command in the session
history coded in the list MUST appear at the end of the list.
リストでコード化されたセッション歴史における最新のコマンドに関連しているElementsはリストの終わりに現れなければなりません。
Elements associated with the oldest command in the session
history coded in the list MUST appear at the start of the list.
リストでコード化されたセッション歴史で最も古いコマンドに関連しているElementsはリストの始めに現れなければなりません。
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 パラメタシステム。 0-127コントローラ数のスペースを広げるために2セットの1万6384のパラメタを提供するMIDIの特徴。 それぞれが1万6384のパラメタを供給するRegistered Parameter Names(RPN)システムとNon登録されたParameter Names(NRPN)システム。
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).
o パラメタシステムトランザクション。 パラメタシステムトランザクションを形成する一連のControl ChangeコマンドでRPNsとNRPNsの値を変えます。 正準なトランザクションはパラメタ番号(NRPNsのコントローラNo.99と98、RPNsのコントローラNo.101と100)を設定する2つのControl Changeコマンドで始まります。 トランザクションはパラメタ値を設定するData Entry(コントローラNo.6と38)、Data Increment(コントローラNo.96)、およびData Decrement(コントローラNo.97)規制Change命令の特殊活字の数字を続行します。 トランザクションはヌルパラメタを指定する(99、98)の2番目の組か(101、100)規制Change命令で終わります(MSBは0x7Fを評価します、LSB値の0x7F)。
Lazzaro & Wawrzynek Standards Track [Page 50] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[50ページ]。
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".
正準なトランザクション系列のいくつかの異形が可能です。 大部分はヌルパラメタ以外のパラメタを指定するかもしれません一般的に(99、98)の端末の組か(101、100)コントロールChangeが、命令する。 この場合、コマンド組は、最初のトランザクションを終えて、2番目のトランザクションを始めます。 コマンド組は両方のトランザクションの一部であると考えられます。 この異形は、[MIDI]で法的であって、お勧めです。 私たちは「タイプ1異形」とこの異形を呼びます。
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.
それほど一般的にない、MSB(99か101)かLSB(98か100)が(99、98)について命令しないか、または(101、100)コントロールChange組は省略されるかもしれません。
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".
MSBコマンドが省略されるなら、トランザクションはセッション歴史に現れるコントローラNo.99か101に最新のC活発なControl ChangeコマンドのMSB値を使用します。 私たちは「タイプ2異形」とこの異形を呼びます。
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].
LSBコマンドが省略されるなら、LSB値0x00は想定されます。 私たちは「タイプ3異形」とこの異形を呼びます。 タイプ2とタイプ3つの異形は、法的であると定義されますが、[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].
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 51] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 51] RFC 4695 RTP Payload Format for MIDI November 2006
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).
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 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.
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."
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.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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
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
Lazzaro & Wawrzynek Standards Track [Page 52] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 52] RFC 4695 RTP Payload Format for MIDI November 2006
fields MUST be set to 0. Below, we define exceptions to this default condition.
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 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, 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.
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.
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
A.3. Chapter C: MIDI Control Change
Figure A.3.1 shows the format for Chapter C.
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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 53] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 53] RFC 4695 RTP Payload Format for MIDI November 2006
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 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.3.1. Log Inclusion Rules
A controller log encodes information about a particular Control Change command in the session history.
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.
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:
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].
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.
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 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).
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
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
Lazzaro & Wawrzynek Standards Track [Page 54] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 54] RFC 4695 RTP Payload Format for MIDI November 2006
list. However, the list MAY omit the controller log for the
most recent active command for the other number in the pair.
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.
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.
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.
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.
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.
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
A.3.2. Controller Log Format
Figure A.3.2 shows the controller log structure of Chapter C.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 55] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 55] RFC 4695 RTP Payload Format for MIDI November 2006
A log encodes recovery information using one of the following tools: the value tool, the toggle tool, or the count tool.
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).
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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.
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).
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).
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
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
Lazzaro & Wawrzynek Standards Track [Page 56] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 56] RFC 4695 RTP Payload Format for MIDI November 2006
toggle tool lets receivers detect this lost "off" command, but the value tool does not.
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.
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.
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
A.3.3. Log List Coding Rules
In this section, we describe the organization of controller logs in the Chapter C log list.
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.
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]).
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).
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 57] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 57] RFC 4695 RTP Payload Format for MIDI November 2006
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.
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].
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).
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.
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.
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.
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.
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.
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 58] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 58] RFC 4695 RTP Payload Format for MIDI November 2006
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.
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.
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 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).
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.
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.
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.
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.
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.
Lazzaro & Wawrzynek Standards Track [Page 59] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro & Wawrzynek Standards Track [Page 59] RFC 4695 RTP Payload Format for MIDI November 2006
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.
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.
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.
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.
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
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.
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:
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)
o データEntry MSB(6)o Data Entry LSB(38)o Data Increment(96)o Data Decrement(97)o Nonによって登録されたParameter Number(NRPN)LSB(98)o Nonによって登録されたParameter Number(NRPN)MSB(99)o Registered Parameter Number(RPN)LSB(100)o Registered Parameter Number(RPN)MSB(101)
Lazzaro & Wawrzynek Standards Track [Page 60] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[60ページ]。
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.
章C コントローラログでパラメタシステムトランザクションの一部である規制Change命令をコード化してはいけません。 代わりに、これらのコマンドは章M、Appendix A.4で定義されたMIDI Parameter章でコード化されます。
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.
しかしながら、章Mで汎用コントローラとして記載されたコントローラを使用する(すなわち、パラメタシステムトランザクションの外)Control Changeコマンドをコード化してはいけません。
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.
代わりに、コントローラは章C コントローラログでコード化されます。 コントローラログはAppendix A.3.2とA.3.3に述べられたコード化規則に従います。 章Cでコード化されると、コード化のための規則はLSB、MSBコントローラ中でAppendix A.3.1を定義して、組(6、38)に適用するのによる(99、98)、および(101、100)を対にしました。
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.
コントローラNo.6、38、または96-101のための活発なControl Changeコマンドがチェックポイント歴史に現れて、これらのコマンドが汎用コントローラとして使用されるなら、章のCコントローラのエントリーが記載するとき、これらのコントローラ番号のための最新の汎用コマンドインスタンスは現れなければなりません。
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.
同じくらいのパラメタシステムコントローラと汎用コントローラが流れるとき、MIDI構文は、ソースがコントローラ6、38、96、および97を使用することを許可します。 RTP MIDI送付者は、これらのコントローラ番号のためにストリームにおける、コマンドのプレースメントに注意することによってそれぞれのControl Changeコマンドの役割を推論しなければならなくて、章Cか章Mにおけるコマンドをコード化するのにこの情報を使用しなければなりません、適宜。
Specifically, active Control Change commands for controllers 6, 38, 96, and 97 act in a general-purpose way when
明確に、コントローラ6、38、96、および97のための活発なControl Changeコマンドはいつを汎用方法で活動させるか。
o no active Control Change commands that set an RPN or NRPN
parameter number appear in the session history, or
o またはRPNかNRPNパラメタ番号を設定するどんな活発なControl Changeコマンドもセッション歴史に現れない。
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 またはセッション歴史におけるRPNを設定する最新の活発なControl ChangeコマンドかNRPNパラメタ番号がヌルパラメタをコード化する、(MSBは0x7Fを評価します、LSB値の0x7F)。
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).
o コントローラNo.121(リセットAll Controllers)のためのControl Changeコマンドは最近、RPNかNRPNパラメタ番号を設定するすべての活発なControl Changeコマンドよりセッション歴史に現れます(詳細に関して[RP015]を見てください)。
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.
最終的に、私たちは、排他的に[MIDI]の推薦の後をつけるMIDIソースがパラメタシステムコントローラとしてNo.98-101を使用することに注意します。 あるいはまた、MIDIソースは、汎用コントローラとして排他的に98-101を使用して、能力を失うかもしれません。絶え間なくパラメタシステムトランザクションを実行してください。
Lazzaro & Wawrzynek Standards Track [Page 61] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[61ページ]。
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.
[MIDI]の言葉を借りて言えば、コントローラ98-101の汎用使用は標準的でないコントローラ課題を構成します。 大部分として、本当の世界MIDIソースはコントローラNo.98-101に標準のコントローラ課題を使用します、SHOULDが、これらのコントローラがパラメタシステムコントローラとして務めると仮定するRTP MIDI送付者、MIDIソースが汎用方法でコントローラNo.98-101を使用するのを知らない場合。
A.4. Chapter M: MIDI Parameter System
A.4。 章M: ミディパラメタシステム
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.
この付録を読む前に、読者は「Cアクティブである」「パラメタシステム」、「パラメタシステムトランザクション」、および「開始しているパラメタシステムトランザクション」のためのAppendix A.1定義を見直したがっているかもしれません。
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.
章MはRegistered Parameter Number(RPN)とNonによって登録されたParameter Number(NRPN)値のためにパラメタシステムトランザクションを保護します。 図A.4.1は章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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ|Q| 未定| リストを登録してください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.1 -- Top-level Chapter M format
図A.4.1--トップレベルの章M 形式
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.
章Mは2八重奏のヘッダーと共に始まります。 Pヘッダービットが1に設定されるなら、1八重奏の分野はヘッダーに続きます、7ビットのPENDING値とその関連Qビットをコード化して。
The 10-bit LENGTH field codes the size of Chapter M and conforms to semantics described in Appendix A.1.
10ビットのLENGTH分野は、章Mのサイズをコード化して、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.
章Mはゼロか、より可変長のパラメタログのリストで終わります。 付録A.4.2はパラメタログのbitfield書式を定義します。 付録A.4.1はログ・リストの包含意味論を定義します。
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.
Appendix A.4.1で定義された規則が、1つ以上のパラメタログがリストに現れるのを必要とするなら、チャンネルジャーナルは章Mを含まなければなりません。
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
チェックポイント歴史のパラメタシステムトランザクションにかかわる最新のC活発なControl Changeコマンドが含んでいるなら、チャンネルジャーナルも章Mを含まなければなりません。
o an RPN MSB (101) or NRPN MSB (99) controller, or
o またはRPN MSB(101)かNRPN MSB(99)コントローラ。
Lazzaro & Wawrzynek Standards Track [Page 62] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[62ページ]。
o an RPN LSB (100) or NRPN LSB (98) controller that completes the
coding of the null parameter (MSB value 0x7F, LSB value 0x7F).
o ヌルパラメタ(MSBは0x7Fを評価します、LSB値の0x7F)のコード化を完了するRPN LSB(100)かNRPN LSB(98)コントローラ。
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.
セッション歴史のパラメタシステムトランザクションにかかわる最新のC活発なControl ChangeコマンドがRPN MSBかNRPN MSBコントローラのためのものであるなら、Pヘッダービットを1に設定しなければなりません、そして、PENDING分野(そして、関連Qビット)は章のMヘッダーに続かなければなりません。 さもなければ、Pヘッダービットを0に設定しなければなりません、そして、PENDING野原とQビットは章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.
PENDINGがNRPN MSBをコード化するなら、Qビットを1に設定しなければなりません。 PENDINGがRPN MSBをコード化するなら、Qビットを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:
EヘッダービットはMIDIストリームの経常取引状態をコード化します。 E=1であるなら、開始しているトランザクションは進行しています。 以下では、私たちがEヘッダービットを設定するための規則を定義します:
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 どんなC活発なパラメタシステムトランザクションControl Changeコマンドもセッション歴史に現れないなら、Eビットを0に設定しなければなりません。
o If the P header bit is set to 1, the E bit MUST be set to 0.
o Pヘッダービットが1に設定されるなら、Eビットを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 セッション歴史における最新のC活発なパラメタシステムトランザクションControl ChangeコマンドがNRPN LSBかRPN LSBコントローラ番号のためのものであり、このコマンドがヌルパラメタのコード化を完了するために行動するなら(MSBは0x7Fを評価します、LSB値の0x7F)、Eビットを0に設定しなければなりません。
o Otherwise, an initiated transaction is in progress, and the E
bit MUST be set to 1.
o さもなければ、開始しているトランザクションは進行しています、そして、Eビットを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).
U、W、およびZヘッダービットはリストのすべてのパラメタログによって共有される特性をコード化します。 これらの特性が設定されるなら、パラメタログは改良された効率でコード化されるかもしれません(私たちは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.
デフォルトで、U、W、およびZビットを0に設定しなければなりません。 すべてのパラメタがリストコードRPNパラメタにログインするなら、Uビットは1に設定されるかもしれません。 すべてのパラメタがリストコードNRPNパラメタにログインするなら、Wビットは1に設定されるかもしれません。 リストのすべてのRPNとNRPNログのパラメタ番号が範囲0-127にあるなら(その結果、0のMSB値を持ってください)、Zビットは1に設定されるかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 63] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[63ページ]。
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).
[RP015]が、未定のParameter SystemトランザクションがコントローラNo.121のためのControl Changeコマンドで閉じられると指定するので(All Controllersをリセットしてください)Cアクティブな意味論が先行のパラグラフに現れることに注意してください。
A.4.1. Log Inclusion Rules
A.4.1。 ログ包含規則
Parameter logs code recovery information for a specific RPN or NRPN parameter.
パラメタログは特定のRPNかNRPNパラメタのための回復情報をコード化します。
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.
パラメタのために開始しているトランザクションの一部を形成する活発なControl Changeコマンドがチェックポイント歴史に現れるなら、パラメタログはリストに現れなければなりません。
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.
チェックポイント歴史がトランザクションを終えるために行動するコントローラNo.98-101のためのトランザクションControl Changeコマンドを含むだけであるなら、この規則への例外は適用されます。 この場合、パラメタのためのログはリストから省略されるかもしれません。
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.
パラメタのために開始しているトランザクションの一部を形成する活発なControl Changeコマンドがセッション歴史に現れるなら、ログはリストに現れるかもしれません。 さもなければ、パラメタのためのログはリストに現れてはいけません。
Multiple logs for the same RPN or NRPN parameter MUST NOT appear in the log list.
同じRPNかNRPNパラメタのための複数のログがログ・リストに現れてはいけません。
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.
パラメタログ・リストは最も古い最初の注文規則(Appendix A.1では、定義される)に従わなければなりません、「パラメタトランザクション」という句が「コマンド」という規則定義における言葉を置き換えていて。
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.
RPNかNRPNのヌルパラメタ(LSBは0x7Fと等しいです、MSB=0x7F)に関連しているパラメタログはログ・リストに現れてはいけません。 章MはEヘッダービット(図A.4.1)とヌルパラメタ意味論をコード化するよう規則に命令するログ・リストを使用します。
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.
[RP015]が、未定のParameter SystemトランザクションがコントローラNo.121のためのControl Changeコマンドでリセットされないと指定するので(All Controllersをリセットしてください)「アクティブな」意味論(「Cアクティブな」意味論よりむしろ)が先行のパラグラフに現れることに注意してください。 しかしながら、従う規則はCアクティブな意味論を使用します、取引方法自体の保護に関係があって、[RP015]が、Reset All Controllersが進行中で取引を取り決めるために行動すると指定するので。
Lazzaro & Wawrzynek Standards Track [Page 64] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[64ページ]。
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
多くの場合、パラメタはRPNとNRPNのためにchに決して割り当てられないで、パラメタ(付録C.2.3)がリストから省略されるかもしれないということであるパラメタを登録します。 例外は適用されます。
o the log codes the most recent initiated transaction in the
session history, and
o そしてログがセッション歴史の最新の開始しているトランザクションをコード化する。
o a C-active command that forms a part of the transaction appears
in the checkpoint history, and
o そしてトランザクションの一部を形成するC活発なコマンドがチェックポイント歴史に現れる。
o the E header bit for the top-level Chapter M header (Figure
A.4.1) is set to 1.
o トップレベルの章Mのヘッダー(図A.4.1)Eヘッダービットは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.
この場合、パラメタのためのログはリストに現れなければなりません。 このログは、トランザクションが進行していることを損失から回収される受信機に知らせます、受信機が正しく損失イベントに続くRPNかNRPN Control Changeコマンドを解釈できるように。
A.4.2. Log Coding Rules
A.4.2。 ログコード化規則
Figure A.4.2 shows the parameter log structure of Chapter M.
図A.4.2は章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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 分野… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.2 -- Parameter log format
図A.4.2--パラメタログ形式
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).
ログはデフォルトサイズ(図A.4.2に示されるように)が3つの八重奏であるヘッダーと共に始まります。 Qヘッダービットが0に設定されるなら、ログはRPNパラメタをコード化します。 Q=1であるなら、ログはNRPNパラメタをコード化します。 7ビットのPNUM-MSBとPNUM-LSB分野は、コントローラ99と98(NRPNsのための)か101と100(RPNsのための)のためにパラメタ番号をコード化して、Control Changeコマンドデータ値を反映します。
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.
J、K、L、M、およびNヘッダービットは、ログのために、目次(TOC)を形成して、ヘッダーに続く修理サイズの分野の存在を示します。 1に設定されるヘッダービットは丸太のままで分野の存在をコード化します。 分野の注文はTOCで丸太のままでヘッダービットに命令に従います。 付録A.4.2.1-2はそれぞれのTOCヘッダービットに関連している分野を定義します。
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.
TとVヘッダービットは、パラメタログに関して情報をコード化しますが、TOCの一部ではありません。 セットTかVビットがどんなパラメタログ分野の存在も示しません。
Lazzaro & Wawrzynek Standards Track [Page 65] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[65ページ]。
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.
Appendix A.4.1の規則が、与えられたパラメタのためのログが章Mに載らなければならないと述べるなら、ログは、チェックポイント歴史における、活発なパラメタトランザクションControl Changeコマンドの損失からパラメタを保護するために十分な情報をコード化しなければなりません。
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.
ログによってコード化されたパラメタがchに決して割り当てられないなら、この規則は適用されません。パラメタ(付録C.2.3)。 この場合、送付者は、J、K、L、M、およびN TOCビットを0に設定するのを選ぶかもしれません、分野なしでパラメタログをコード化して。
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.
chに決して割り当てられないパラメタを保護するログが一定の条件の下でREQUIREDであることに注意してください(Appendix A.4.1を見てください)。 ログの目的はトランザクションが進行していることを損失から回収される受信機に知らせることです、受信機が正しく損失イベントに続くRPNかNRPN Control Changeコマンドを解釈できるように。
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.
パラメタログは2つのツールをパラメタ保護に提供します: 値のツールとカウントツール。 パラメタの意味論によって、送付者は、与えられたパラメタを保護するのにどちらかのツールか、両方のツールも、ツールも使用しないかもしれません。
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.
値のツールは受信機がRPNかNRPNパラメタの現行価値を決定するのに使用するかもしれない情報をコード化します。 値のツール、Vヘッダービットがそうしなければならないパラメタログ用途がセットであるなら、1、およびJ、K、L、およびTOCビットが設定しなければならないMを設定するためにAppendices A.4.2.1で定義された意味論に続かれてください。 パラメタログが0、J、K、L、およびM TOCへのまたビットを設定しなければならないセットが0であったに違いないなら値のツール、Vビットを使用しないなら。
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.
カウントツールはRPNかNRPNパラメタのためにトランザクションの数をコード化します。 パラメタログがカウントツールを使用するなら、Tヘッダービットを1に設定しなければなりません、そして、N TOCビットを設定するためにAppendices A.4.2.2で定義された意味論に従わなければなりません。 パラメタログがカウントツールを使用しないなら、TビットとN TOCビットを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.
送付者が値(V)を使用するならVとTが設定されることに注意するか、または進行中ベースに関するログのために(T) ツールを数えてください。 したがって、Nが0と等しくてもK J==L=M=0、およびTが設定されても、Vは設定されるかもしれません。
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).
多くの場合、1つのタイプ(RPNとNRPN)にはログ・リストでコード化されたすべてのパラメタがあります、そして、すべてのパラメタ番号が範囲0-127にあります。 Appendix A.4.1、送付者5月の信号のこの状態について説明するので、トップレベルの章Mを設定することによって、1(制限された範囲をコード化する)とUかWビットを1に設定することによって(パラメータの型をコード化する)、ヘッダーはZに噛み付きました。
Lazzaro & Wawrzynek Standards Track [Page 66] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[66ページ]。
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.
トップレベルの章Mであるなら、ヘッダーはZ=1とU=1かW=1のどちらかをコード化して、パラメタログ・リストのすべてのログが変更されたヘッダー形式を使用しなければなりません。 この変更は2八重奏のヘッダーをもたらすために図A.4.2で見せられたbitfieldのビット8-15を削除します。 W、削除されたPNUM-MSBとQ分野の値はUから推論されたかもしれません、そして、Zは値に噛み付きました。
A.4.2.1. The Value Tool
A.4.2.1。 値のツール
The value tool uses several fields to track the value of an RPN or NRPN parameter.
値のツールは、RPNかNRPNパラメタの値を追跡するのにいくつかの分野を使用します。
The J TOC bit codes the presence of the octet shown in Figure A.4.3 in the field list.
J TOCビットは分野リストに図A.4.3に示された八重奏の存在をコード化します。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-MSB |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |X| エントリー-MSB| +-+-+-+-+-+-+-+-+
Figure A.4.3 -- ENTRY-MSB field
図A.4.3--ENTRY-MSB分野
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.
7ビットのENTRY-MSB分野はログパラメタに関してトランザクションに現れるセッション歴史のコントローラNo.6のための最新の活発なControl Changeコマンド(データEntry MSB)のデータ値をコード化します。
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.
ENTRY-MSBによってコード化されたコマンドがコントローラ121のための最新のControl Changeコマンドに先行するなら(All Controllersをリセットしてください)、セッション歴史にXビットを1に設定しなければなりません。 さもなければ、Xビットを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.
コントローラNo.6のための活発なControl Changeコマンドがチェックポイント歴史に現れるなら、値のツールを使用するパラメタログはENTRY-MSB分野を含まなければなりません。
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].
[RP015]が、コントローラ121(リセットAll Controllers)のためのControl ChangeコマンドがRPNとNRPN値をリセットしないで、またその結果、Xビットが[RP015]に従うMIDIシステムのために回復の役割を果たさないと指定することに注意してください。
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.
しかしながら、あるレンダラー(DLS2など[DLS2]の)は、あるRPN値がReset All Controllersのいくつかの用途のためにリセットされると指定します。 Xビット(そして、この付録のこの種の他のbitfieldの特徴)はこのタイプのレンダラーのために回復における役割を果たします。
Lazzaro & Wawrzynek Standards Track [Page 67] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[67ページ]。
The K TOC bit codes the presence of the octet shown in Figure A.4.4 in the field list.
K TOCビットは分野リストに図A.4.4に示された八重奏の存在をコード化します。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| ENTRY-LSB |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |X| エントリー-LSB| +-+-+-+-+-+-+-+-+
Figure A.4.4 -- ENTRY-LSB field
図A.4.4--ENTRY-LSB分野
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.
7ビットのENTRY-LSB分野はログパラメタに関してトランザクションに現れるセッション歴史のコントローラNo.38のための最新の活発なControl Changeコマンド(データEntry LSB)のデータ値をコード化します。
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.
ENTRY-LSBによってコード化されたコマンドがコントローラ121のための最新のControl Changeコマンドに先行するなら(All Controllersをリセットしてください)、セッション歴史にXビットを1に設定しなければなりません。 さもなければ、Xビットを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.
原則として、コントローラNo.38のための活発なControl Changeコマンドがチェックポイント歴史に現れるなら、値のツールを使用するパラメタログはENTRY-LSB分野を含まなければなりません。 しかしながら、ENTRY-LSBに関連しているControl Changeコマンドがセッション歴史のログパラメタに関してトランザクションに現れるコントローラNo.6(データEntry MSB)のためのControl Changeコマンドに先行するなら、ENTRY-LSB野原はパラメタログに現れてはいけません。
The L TOC bit codes the presence of the octets shown in Figure A.4.5 in the field list.
L TOCビットは分野リストに図A.4.5に示された八重奏の存在をコード化します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|X| A-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|X| 1ボタンです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.5 -- A-BUTTON field
図A.4.5--1BUTTONの分野
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.
14ビットのA-BUTTON分野はセッション歴史のログパラメタに関してトランザクションに現れるコントローラNo.96と97(データIncrementとData Decrement)のための活発なControl Changeコマンドの数のカウントをコード化します。
Lazzaro & Wawrzynek Standards Track [Page 68] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[68ページ]。
The M TOC bit codes the presence of the octets shown in Figure A.4.6 in the field list.
TOCが噛み付いたMは分野リストに図A.4.6に示された八重奏の存在をコード化します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| C-BUTTON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|R| C-ボタン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4.6 -- C-BUTTON field
図A.4.6--C-BUTTON分野
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.
14ビットのC-BUTTON分野には、A-BUTTONと同じ意味論があります、セッション歴史でコントローラ121(リセットAll Controllers)のための最新のControl Changeコマンドに先行するData IncrementとData Decrement Control Changeコマンドが数えられないのを除いて。
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.
A-BUTTONとC-BUTTONの両方に関しては、セッション歴史でコントローラNo.6(データEntry MSB)かログパラメタに関してトランザクションに現れる38(データEntry LSB)のためのControl Changesコマンドに先行するなら、Data IncrementとData Decrement Control Changeコマンドは数えられません。
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).
A-BUTTONとC-BUTTON分野は解釈されて、符号のない整数、および関連づけられたGビットとして分野が整数のサインをコード化するという(Gは正数のための0かゼロと等しいです、ネガのためのG=1)ことです。
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.
カウント値を計算して、コード化して、カウント値を0に初期化して、それぞれのためにData Incrementコマンドに資格を与えながら1を加えて、各資格を得るために1を引き算するために、Data Decrementは命令します。 それぞれ後に、加えるか、引いてください、そして、またはカウントの大きさを16383に制限してください。 Gビットはカウントのサインをコード化します、そして、A-BUTTONかC-BUTTON分野はカウントの大きさをコード化します。
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-BUTTON分野において、最新の適切なData IncrementかData Decrementコマンドがセッション歴史でコントローラ121(リセットAll Controllers)のための最新のControl Changeコマンドに先行するなら、A-BUTTON分野に関連しているXビットを1に設定しなければなりません。 さもなければ、Xビットを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:
コントローラNo.96か97のための活発なControl Changeコマンドがチェックポイント歴史に現れるなら、値のツールを使用するパラメタログはA-BUTTONとC-BUTTON分野を含まなければなりません。 しかしながら、コード化効率を高めるために、この規則には、いくつかの例外があります:
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.
o ログがA-BUTTON分野を含んで、A-BUTTON分野のXビットが1に設定されるなら、C-BUTTON分野(そして、その関連RとGビット)はログから省略されるかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 69] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[69ページ]。
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.
o ログがA-BUTTON分野を含んで、A-BUTTONとC-BUTTON分野(そして、それらの関連Gビット)が同じ値をコード化するなら、C-BUTTON分野(そして、その関連RとGビット)はログから省略されるかもしれません。
A.4.2.2. The Count Tool
A.4.2.2。 カウントツール
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.
カウントツールはRPNかNRPNパラメタのためにトランザクションの数を追跡します。 N TOCビットは分野リストに図A.4.7に示された八重奏の存在をコード化します。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|X| COUNT |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |X| カウント| +-+-+-+-+-+-+-+-+
Figure A.4.7 -- COUNT field
図A.4.7--COUNT分野
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.
COUNTが数をコード化する7ビットはログパラメタのためのセッション歴史に現れるトランザクションを開始しました。 1つ以上の活発なControl Changeコマンドを含んでいるなら、開始しているトランザクションは数えられます、パラメタトランザクションを開始するコントローラ98-101のためのコマンドを含んでいて。
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.
最新の数えられたトランザクションがセッション歴史でコントローラ121(リセットAll Controllers)のための最新のControl Changeコマンドに先行するなら、COUNT分野に関連しているXビットを1に設定しなければなりません。 さもなければ、Xビットを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.
トランザクション勘定は実行された法128です。 変動回数は、セッションの始めの0に設定されて、Reset州コマンド(付録A.1)がセッション歴史に現れるときはいつも、0にリセットされます。
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.
変動回数(法128)を増加する活発なコマンドがチェックポイント歴史に現れるなら、カウントツールを使用するパラメタログはCOUNT分野を含まなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 70] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[70ページ]。
A.5. Chapter W: MIDI Pitch Wheel
A.5。 章W: ミディ大歯車
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.
CアクティブなMIDI Pitch Wheel(0xE)コマンドがチェックポイント歴史に現れるなら、チャンネルジャーナルは章Wを含まなければなりません。 図A.5.1は章Wのために書式を示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| FIRST |R| SECOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| 1番目|R| 2番目| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.5.1 -- Chapter W format
図A.5.1--章W 形式
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.
章には、16ビットの固定サイズがあります。 FIRSTとSECOND分野は、1つの番目ものの7ビットの値とセッション歴史で、最新の活発なPitch Wheelコマンドの2番目のデータ八重奏です。
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).
章WがC活発なコマンドをコード化して、その結果、C活発でない活発なコマンドはコード化しないことに注意してください(章包含テキストの説明に関してこの点でAppendix A.1の持続する第2パラグラフを見てください)。
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.
[RP015]が、コントローラNo.121(リセットAll Controllers)のためのControl ChangeコマンドがPitch Wheel値を0にリセットするために行動すると宣言するので、章Wは「アクティブですが、Cアクティブでない」コマンドをコード化しません。 章Wが「アクティブですが、Cアクティブでない」コマンドをコード化するなら、Reset All Controllersコマンドに続く修理操作は聞き古したPitch Wheel値で不当にストリームを修理するかもしれないでしょうに。
A.6. Chapter N: MIDI NoteOff and NoteOn
A.6。 第N章: ミディNoteOffと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.
この付録では、私たちは、NoteOnが、速度がNoteOffコマンドであるとゼロで命令すると考えます。 この付録を読む前に、読者は「N活発なコマンド」のAppendix A.1定義を見直したがっているかもしれません。
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.
第N章はNoteOnの間を行き来するストリームにおける注意コマンドと特定の注意番号のためのNoteOffコマンドを完全に保護します。 しかしながら、まれなアプリケーションでは、複数の重なっているNoteOnコマンドが注意番号の弁護に出廷するかもしれません。 Appendix A.7で説明された章Eは、これらのストリームを完全に保護するために章のNを増大させます。
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.
NアクティブなMIDI NoteOn(0×9)かNoteOff(0×8)コマンドがチェックポイント歴史に現れるなら、チャンネルジャーナルは第N章を含まなければなりません。 図A.6.1は第N章のために書式を示しています。
Lazzaro & Wawrzynek Standards Track [Page 71] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[71ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| レン| 安値| 高値|S| NOTENUM|Y| 速度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| NOTENUM|Y| 速度| .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OFFBITS| OFFBITS| .... | OFFBITS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.1 -- Chapter N format
図A.6.1--第N章の形式
Chapter N consists of a 2-octet header, followed by at least one of the following data structures:
第N章は少なくとも以下のデータ構造の1つがあとに続いた2八重奏のヘッダーから成ります:
o A list of note logs to code NoteOn commands.
o A NoteOff bitfield structure to code NoteOff commands.
o NoteOnをコード化する注意ログのリストは命令します。o A NoteOff bitfieldはNoteOffコマンドをコードに構造化します。
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.
私たちはAppendix A.6.1のヘッダーbitfield意味論を定義します。 私たちは注意ログ意味論とAppendix A.6.2のNoteOff bitfield意味論を定義します。
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.
1NアクティブなNoteOnかNoteOffがチェックポイント歴史参照で注意番号を命令するなら、注意ログ・リストかNoteOff bitfield構造のどちらかで注意番号をコード化しなければなりません。
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.
注意ログ・リストは最新のチェックポイント歴史外観がN活発なNoteOnコマンドであるすべての注意番号のためのエントリーを含まなければなりません。 NoteOff bitfield構造は最新のチェックポイント歴史外観がN活発なNoteOffコマンドであるすべての注意番号のためのセット・ビットを含まなければなりません。
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.
すべての注意ログとNoteOff bitfieldセット・ビットはセッション歴史の注意番号の最新のNアクティブなNoteOnかNoteOff参照をコード化しなければなりません。
The note log list MUST obey the oldest-first ordering rule (defined in Appendix A.1).
注意ログ・リストは最も古い最初の注文規則(Appendix A.1では、定義される)に従わなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 72] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[72ページ]。
A.6.1. Header Structure
A.6.1。 ヘッダー構造
The header for Chapter N, shown in Figure A.6.2, codes the size of the note list and bitfield structures.
図A.6.2に示された第N章ヘッダーはノートリストとbitfield構造のサイズをコード化します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| LEN | LOW | HIGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| レン| 安値| 高値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.2 -- Chapter N header
図A.6.2--第N章のヘッダー
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.
LEN分野(7ビットの整数値)はノートリストの2八重奏の注意ログの数をコード化します。 ゼロは、LENのための有効値であり、空のノートリストをコード化します。
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.
4ビットのLOWとHIGH分野は注意ログ・リストに従うOFFBITS八重奏の数をコード化します。 LOWとHIGHは符号のない整数値です。 LOW<がHIGHと等しいなら、章にはOFFBITS八重奏があります(HIGH--LOW+1)。 値は対にされます、そして、(LOWは15、HIGH=0と等しいです)(LOW=15、HIGH=1)は空のNoteOff bitfield構造(すなわち、OFFBITS八重奏がない)をコード化します。 他の(LOW>HIGH)値の組はヘッダーに現れてはいけません。
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.
BビットはNoteOff bitfield構造のためのS-ビットの機能性(付録A.1)を提供します。 デフォルトで、Bビットを1に設定しなければなりません。 しかしながら、前のパケット(パケットI--Appendix A.1で定義されるIがある1)のMIDI指揮班がチャンネルのためのNoteOffコマンドを含んでいるなら、Bビットを0に設定しなければなりません。 Bビットが0に設定されるなら、第N章を含むよりハイレベルの回復ジャーナル要素は0に設定されるSビットを持たなければなりません、トップレベルジャーナルヘッダーを含んでいて。
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.
127のLEN値は127か128の注意ログのノートリストの長さをコード化します、LOWとHIGHの値によって。 LENが127、LOW=15、およびHIGH=0と等しいなら、ノートリストは128の注意ログを保持します、そして、NoteOff bitfield構造は空です。 ノートリストが含む127のLOWとHIGH、LENの他の値=コードのために、127はログに注意します。 この場合、章には、LOWが15とHIGH=1と等しいなら、LOW<がHIGHと等しく、OFFBITS八重奏を全く持っていないなら、NoteOff OFFBITS八重奏があります(HIGH--LOW+1)。
Lazzaro & Wawrzynek Standards Track [Page 73] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[73ページ]。
A.6.2. Note Structures
A.6.2。 注意構造
Figure A.6.3 shows the 2-octet note log structure.
図A.6.3は2八重奏の注意ログ構造を見せています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |Y| VELOCITY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| NOTENUM|Y| 速度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.6.3 -- Chapter N note log
図A.6.3--第N章の注意ログ
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.
7ビットのNOTENUM分野はログの注意番号をコード化します。 注意番号はノートリストの複数の注意ログによって表されてはいけません。
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.
7ビットのヴェロシティ分野はセッション歴史の注意番号のための最新のN活発なNoteOnコマンドのために速度値をコード化します。 与えられた注意番号のための複数の重なっているNoteOnsが、Appendix A.7で議論するように章Eを使用することでコード化されるかもしれません。
VELOCITY is never zero; NoteOn commands with zero velocity are coded as NoteOff commands in the NoteOff bitfield structure.
ヴェロシティは決してゼロではありません。 NoteOnは、NoteOffがNoteOff bitfield構造で命令するように速度がコード化されるとゼロで命令します。
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.
注意ログはNoteOnコマンドの実行時間をコード化しません。 しかしながら、YビットはNoteOn実行時間頃に送付者からヒントをコード化します。 Yビットは注意ログが取り戻されたNoteOnコマンドをプレーするか(Y=1)、またはサボるという(Y=0)推薦をコード化します。 非標準の指導に関して[RFC4696]のセクション4.2をYビットの使用に見てください。
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.6.1は章の終わりにOFFBITS八重奏のリストとしてNoteOff bitfield構造を見せています。 NoteOff OFFBITS八重奏は8つの連続したMIDI注意番号のためのNoteOff情報をコード化します、最も多くの重要なビットが最も下位の注意番号を表していて。 最初のOFFBITS八重奏の最も多くの重要なビットは注意No.8*LOWをコード化します。 最後のOFFBITS八重奏の最も多くの重要なビットは注意No.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.
セット・ビットは注意番号のためのNoteOffコマンドをコード化します。 NoteOff bitfield構造のための最も効率的なコード化では、構造の1番目と最後の八重奏は少なくとも1セット・ビットを含んでいます。 第N章がNoteOff速度データをコード化しないことに注意してください。
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
一般的な場合では、回復ジャーナルがコントローラ64(より湿っているPedal(支える))のためのNoteOffコマンドとChange Controlコマンドの相対的なプレースメントをコード化しないことに注意してください。 多くの場合、損失イベントを処理する受信機はこの相対的なプレースメントを推論するかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 74] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[74ページ]。
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.
歴史、流れてください、そして、その結果、NoteOff注意がペダルによって支えられるかどうか決定してください。 そのような決断が可能でないなら、SHOULDが間違える黙りペダルの側面が誤って支えられた注意として支える受信機は不快な(一時的ですが)人工物を生産するかもしれません。
A.7. Chapter E: MIDI Note Command Extras
A.7。 章E: ミディ注意コマンドエキストラ
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.
この付録を読む前に、読者は「N活発なコマンド」のAppendix A.1定義を見直したがっているかもしれません。 この付録では、0の速度があるNoteOnコマンドは64のリリース速度価値があるNoteOffコマンドであると考えられます。
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).
章EはMIDIストリームにめったに現れないMIDI NoteOn(0×9)とNoteOff(0×8)コマンド機能の回復情報をコード化します。受信機は、ストリームのためのいくつかのNoteOnコマンドが介入しているNoteOffなしで注意番号の弁護に出廷する一時的な人工物を減少させるのに章Eを使用します。 また、受信機は、NoteOffリリース速度を使用するストリームのために一時的な人工物を減少させるのに章Eを使用します。 章Eは第N章(付録A.6)でコード化された注意情報を補います。
Figure A.7.1 shows the format for Chapter E.
図A.7.1は章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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| レン|S| NOTENUM|V| カウント/VEL|S| NOTENUM| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V| カウント/VEL| .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.7.1 -- Chapter E format
図A.7.1--章E 形式
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.
章は2八重奏の注意ログの可変長さのリストがあとに続いた1八重奏のヘッダーから成ります。 付録A.7.1は注意ログのためにbitfield書式を定義します。
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).
ログ・リストは少なくとも1つの注意ログを含まなければなりません。 7ビットのLENヘッダーフィールドは1を引いてリストの注意ログの数をコード化します。 この付録で定義された規則が、1つ以上の注意ログがリストに現れるのを必要とするなら、チャンネルジャーナルは章Eを含まなければなりません。 注意ログ・リストは最も古い最初の注文規則(Appendix A.1では、定義される)に従わなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 75] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[75ページ]。
A.7.1. Note Log Format
A.7.1。 注意ログ形式
Figure A.7.2 reproduces the note log structure of Chapter E.
図A.7.2は章Eの注意ログ構造を再生させます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |V| COUNT/VEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| NOTENUM|V| カウント/VEL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.7.2 -- Chapter E note log
図A.7.2--章E 注意ログ
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.
注意ログは7ビットのNOTENUM分野によってコード化されたMIDI注意番号の情報をコード化します。 情報の本質はVフラグビットの価値に依存します。
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.
Vビットが1に設定されるなら、COUNT/VEL分野はセッション歴史に現れる注意番号のための最新のN活発なNoteOffコマンドのためにリリース速度価値をコード化します。
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.
Vビットが0に設定されるなら、COUNT/VEL分野はセッション歴史に現れる注意番号のためのNoteOnの数とNoteOffコマンドの参照カウントをコード化します。
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.
参照カウントはセッションの始めの0に設定されます。 NoteOnコマンドはカウントを1つ増加します。 NoteOffコマンドはカウントを1つ減少させます。 しかしながら、否定的カウントが値であると生成する減少は実行されません。
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.
参照カウントが範囲0-126にあるなら、7ビットのCOUNT/VEL分野はカウントの符号のない整数表現をコード化します。 カウントが127以上であるなら、COUNT/VELは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.
123-127 デフォルトで、Reset州コマンド(付録A.1)がセッション歴史に現れるときはいつも、カウントは0にリセットされます、そして、MIDI Control Changeがコントローラ番号のために命令するときはいつも、(All Notes Off意味論がある数)か120(すべてのSound Off)がセッション歴史に現れます。
A.7.2. Log Inclusion Rules
A.7.2。 ログ包含規則
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.
チェックポイント歴史の注意番号のための最新のNアクティブなNoteOnかNoteOffコマンドが64以外のリリース速度価値があるNoteOffコマンドであるなら、Vビットが1に設定される注意ログは章Eに注意番号に関して載らなければなりません。
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
そして最新のNアクティブなNoteOnかNoteOffが注意のために命令するならチェックポイント歴史の数がNoteOffコマンドである。
Lazzaro & Wawrzynek Standards Track [Page 76] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[76ページ]。
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.
注意番号のための参照カウントが0以上である、Vビットが0に設定される注意ログは章Eに注意番号に関して載らなければなりません。
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.
チェックポイント歴史の注意番号のための最新のNアクティブなNoteOnかNoteOffコマンドがNoteOnコマンドであり、注意番号のための参照カウントが1以上であるなら、Vビットが0に設定される注意ログは章Eに注意番号に関して載らなければなりません。
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.
高々、2つの注意ログが章Eに注意番号に関して載るかもしれません: Vビットがある1つのログがVビットが1に設定される0、および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.
章Eは最大128の注意ログをコード化します。 ログ包含規則が128以上のREQUIREDログをもたらすなら、128ログの限界に達するように、章EからVビットが1に設定される注意ログを下げなければなりません。 Vビットが0に設定される注意ログを下げてはいけません。
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.
ほとんどのMIDIストリームはログ包含規則の引き金となる方法でNoteOnとNoteOffコマンドを使用しません。 これらのストリーム、章Eが決してチャンネルジャーナルに載るREQUIREDでないので。
The ch_never parameter (Appendix C.2.3) may be used to configure the log inclusion rules for Chapter E.
_chに、パラメタ(付録C.2.3)は、章Eのためにログ包含規則を構成するのに決して使用されないかもしれません。
A.8. Chapter T: MIDI Channel Aftertouch
A.8。 章T: ミディチャンネル残触覚
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.
NアクティブでCアクティブなMIDI Channel Aftertouch(0xD)コマンドがチェックポイント歴史に現れるなら、チャンネルジャーナルは章Tを含まなければなりません。 図A.8.1は章Tのために書式を示しています。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| PRESSURE |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S| 圧力| +-+-+-+-+-+-+-+-+
Figure A.8.1 -- Chapter T format
図A.8.1--章T 形式
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.
章には、8ビットの固定サイズがあります。 7ビットのPRESSURE分野はセッション歴史の最新のNアクティブでC活発なChannel Aftertouchコマンドの圧力値を保持します。
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).
章TはC活発でN活発なコマンドをコード化するだけです。 [RP015]が、コントローラ121(リセットAll Controllers)のためのControl Changeコマンドが0へのチャンネル圧をリセットするために行動すると宣言するので(Appendix A.5の端で、より完全な原理に関して議論を見てください)、私たちはC活発な制限を定義します。
Lazzaro & Wawrzynek Standards Track [Page 77] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[77ページ]。
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.
私たちは、ストリームを修理するために残触覚コマンドが活動に注意するためにリンクされて、その結果、N活発でないChannel Aftertouchコマンドを聞き古したである、使用するべきでないという前提のN活発な制限を定義します。
A.9. Chapter A: MIDI Poly Aftertouch
A.9。 章A: ミディポリー残触覚
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.
CアクティブなPoly Aftertouch(0xA)コマンドがチェックポイント歴史に現れるなら、チャンネルジャーナルは章Aを含まなければなりません。 図A.9.1は章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 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| レン|S| NOTENUM|X| 圧力|S| NOTENUM| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 圧力| .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.9.1 -- Chapter A format
図A.9.1--章A 形式
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).
章は2八重奏の注意ログの可変長さのリストがあとに続いた1八重奏のヘッダーから成ります。 注意番号のためのC活発なPoly Aftertouchコマンドがチェックポイント歴史に現れるなら、注意ログは注意番号の弁護に出廷しなければなりません。 注意番号はノートリストの複数の注意ログによって表されてはいけません。 注意ログ・リストは最も古い最初の注文規則(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.
7ビットのLEN分野は1を引いてリストの注意ログの数をコード化します。 図A.9.2は章Aの注意ログ構造を再生させます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| NOTENUM |X| PRESSURE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| NOTENUM|X| 圧力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.9.2 -- Chapter A note log
図A.9.2--章A 注意ログ
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.
7ビットのPRESSURE分野は7ビットのNOTENUM分野でコード化されたMIDI注意番号のためのセッション歴史の最新のC活発なPoly Aftertouchコマンドの圧力値をコード化します。
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
原則として、Xビットを0に設定しなければなりません。 しかしながら、ログによってコード化されたコマンドがセッション歴史における以下のコマンドの1つの前に現れるなら、Xビットを1に設定しなければなりません: ミディコントロール変化
Lazzaro & Wawrzynek Standards Track [Page 78] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[78ページ]。
numbers 123-127 (numbers with All Notes Off semantics) or 120 (All Sound Off).
No.123-127(All Notes Off意味論がある数)か120(すべての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).
[RP015]が、コントローラ121(リセットAll Controllers)のためのControl Changeコマンドが0に対するポリフォニーの圧力をリセットするために行動すると宣言するので(Appendix A.5の端で、より完全な原理に関して議論を見てください)、私たちは章AのためのC活発な制限を定義します。
B. The Recovery Journal System Chapters
B。 回復ジャーナルシステム章
B.1. System Chapter D: Simple System Commands
B.1。 システム、章D: 簡単なシステム・コマンド
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.
アクティブなMIDI Reset(0xFF)、MIDI Tune Request(0xF6)、MIDI Song Select(0xF3)、未定義のMIDI System Common(0xF4と0xF5)、または未定義のMIDI Systemレアル時間(0xF9と0xFD)コマンドがチェックポイント歴史に現れるなら、システムジャーナルは章Dを含まなければなりません。
Figure B.1.1 shows the variable-length format for Chapter D.
図B.1.1は章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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ログを命令してください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.1 -- System Chapter D format
図B.1.1--システム章D 形式
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.
章は1つ以上のコマンドログがあとに続いた1八重奏のヘッダーから成ります。 ヘッダーフラグビットはReset(B=1)のためのコマンドログの存在を示します、Tune Request(G=1)、Song Select(H=1)、未定義のSystem Common 0xF4(J=1)、未定義のSystem Common 0xF5(K=1)、未定義のSystemレアル-時間0xF9(Y=1)、または未定義のSystemレアル-時間0xFD(Z=1)コマンド。
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.
図B.1.2はResetとTune Requestコマンドのための1八重奏のコマンドログ書式を示しています。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S| カウント| +-+-+-+-+-+-+-+-+
Figure B.1.2 -- Command log for Reset and Tune Request
図B.1.2--ResetとTune Requestのためのコマンドログ
Lazzaro & Wawrzynek Standards Track [Page 79] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[79ページ]。
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.
活発なResetコマンドがチェックポイント歴史に現れるなら、章DはResetコマンドログを含まなければなりません。 7ビットのCOUNT分野はセッション歴史の現在のResetコマンド(法128)の総数をコード化します。
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.
活発なTune Requestコマンドがチェックポイント歴史に現れるなら、章DはTune Requestコマンドログを含まなければなりません。 7ビットのCOUNT分野はセッション歴史の現在のTune Requestコマンド(法128)の総数をコード化します。
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.
これらのコマンドのために、参照としてのCOUNT分野条例は重要です。 詳しい情報に関してAppendix A.1との「セッション歴史参照カウント」の定義を見てください。
Figure B.1.3 shows the 1-octet command log format for the Song Select command.
図B.1.3はSong Selectコマンドのための1八重奏のコマンドログ書式を示しています。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| VALUE |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S| 値| +-+-+-+-+-+-+-+-+
Figure B.1.3 -- Song Select command log format
図B.1.3--歌のSelectコマンドログ形式
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.
活発なSong Selectコマンドがチェックポイント歴史に現れるなら、章DはSong Selectコマンドログを含まなければなりません。 7ビットのVALUE分野はセッション歴史の最新の活発なSong Selectコマンドの歌の番号をコード化します。
B.1.1. Undefined System Commands
B.1.1。 未定義のシステム・コマンド
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.
このセクションで、私たちはコマンドが未定義のSystemコマンドのために登録する章Dを定義します。 [MIDI]は今後の使用のために未定義のSystemコマンドの0xF4、0xF5、0xF9、および0xFDを予約します。 この書くこと時点で、これらのコマンドを使用するどんなMIDIコマンドストリームも[MIDI]と共に不従順です。 しかしながら、[MIDI]の将来のバージョンはこれらのコマンドを定義するかもしれません、そして、いくつかの製品が不従順な方法でこれらのコマンドを使用します。
Lazzaro & Wawrzynek Standards Track [Page 80] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[80ページ]。
Figure B.1.4 shows the variable-length command log format for the undefined System Common commands (0xF4 and 0xF5).
図B.1.4は未定義のSystem Commonコマンド(0xF4と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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| カウント| 値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 法的… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.4 -- Undefined System Common command log format
図B.1.4--未定義のSystem Commonコマンドログ形式
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.
コマンドログは単独のコマンドタイプ(両方ではなく、0xF4か0xF5)をコード化します。 活発な0xF5コマンドがチェックポイント歴史に現れるなら、活発な0xF4コマンドがチェックポイント歴史に現れて、独立しているコマンドログを含まなければならないなら、章Dはコマンドログを含まなければなりません。
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.
章Dは可変数のデータ・フィールドがあとに続いた2八重奏のヘッダーから成ります。 ヘッダーフラグビットはCOUNT分野(C=1)、VALUE分野(V=1)、およびLEGAL分野(L=1)の存在を示します。 10ビットのLENGTH分野は、コマンドログのサイズをコード化して、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.
2ビットのDSZ分野はごく最近セッション歴史に現れるコマンドインスタンスにおける、データ八重奏の数をコード化します。 DSZが0-2と等しいなら、コマンドには、0-2 データ八重奏があります。 DSZ=3であるなら、コマンドには、3つ以上のコマンドデータ八重奏があります。
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.
私たちは現在、COUNT、VALUE、およびLEGAL分野の使用のために省略時の解釈を定義します。 Appendix C.2.3で定義されたセッション構成ツールは、この振舞いをくつがえすのに使用されるかもしれません。
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.
デフォルトで、DSZ分野が0に設定されるなら、コマンドログはCOUNT分野を含まなければなりません。 8ビットのCOUNT分野はセッション歴史の現在のログ(0xF4か0xF5)によってコード化されたタイプのコマンドの総数をコード化します、法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.
デフォルトで、DSZ分野が1-3に設定されるなら、コマンドログはVALUE分野を含まなければなりません。 可変長のVALUE分野はセッション歴史でコマンドタイプの最新の使用のためのデータ八重奏がログでコード化した逐語的なコピー(0xF4か0xF5)をコード化します。 最終データ八重奏の最も多くの重要なビットを1に設定しなければなりません、そして、他のすべてのデータ八重奏の最も多くの重要なビットを0に設定しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 81] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[81ページ]。
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.
LEGAL分野は今後の使用のために予約されます。 [MIDI]へのアップデートが0xF4か0xF5コマンドを定義するなら、IETF標準化過程文書はLEGAL分野を定義するかもしれません。 そのようなドキュメントが現れるまで、送付者はLEGAL分野を使用してはいけません、そして、受信機はLEGAL野原を飛ばすのにLENGTH分野を使用しなければなりません。 パケット損失からCOUNTとVALUE分野の使用で新しい0xF4か0xF5コマンドの意味論を保護できないなら、LEGAL分野はIETFによって定義されるでしょうに。
Figure B.1.5 shows the variable-length command log format for the undefined System Real-time commands (0xF9 and 0xFD).
図B.1.5は未定義のSystemレアル-時間コマンド(0xF9と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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| カウント| 法的… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.1.5 -- Undefined System Real-time command log format
図B.1.5--未定義のSystemレアル-時間コマンドログ形式
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.
コマンドログは単独のコマンドタイプ(両方ではなく、0xF9か0xFD)をコード化します。 活発な0xFDコマンドがチェックポイント歴史に現れるなら、活発な0xF9コマンドがチェックポイント歴史に現れて、独立しているコマンドログを含まなければならないなら、章Dはコマンドログを含まなければなりません。
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.
章Dは可変数のデータ・フィールドがあとに続いた1八重奏のヘッダーから成ります。 ヘッダーフラグビットはCOUNT分野(C=1)とLEGAL分野(L=1)の存在を示します。 5ビットのLENGTH分野は、コマンドログのサイズをコード化して、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.
私たちは現在、COUNTとLEGAL分野の使用のために省略時の解釈を定義します。 Appendix C.2.3で定義されたセッション構成ツールは、この振舞いをくつがえすのに使用されるかもしれません。
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.
8ビットのCOUNT分野はセッション歴史の現在のログによってコード化されたタイプのコマンドの総数をコード化します、法256。 デフォルトで、COUNT分野はコマンドログに存在していなければなりません。
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.
LEGAL分野は今後の使用のために予約されます。 [MIDI]へのアップデートが0xF9か0xFDコマンドを定義するなら、IETF標準化過程文書は、コマンドを保護するためにLEGAL分野を定義するかもしれません。 そのようなドキュメントが現れるまで、送付者はLEGAL分野を使用してはいけません、そして、受信機はLEGAL野原を飛ばすのにLENGTH分野を使用しなければなりません。 パケット損失からCOUNT分野の使用で新しい0xF9か0xFDコマンドの意味論を保護できないなら、LEGAL分野はIETFによって定義されるでしょうに。
Lazzaro & Wawrzynek Standards Track [Page 82] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[82ページ]。
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.
最終的に、私たちは、未定義のSystemレアル-時間コマンドのいくつかの標準的でない用途がMIDIシーケンサー系の不従順な異形を実装するために行動することに注意します。 Appendix B.3.1では、私たちはMIDIシーケンサー系のためのこの場合何らかの保護を提供する弾性ツールについて説明します。
B.2. System Chapter V: Active Sense Command
B.2。 システム章のV: 活発な感覚コマンド
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.
アクティブなMIDI Active Sense(0xFE)コマンドがチェックポイント歴史に現れるなら、システムジャーナルは章Vを含まなければなりません。 図B.2.1は章Vのために書式を示しています。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S| COUNT |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S| カウント| +-+-+-+-+-+-+-+-+
Figure B.2.1 -- System Chapter V format
図B.2.1--システム章V 形式
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.
7ビットのCOUNT分野はセッション歴史の現在のActive Senseコマンド(法128)の総数をコード化します。 参照としてのCOUNT分野条例は重要です。 詳しい情報に関してAppendix A.1との「セッション歴史参照カウント」の定義を見てください。
B.3. System Chapter Q: Sequencer State Commands
B.3。 システム、章Q: シーケンサ州のコマンド
This appendix describes Chapter Q, the system chapter for the MIDI sequencer commands.
この付録はMIDIシーケンサコマンドのために章Q、システム章について説明します。
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.
コマンド外観のために、アクティブなMIDI Song Position Pointer(0xF2)、MIDI Clock(0xF8)、MIDI Start(0xFA)、MIDI Continue(0xFB)、またはMIDI Stop(0xFC)コマンドがチェックポイント歴史に現れて、この付録で定義された規則が章のQ bitfieldコンテンツで変化を必要とするなら、システムジャーナルは章Qを含まなければなりません。
Figure B.3.1 shows the variable-length format for Chapter Q.
図B.3.1は章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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| トップ| 時計| TIMETOOLS… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.3.1 -- System Chapter Q format
図B.3.1--システム章Q 形式
Lazzaro & Wawrzynek Standards Track [Page 83] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[83ページ]。
Chapter Q consists of a 1-octet header followed by several optional fields, in the order shown in Figure B.3.1.
章Qは図B.3.1のオーダーにおけるいくつかの任意の分野があとに続いた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.
ヘッダーフラグビットは16ビットのCLOCK分野(C=1)と24ビットのTIMETOOLS分野(T=1)の存在を示します。 3ビットのTOPヘッダーフィールドはCLOCKとTIMETOOLSのように符号のない整数として解釈されます。 私たちはAppendix B.3.1のTIMETOOLS分野について説明します。
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.
章Qはシーケンサー系の最新の事情をコード化します。 受信機は、パケット損失エピソードの後にシーケンサを再連動させるのに章を使用します。 章の分野はシーケンサのオンであるかオフな状態、歌の現在の見解、および強拍をコード化します。
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.
Nヘッダービットはセッション歴史におけるStart、Stop、およびContinueコマンドの相対的な発生をコード化します。 アクティブなStartかContinueコマンドがごく最近現れるなら、Nビットを1に設定しなければなりません。 アクティブなStopがごく最近現れるか、またはいいえのアクティブなStart、Stop、またはContinueコマンドがセッション歴史に現れるなら、Nビットを0に設定しなければなりません。
The C header flag, the TOP header field, and the CLOCK field act to code the current position in the sequence:
Cヘッダー旗、TOPヘッダーフィールド、およびCLOCK分野は系列の現在の見解をコード化するために作動します:
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 Cが1、3ビットのTOPヘッダーフィールドと等しいか、そして、16ビットのCLOCK分野は、19ビットの未署名の量の65536*TOP+CLOCKを形成するために結合されます。 この値はユニットのMIDI Clocks(1四分音符あたり24個の時計)の歌の位置、法524288をコード化します。 Song Position Pointerコマンドでコード化されるかもしれない最大の歌の位置の価値が98303個の時計(17ビットでコード化されるかもしれない)であり、一般に、MIDIによってコード化された歌がこの値より長い間持続時間を避けるために構成されることに注意してください。 しかしながら、19ビットのサイズはリアルタイムのアプリケーションの役に立つかもしれません、長期間の間に時計コマンドを送るドラム・マシンMIDI出力のように。
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.
o C=0であるなら、歌の位置は歌の始まりです。 0C=位置はCでコード化された位置=1、TOP=0、およびCLOCK=0と同じです、歌の位置が524288個未満のMIDI時計であるケースのために。 ある状況(後でこのセクションで定義される)で、標準のテキストはC=0かC=1、TOP=0、歌の始まりのCLOCK=0コード化を必要とするかもしれません。
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.
C、TOP、およびCLOCK分野は現在の歌の位置をコード化するように用意ができなければなりません、N=0とN=1状態の両方のために。 C=0であるなら、TOP分野を0に設定しなければなりません。 歌の位置の厳密な定義に関して[MIDI]を見てください。
Lazzaro & Wawrzynek Standards Track [Page 84] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[84ページ]。
The D header bit encodes information about the downbeat and acts to qualify the song position coded by the C, TOP, and CLOCK fields.
Dヘッダービットは、Cによってコード化された歌の位置、TOP、およびCLOCK野原に資格を与えるために強拍と行為の情報をコード化します。
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.
Dビットが1に設定されるなら、歌の位置はプレーした系列の最新の見解を表します。 Dが歌を増加するように1、次のClockコマンド(N=1であるなら)または次の(続いてください、Clock)組(N=0であるなら)条例と等しいなら、1個の時計と、プレーにアップデートされた位置を位置決めしてください。
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.
Dビットが0に設定されるなら、歌の位置はまだプレーされていない系列の見解を表します。 Dが0、次のClockコマンドと等しいか、そして、(N=1であるなら)次の(続いてください、Clock)組(N=0であるなら)が、歌の位置によってコード化された歌のポイントをプレーするために行動します。 歌の位置は増加されていません。
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.
0D=コード化を使用するストリームに関する例は最新の系列コマンドがStartかSong Position Pointerコマンド(両方のN=1状態)であるものです。 しかしながら、また、Dが0とNと等しい例=0を構成するのも可能です。 Stopコマンドがすぐにあとに続いたStartコマンドは章Qで0、0、C=D=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.
N=1(Startをコード化するか、Continue)、D=0(強拍がまだプレーされているために持っているコード化)、および歌の位置が歌の始めにあるなら、StartコマンドがContinueコマンドより最近セッション歴史、およびC=1に起こるなら、C=0歌位置コード化を使用しなければならなくて、TOP=はContinueコマンドがセッション歴史におけるStartコマンドより最近起こるならコード化を使用しなければならないという0歌の0、CLOCK=位置です。
B.3.1. Non-compliant Sequencers
B.3.1。 不従順なシーケンサ
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.
この付録における章のQ記述は、シーケンサー系がClockコマンドと共に時間を数えると仮定します、[MIDI]で強制されるように。 しかしながら、いくつかの不従順な製品は時間を数えるClockコマンドを使用しませんが、代わりに標準的でないメソッドを使用してください。
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.
章Qは、これらの標準的でない製品の弾性サポートを提供するのにTIMETOOLS分野を使用します。 デフォルトで、TIMETOOLS野原は章Qに現れてはいけません、そして、Tヘッダービットを0に設定しなければなりません。 Appendix C.2.3で説明されたセッション構成ツールは、TIMETOOLSコード化を選択するのに使用されるかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 85] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[85ページ]。
Figure B.3.2 shows the format of the 24-bit TIMETOOLS field.
図B.3.2は24ビットのTIMETOOLS分野の書式を示しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.3.2 -- TIMETOOLS format
図B.3.2--TIMETOOLS形式
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).
タイム誌分野はユニットのミリセカンドがいる24ビットの符号のない整数量です。 タイム誌はTOP、CLOCK、およびC分野によってコード化された歌の位置に付加的な修正項をコード化します。 タイム誌はネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
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.
受信機は、ユニットのMIDI時計にタイム誌を変換して、65536*TOP+CLOCKにそれを加えることによって、正しい歌の位置を計算します(Cが=1であると仮定して)。 あるいはまた、受信機は、ミリセカンド(Cが=1であると仮定します)に65536*TOP+CLOCKを変換して、それをタイム誌に追加するかもしれません。 Appendix B.3で定義された陰気な(Dヘッダービット)意味論は直っている歌の位置に適用されます。
B.4. System Chapter F: MIDI Time Code Tape Position
B.4。 システム、章F: ミディ時間コードテープ位置
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.
MIDI Time Code(MTC)のためのシステム章は、この付録が章Fについて説明すると命令します。 この付録を読む前に、読者は「終わっているか未完成のコマンド」のAppendix A.1定義を見直したがっているかもしれません。
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.
活発なSystem Common Quarter Frameコマンド(0xF1)か活発な完成System Exclusive(普遍的なレアルTime)MTC Full Frameコマンド(F0 7F cc01 01時間のMn Sc fr F7)がチェックポイント歴史に現れるなら、システムジャーナルは章Fを含まなければなりません。 さもなければ、システムジャーナルは章Fを含んではいけません。
Figure B.4.1 shows the variable-length format for Chapter F.
図B.4.1は章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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+
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|ポイント| 完全… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 部分的… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+
Figure B.4.1 -- System Chapter F format
図B.4.1--システム章F 形式
Lazzaro & Wawrzynek Standards Track [Page 86] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[86ページ]。
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.
章Fはセッション歴史でコード化された最近のMTCテープ位置の情報を保持します。 受信機は、パケット損失エピソードの後にMTCシステムを再同期させるのに章Fを使用します。
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).
章Fは図B.4.1のオーダーにおけるいくつかの任意の分野があとに続いた1八重奏のヘッダーから成ります。 CとPヘッダービットは、目次(TOC)を形成して、32ビットのCOMPLETE分野(C=1)と32ビットのPARTIAL分野(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.
QヘッダービットはCOMPLETEフィールド形式の情報をコード化します。 章FがCOMPLETE分野を含んでいないなら、0にQを設定しなければなりません。
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).
Dヘッダービットはテープ運動方向をコード化します。 テープが前方へ動いているなら、テープ方向が不確定であるなら、Dビットを0に設定しなければなりません。 テープが反対の方向に入って来ているなら、Dビットを1に設定しなければなりません。 多くの場合、セッション歴史における、コマンドの注文は明確にテープ方向を定義します。 しかしながら、いくつかのコマンド・シーケンスに、不確定の方向(1つのFull Frameコマンドから成るセッション歴史などの)があります。
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).
3ビットのPOINTヘッダーフィールドは符号のない整数として解釈されます。 付録B.4.1はPOINT分野がどうPARTIAL分野のコンテンツの情報をコード化するかを定義します。 章Fがそうしないなら、PARTIAL分野を含んでください、POINT MUST。7(Dが0と等しいなら)へのセットか0(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.
活発な終わっているFull Frameコマンドがチェックポイント歴史に現れるか、またはフレーム価値のコード化を完了する活発なQuarter Frameコマンドがチェックポイント歴史に現れるなら、章FはCOMPLETE分野を含まなければなりません。
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.
COMPLETE分野はセッション歴史に現れる最新のアクティブな完全なMTCフレーム価値をコード化します。 このフレーム値は、一連の8つの活発なQuarter Frameコマンド(前進のテープ運動のための0xF1 0x7nを通した0xF1 0x0n、逆のテープ運動のための0xF1 0x0nを通した0xF1 0x7n)の形を取るか、または活発な終わっているFull Frameコマンドの形を取るかもしれません。
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].
COMPLETE分野がQuarter Frameコマンドシリーズをコード化するなら、Qヘッダービットを1に設定しなければなりません、そして、COMPLETE分野には、図B.4.2に示された書式がなければなりません。 4ビットはMessage Type0のために、Message Type7[MIDI]を通してMT0からMT7へのデータ(下側の)がQuarter Frameコマンドのために少しずつ掴み取るコードをさばきます。 これらの少量が今後の使用のために[MIDI]によって予約された分野に加えて完全なフレーム値をコード化します。
Lazzaro & Wawrzynek Standards Track [Page 87] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[87ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
図B.4.2--COMPLETEフィールド形式、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.
この用法で、フレーム値が0xF1 0x7nコマンド・シーケンスを通して0xF1 0x0nをコード化するなら、2個のフレーム(Quarter Frameコマンドでコード化されたフレーム値に比例した)でCOMPLETE分野でコード化されたフレーム値を相殺しなければなりません。 このオフセットは前進のテープ運動のためのQuarter Frameコード化の2フレーム潜在を補います。 フレーム値が0xF1 0x0n Quarter Frameコマンド・シーケンスを通して0xF1 0x7nをコード化するなら、どんなオフセットも適用されていません。
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.
あるいはまた、最新のアクティブな完全なMTCフレーム価値は活発な終わっているFull Frameコマンドでコード化されるかもしれません。 この場合、Qヘッダービットを0に設定しなければなりません、そして、COMPLETE分野には、図B.4.3に示された書式がなければなりません。 HR、ミネソタ(サウスカロライナ)、およびFR分野はFull Frameコマンドの時間、Mn、Sc、およびfrデータ八重奏に対応しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 時間| ミネソタ| サウスカロライナ| フラン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.4.3 -- COMPLETE field format, Q = 0
図B.4.3--COMPLETEフィールド形式、Q=0
B.4.1. Partial Frames
B.4.1。 部分的なフレーム
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).
MTCフレーム値のデータをコード化する最新の活発なセッション歴史命令は前方に移行している0xF1 0x7nコマンド(前進のテープ運動のためにフレーム値を完成する)か逆移行している0xF1 0x1nコマンド(逆のテープ運動のためにフレーム値を完成する)以外のQuarter Frameコマンドであるかもしれません。
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.
私たちは、このタイプのQuarter Frameコマンドが部分的なフレーム値に関連していると考えます。 部分的なフレーム値を定義するQuarter Frame系列は、タイプより多くの0をMessage Type0で始めて、近接して中間的Message Type7、またはMessage Type7の始めに増加して、近接して中間的Messageに減少させなければなりません。 このパターンに従わないQuarter Frameコマンド・シーケンスは部分的なフレーム値に関連づけられません。
Lazzaro & Wawrzynek Standards Track [Page 88] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[88ページ]。
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.
章FはMTCフレーム値のデータをコード化するチェックポイント歴史における最新の活発なコマンドが部分的なフレーム値に関連しているQuarter FrameコマンドであるならPARTIAL分野を含まなければなりません。 さもなければ、章FはPARTIAL分野を含んではいけません。
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.
部分的なフレーム値はQuarter Frameコマンド・シーケンスのデータの(下側)の少量から成ります。 図B.4.2に示された書式を使用して、PARTIAL分野は部分的なフレーム値をコード化します。 Quarter Frameコマンドに関連していないメッセージType分野を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.
POINTヘッダーフィールドは、PARTIAL分野のMessage Type分野が有効データをコード化するのを示します。 P=1であるなら、POINT分野はセッション歴史の最新の活発なQuarter Frameコマンドのデータ価値の上側の少量の低級3ビットによって形成された符号のない整数値をコード化しなければなりません。 Dが0とP=1と等しいなら、POINT MUSTは範囲0-6で値を呈します。 Dが1とP=1と等しいなら、POINT MUSTは範囲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.
D=0であるなら、POINT値を含めた0からの包括的な範囲のMT分野(図B.4.2)は部分的なフレーム値をコード化します。 Dが1と等しいなら、7からの包括的な範囲のMT分野は、部分的なフレームが評価するPOINT値のエンコードをダウンして、含んでいます。 送付者が、COMPLETE分野コード化と異なって2フレームが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.
デフォルト意味論のために、回復ジャーナルが章Fを含んでいて、セッション歴史が法的な[MIDI]シリーズのQuarter FrameとFull Frameコマンドをコード化するなら、章はいつもCOMPLETEかPARTIAL分野(そして、両方の分野を含むかもしれない)を含んでいます。 このようにして、そして、1八重奏の章、F(CはP=0と等しい)はセッション歴史での不正コマンド系列の存在をいつもコード化します(また、いくつかの状態、C=1の下では、0P=状態は不正コマンド系列の存在をコード化するかもしれません)。 不正コマンド系列状態は、現実に一時的であり、通常、Quarter Frameコマンド・シーケンスが中間的Message Typeと共に始まったのを示します。
B.5. System Chapter X: System Exclusive
B.5。 システム、章X: システム排他的です。
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.
MIDI System Exclusive(SysEx)のためのシステム章は、この付録が章Xについて説明すると命令します(0xF0)。 この付録を読む前に、読者は「終わっているか未完成のコマンド」のAppendix A.1定義を見直したがっているかもしれません。
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
章Xは1つ以上のコマンドログのリストから成ります。 リストの各ログはセッション歴史に現れる特定の終わっているか未完成のSysExコマンドの情報をコード化します。 システム
Lazzaro & Wawrzynek Standards Track [Page 89] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[89ページ]。
journal MUST contain Chapter X if the rules defined in Appendix B.5.2 require that one or more logs appear in the list.
Appendix B.5.2で定義された規則が、1つ以上のログがリストに現れるのを必要とするなら、ジャーナルは章Xを含まなければなりません。
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).
ログ・リストはヘッダーによって先行されていません。 代わりに、各ログはそれとなくそれ自身の長さをコード化します。 N'thリストログ、存在の長さを与える、(N+1)、'、リストログがシステムジャーナルヘッダー(主なテキストのセクション5の図10)のLENGTH分野から第推論されるかもしれない、' ログ・リストは最も古い最初の注文規則(Appendix A.1では、定義される)に従わなければなりません。
B.5.1. Chapter Format
B.5.1。 章の形式
Figure B.5.1 shows the bitfield format for the Chapter X command log.
図B.5.1は章のXコマンドログのためにbitfield書式を示しています。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| カウント| 最初に… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B.5.1 -- Chapter X command log format
図B.5.1--章X コマンドログ形式
A Chapter X command log consists of a 1-octet header, followed by the optional TCOUNT, COUNT, FIRST, and DATA fields.
章のXコマンドログは任意のTCOUNT、COUNT、FIRST、およびDATA分野が支えた1八重奏のヘッダーから成ります。
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.
T、C、F、およびDヘッダービットはログのための目次(TOC)として作用します。 Tが1に設定されるなら、1八重奏のTCOUNT野原は丸太のままで現れます。 Cが1に設定されるなら、1八重奏のCOUNT野原は丸太のままで現れます。 Fが1に設定されるなら、可変長のFIRST野原は丸太のままで現れます。 Dが1に設定されるなら、可変長のDATA野原は丸太のままで現れます。
The L header bit sets the coding tool for the log. We define the log coding tools in Appendix B.5.2.
Lヘッダービットはログにコーディング・ツールを設定します。 私たちは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.
STA分野はログによってコード化されたコマンドの状態をコード化します。 2ビットのSTA値は符号のない整数として解釈されます。 STAが0歳であるなら、ログは未完成のコマンドをコード化します。 非ゼロSTA値は異なったクラスの終わっているコマンドをコード化します。 1のSTA値が取り消されたコマンドをコード化して、2のSTA値がそれが使用するコマンドをコード化する、「F7"工事、およびすべてのもう一方が終えた3つのコードのSTA値を下げる、コマンド、」 テキストが説明するメインのセクション3.2は、取り消して、「F7"コマンドを下げました」。
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
Sが章のX.Forのために他のログに噛み付いたのでリストがリストで機能させる最初のログインのSビット(付録A.1)、Sビットは参照されます。
Lazzaro & Wawrzynek Standards Track [Page 90] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[90ページ]。
to the log itself. The value of the "phantom" S bit associated with the first log is defined by the following rules:
ログ自体に。 最初のログに関連している「幻」Sビットの価値は以下の規則で定義されます:
o If the list codes one log, the phantom S-bit value is the same
as the Chapter X S-bit value.
o リストが1つのログをコード化するなら、幻影のS-ビット値は章のX S-ビット価値と同じです。
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.
o リストが複数のログをコード化するなら、幻影のS-ビット値はリストの1番目と2番目のコマンドログのS-ビット価値の論理的なORです。
In all other respects, the S bit follows the semantics defined in Appendix A.1.
他のすべての点で、Sビットは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.
FIRST分野(プレゼントはFであるなら1と等しい)はDATA分野の適用範囲を設定する可変長の符号のない整数値をコード化します。
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.
FIRST分野(プレゼントはFであるなら1と等しい)はどのSysExデータ・バイトがログのDATA分野でコード化されるかを指定する可変長の符号のない整数値をコード化します。 FIRST分野は最上位ビットが最上位ビットが1に設定される1つ以上の八重奏で任意に先行された0に設定される八重奏から成ります。 図B.5.2に示されたアルゴリズムは、値のDEC社(FIRST)をもたらすためにこの書式を符号のない整数に解読します。 DEC社(FIRST)がSysExコマンドにおけるデータ八重奏に参照をつけるので、FIRSTはa可変長のコード化を使用します、そして、SysExコマンドはデータ八重奏の特殊活字の数字を含むかもしれません。
One-Octet FIRST value:
1八重奏のFIRST値:
Encoded form: 0ddddddd
Decoded form: 00000000 00000000 00000000 0ddddddd
コード化されたフォーム: 0ddddddd Decodedは形成します: 00000000 00000000 00000000 0ddddddd
Two-Octet FIRST value:
2八重奏のFIRST値:
Encoded form: 1ccccccc 0ddddddd
Decoded form: 00000000 00000000 00cccccc cddddddd
コード化されたフォーム: 1ccccccc 0ddddddd Decodedは形成します: 00000000 00000000 00cccccc cddddddd
Three-Octet FIRST value:
3八重奏のFIRST値:
Encoded form: 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 00000000 000bbbbb bbcccccc cddddddd
コード化されたフォーム: 1bbbbbbb 1ccccccc 0ddddddd Decodedは形成します: 00000000 000bbbbb bbcccccc cddddddd
Four-Octet FIRST value:
4八重奏のFIRST値:
Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd
Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd
コード化されたフォーム: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd Decodedは形成します: 0000aaaa aaabbbbb bbcccccc cddddddd
Figure B.5.2 -- Decoding FIRST field formats
図B.5.2--FIRSTフィールド形式を解読すること。
Lazzaro & Wawrzynek Standards Track [Page 91] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[91ページ]。
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.
DATA分野(プレゼントはDであるなら1と等しい)はログによってコード化されたSysExコマンドのデータ八重奏の変更されたバージョンをコード化します。 DATA分野で状態八重奏をコード化してはいけません。
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.
F=0であるなら、DATA分野は、SysExコマンドの最初のデータ八重奏で始まって、コマンドのためのセッション歴史に現れるすべての順次データ八重奏を含んでいます。 Fが1、分野と始まるDATAと等しい、(DEC社(FIRST)+1)、'、SysExのデータ八重奏がコマンドのためのセッション歴史に現れるすべての順次データ八重奏を命令して、第含んでいる、' 特定のMIDIリストSysExコマンドセグメントに現れるのではなく、ソースMIDIデータ・ストリームに現れるように「コマンド」という上の記述における言葉がオリジナルのSysExコマンドを示すことに注意してください。
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.
それぞれの八重奏の重要なビットを最も使用して、DATA分野の長さはそれとなくコード化されます。 DATA分野の最終的な八重奏の最も多くの重要なビットを1に設定しなければなりません。 他のすべてのDATA八重奏の最も多くの重要なビットを0に設定しなければなりません。 このコード化メソッドはMIDIデータ八重奏の最も多くの重要なビットが定義上0であるという事実を当てにします。 この長さをコード化する変更は別として、DATA分野はそれがコード化するすべてのデータ八重奏の逐語的なコピーをコード化します。
B.5.2. Log Inclusion Semantics
B.5.2。 ログ包含意味論
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.
章XはSysExコマンドを保護するために2つのツールを提供します: 「新鮮」ツールと「リスト」ツール。 ツール定義は私たちが現在定義するコマンドについて「SysExはタイプする」概念を使用します。
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".
MTC Full Frameコマンドを除いて、セッションにおけるそれぞれのSysExコマンドインスタンスは「SysExタイプ」を持っていると言われています。 タイプは平等比較に使用されます: セッションにおける2つのSysExコマンドが「同じSysExタイプ」を持っていると言われているか、または「異なったSysExはタイプします」。
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.
効率が関心でないなら、送付者は簡単なタイプ規則に従うかもしれません: 異なったSysExはセッション歴史におけるあらゆるSysExコマンドでタイプします、そして、その結果、いいえtwoはセッションのときに同じタイプがあるように命令します。
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:
能率を増進するために、送付者はこの規則への例外を実装するかもしれません。 これらの例外は、同じSysExが、あるセットのSysExコマンドインスタンスでタイプすると宣言します。 例外でカバーされなかった少しのコマンドも簡単な規則に従います。 私たちは以下の例外を記載します:
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
o 同じデータ八重奏分野(データ八重奏の同数、それぞれのデータ八重奏のための同じ値)があるすべてのコマンドには、同じタイプがあります。 すべてのSysExコマンドにこの規則をセッション、または全く適用してはいけません。 この例外の実装が形式と意味論に関する送付者知識を全く必要としない注意
Lazzaro & Wawrzynek Standards Track [Page 92] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[92ページ]。
SysEx commands in the stream, merely the ability to count and
compare octets.
SysExはストリーム、八重奏を数えて、比較する単に能力で命令します。
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.
o 意味論が同じ「パラメタ」の値を設定するか、または報告する同じコマンドの2つのインスタンスには、同じタイプがあります。 この例外の実装は形式に関する特定の知識とSysExコマンドの意味論を必要とします。 実際には、送付者実装は、あるクラスのコマンド([MIDI]で定義されたUniversal System Exclusiveコマンドなどの)のためにこの例外をサポートするのを選びます。 送付者が、クラスにおける特定のコマンドのためのこの例外が(例えばMaster VolumeへのTime System Exclusiveメッセージ(F0 F7cc04 01vv vv F7)が[MIDI]で定義したUniversalレアル)であるとサポートするなら、それはセッションにおけるこの特定のコマンドのすべてのインスタンスへの例外をサポートしなければなりません。
We now use this definition of "SysEx type" to define the "recency" tool and the "list" tool for Chapter X.
私たちは、現在、章Xのために「新鮮」ツールと「リスト」ツールを定義するのに「SysExはタイプする」この定義を使用します。
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)).
デフォルトで、章のXログ・リストは、チェックポイント歴史(章F(付録B.4)でコード化される終わっているMTC Full Frameコマンドを除いた)に現れるすべての終わっているか未完成の活発なSysExコマンドの損失で引き起こされた無期人工物からレンダリングされたMIDI性能を保護するために十分な情報をコード化しなければなりません。
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.
新鮮ツールがある特定のSysExタイプのコマンドを保護するために、送付者はチェックポイント歴史に現れるSysExタイプの最新の終わっているアクティブなインスタンスのためのログ・リストのログをコード化しなければなりません。 さらに、SysExタイプの未完成のアクティブなインスタンスがチェックポイント歴史に現れるなら、送付者は未完成のコマンドインスタンスのためのログ・リストのログをコード化しなければなりません。 両方のコマンドログのLヘッダービットを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.
リストツールがある特定のSysExタイプのコマンドを保護するために、送付者はチェックポイント歴史に現れるSysExタイプのそれぞれの終わっているか未完成のアクティブなインスタンスのための章のXログ・リストのログをコード化しなければなりません。 リストツールコマンドログのLヘッダービットを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.
原則として、リストか新鮮ツールによるログREQUIREDはSysExコマンドインスタンスのためのチェックポイント歴史でログに関連しているように見えるすべてのデータ八重奏をコード化するDATA分野を含まなければなりません。 FIRST分野は、この必要条件を最少量で満たすDATA分野を構成するのに使用されるかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 93] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[93ページ]。
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.
この規則への例外は取り消されたコマンド(セクション3.2では、定義される)に適用されます。 取り消されたコマンドに関連しているREQUIREDコマンドログはDATA分野なしでコード化されるかもしれません。 しかしながら、DATAが丸太のままで現れるなら、DATA MUSTはコマンドのためのチェックポイント歴史でログに関連しているように見えるすべてのデータ八重奏をコード化します。
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.
このセクションの前のテキストによって定義されるように、デフォルトで、すべてが終わったか、またはリストツールか新鮮ツールでチェックポイント歴史(終わっているMTC Full Frameコマンドを除いた)に現れる未完成の活発なSysExコマンドを保護しなければなりません。
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.
いくつかのMIDIソースストリームのために、このデフォルトはサイズが大き過ぎる章Xをもたらします。 例えば、送付者がUDP RTPストリームへの1万のデータ八重奏で「急いで」SysExコマンドを「移-コード」に始めると想像してください、データ八重奏がMIDIソースによって提供されるとすぐに、コマンドセグメントをSysExに送ることによって。 1000の八重奏を送った後に、章Xの拡張はストリームには、Maximum Transmission Unit(MTU)をうまくはめ込むことができないくらい大きいRTPパケットをもたらします。
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.
この状況で、送付者がSysExコマンドに閉ループ送付方針を使用するなら、ストリームを失速させることによって、RTPパケットサイズにいつもふたをするかもしれません。 ストリーム売店、かつての最大のサイズに、送付者が控えるパケット範囲では、受信機フィードバックが章のX.Ifの整頓にストリームを可能にするまで非空のMIDI Commandセクションがある新しいパケットを送ると、SysExセグメントの間で(ツールがAppendix C.1で定義した構成使用の間、選択可能です)に見える任意のコマンドが可能にしますが、送付者がSysExセグメントストリームを失速させるかもしれませんが、MIDIリストにおける他のコマンドをコード化し続けてください。
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:
売店はサイズが発行する章の実行可能な、しかし、サブ最適解のXです。 売店に代わる手段として、送付者SHOULDは章Xの予期されたサイズを減少させるためにセッション構成の間、先制措置を取ります、以下で説明されたメソッドを使用して:
o Partitioned transport. Appendix C.5 provides tools for sending
a MIDI name space over several RTP streams. Senders may use
these tools to map a MIDI source into a low-latency UDP RTP
stream (for channel commands and short SysEx commands) and a
reliable [RFC4571] TCP stream (for bulk-data SysEx commands).
The cm_unused and cm_used parameters (Appendix C.1) may be used
to communicate the nature of the SysEx command partition. As
TCP is reliable, the RTP MIDI TCP stream would not use the
recovery journal. To minimize transmission latency for short
SysEx commands, senders may begin segmental transmission for all
SysEx commands over the UDP stream and then cancel the UDP
transmission of long commands (using tools described in Section
3.2) and resend the commands over the TCP stream.
o 輸送を仕切りました。 付録C.5はいくつかのRTPストリームの上にMIDI名前スペースを送るのにツールを提供します。Sendersは、低遅延UDP RTPストリーム(チャネル指令と短いSysExコマンドのための)と信頼できる[RFC4571]TCPストリーム(大量のデータSysExコマンドのための)にMIDIソースを写像するのにこれらのツールを使用するかもしれません。 未使用とcmの_の中古のパラメタ(付録C.1)が使用されているかもしれないcm_はSysExコマンドパーティションの本質を伝えます。 TCPが信頼できるので、RTP MIDI TCPストリームは回復ジャーナルを使用しないでしょう。 次に、送付者は、短いSysExコマンドのためにトランスミッション潜在を最小にするために、UDPストリームの上ですべてのSysExコマンドのためのセグメントのトランスミッションを始めて、長いコマンド(セクション3.2で説明されたツールを使用する)のUDP送信を中止して、TCPストリームの上にコマンドを再送するかもしれません。
Lazzaro & Wawrzynek Standards Track [Page 94] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[94ページ]。
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.
o 選択している保護。 ジャーナル保護は絶え間なくすべてのSysExコマンドに必要でないかもしれません。 _chに、パラメタ(付録C.2)は、どのSysExコマンドが章Xから除かれるかを伝えるのに決して使用されないかもしれません。
B.5.3. TCOUNT and COUNT Fields
B.5.3。 TCOUNTとカウント分野
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.
Tヘッダービットが1に設定されるなら、8ビットのTCOUNT野原はコマンドログに現れます。 Cヘッダービットが1に設定されるなら、8ビットのCOUNT野原はコマンドログに現れます。 TCOUNTとCOUNTは符号のない整数として解釈されます。
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.
TCOUNT分野はセッション歴史に現れるログによってコード化されたSysExタイプのSysExコマンドの総数をコード化します、ログによってコード化された(終わるか未完成)のコマンドがセッション歴史を入力した後に瞬間に。
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.
セッション歴史に現れるSysExコマンドの総数はCOUNT分野はコード化されて、ログによる決してパラメタ(付録C.2)でなくて、現在、(終わるか未完成)のコマンドの後にコード化されたch_を通して章Xから除かれるコマンドを除くと、セッション歴史は入力されます。
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).
TCOUNTとCOUNTのために重要であるコマンドは法-256演算を使用します。 MTC Full Frameコマンドインスタンス(付録B.4)はTCOUNTとCOUNT定義が彼らの包含を保証するなら重要であるコマンドに含まれています、取り消されたコマンド(セクション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.
送付者は、アイデンティティとコマンドインスタンスの(TCOUNTのための)系列位置を追跡するのにTCOUNTとCOUNT分野を使用します。 アイデンティティか系列情報がログによってコード化されたコマンドタイプを保護するのに必要であるなら、SendersはTCOUNTかCOUNT分野を使用しなければなりません。
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.
送付者がセッションのときにCOUNT分野を使用するなら、ストリームにおけるあらゆる章Xの最終的なコマンドログはCOUNT分野をコード化しなければなりません。 この規則で、受信機はパケット損失の後にCOUNT値を再連動させます。
C. Session Configuration Tools
C。 セッション構成ツール
In Sections 6.1-2 of the main text, we show session descriptions for minimal native and mpeg4-generic RTP MIDI streams. Minimal streams lack the flexibility to support some applications. In this appendix, we describe how to customize stream behavior through the use of the payload format parameters.
主なテキストのセクション6.1-2では、私たちは最小量のネイティブとmpeg4-ジェネリックRTP MIDIストリームのためのセッション記述を示しています。最小量のストリームはいくつかのアプリケーションをサポートする柔軟性を欠いています。 この付録では、私たちはペイロード形式パラメタの使用でストリームの振舞いをカスタマイズする方法を説明します。
Lazzaro & Wawrzynek Standards Track [Page 95] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[95ページ]。
The appendix begins with 6 sections, each devoted to parameters that affect a particular aspect of stream behavior:
付録はそれぞれストリームの振舞いの特定の局面に影響するパラメタにささげられた6つのセクションで始まります:
o Appendix C.1 describes the stream subsetting system (cm_unused
and cm_used).
o 付録C.1はストリーム副設定システム(未使用とcm_が使用したcm_)について説明します。
o Appendix C.2 describes the journalling system (ch_anchor,
ch_default, ch_never, j_sec, j_update).
o 付録C.2はjournallingシステム(_アンカー、ch_デフォルトが決してchしないch、j_秒、j_アップデート)について説明します。
o Appendix C.3 describes MIDI command timestamp semantics
(linerate, mperiod, octpos, tsmode).
o 付録C.3はMIDIコマンドタイムスタンプ意味論(linerate、mperiod、octpos、tsmode)について説明します。
o Appendix C.4 describes the temporal duration ("media time") of
an RTP MIDI packet (guardtime, rtp_maxptime, rtp_ptime).
o 付録C.4はRTP MIDIパケット(guardtime、rtp_maxptime、rtp_ptime)の時の持続時間(「メディア時間」)について説明します。
o Appendix C.5 concerns stream description (musicport).
o 付録C.5関心は記述(musicport)を流します。
o Appendix C.6 describes MIDI rendering (chanmask, cid, inline,
multimode, render, rinit, subrender, smf_cid, smf_info,
smf_inline, smf_url, url).
o 付録C.6はMIDIレンダリングについて説明します(chanmask、インライン、マルチモードがレンダリングするrinitであって、よりsubrenderなCidは、_Cidをsmfして、smf_インフォメーション、smf_インラインは_urlに、urlにsmfされます)。
The parameters listed above may optionally appear in session descriptions of RTP MIDI streams. If these parameters are used in an SDP session description, the parameters appear on an fmtp attribute line. This attribute line applies to the payload type associated with the fmtp line.
上にリストアップされたパラメタはRTP MIDIストリームのセッション記述に任意に現れるかもしれません。これらのパラメタがSDPセッション記述に使用されるなら、パラメタはfmtp属性系列に現れます。 この属性系列はfmtp系列に関連づけられたペイロードタイプに適用されます。
The parameters listed above add extra functionality ("features") to
minimal RTP MIDI streams. In Appendix C.7, we show how to use these
features to support two classes of applications: content-streaming
using RTSP (Appendix C.7.1) and network musical performance using SIP
(Appendix C.7.2).
上にリストアップされたパラメタは付加的な機能性(「特徴」)を最小量のRTP MIDIストリームに言い足します。Appendix C.7では、私たちは、どのように2つのクラスのアプリケーションをサポートするこれらの特徴を使用するかを示します: SIP(付録C.7.2)を使用することでRTSP(付録C.7.1)とネットワーク演奏を使用する満足しているストリーミング。
The participants in a multimedia session MUST share a common view of all of the RTP MIDI streams that appear in an RTP session, as defined by a single media (m=) line. In some RTP MIDI applications, the "common view" restriction makes it difficult to use sendrecv streams (all parties send and receive), as each party has its own requirements. For example, a two-party network musical performance application may wish to customize the renderer on each host to match the CPU performance of the host [NMP].
マルチメディアセッションの関係者はRTPセッションのときに現れるRTP MIDIストリームのすべての共通認識を共有しなければなりません、ただ一つのメディア(m=)系列によって定義されるように。 いくつかのRTP MIDIアプリケーションでは、「共通認識」制限でsendrecvストリームを使用するのは難しくなります(すべてのパーティーが、発信して、受信します)、各当事者にそれ自身の要件があるとき。 例えば、2パーティーのネットワーク演奏アプリケーションは、ホスト[NMP]のCPU実績を合わせるために各ホストの上でレンダラーをカスタム設計したがっているかもしれません。
We solve this problem by using two RTP MIDI streams -- one sendonly, one recvonly -- in lieu of one sendrecv stream. The data flows in the two streams travel in opposite directions, to control receivers configured to use different renderers. In the third example in Appendix C.5, we show how the musicport parameter may be used to define virtual sendrecv streams.
私たちは2つのRTP MIDIストリームを使用することによって、この問題を解決します--1sendonly、1つのsendrecvストリームの代わりに1recvonly。 2つのストリームにおけるデータフローは、異なったレンダラーを使用するために構成された受信機を制御するためにそれぞれ反対の方向に移動します。 Appendix C.5における3番目の例では、私たちはmusicportパラメタが仮想のsendrecvストリームを定義するのにどう使用されるかもしれないかを示しています。
Lazzaro & Wawrzynek Standards Track [Page 96] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[96ページ]。
As a general rule, the RTP MIDI protocol does not handle parameter changes during a session well, because the parameters describe heavyweight or stateful configuration that is not easily changed once a session has begun. Thus, parties SHOULD NOT expect that parameter change requests during a session will be accepted by other parties. However, implementors SHOULD support in-session parameter changes that are easy to handle (for example, the guardtime parameter defined in Appendix C.4) and SHOULD be capable of accepting requests for changes of those parameters, as received by its session management protocol (for example, re-offers in SIP [RFC3264]).
概して、RTP MIDIプロトコルはセッションの間、パラメータ変動をよく扱いません、パラメタがセッションがいったん始まると容易に変えられないヘビー級の、または、statefulな構成について説明するので。 したがって、SHOULD NOTが、そのパラメータ変動がセッションの間、要求すると予想するパーティーは相手によって受け入れられるでしょう。 しかしながら、作成者SHOULDはセッションにおける(例えばAppendix C.4で定義されたguardtimeパラメタ)とSHOULDを扱うのが簡単であることが、それらのパラメタの変化を求める要求を受け入れることができます、セッション管理が受け取るように議定書を作るということであるということであるパラメータ変動(例えば、SIP[RFC3264]の再申し出)をサポートします。
Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC4234]) syntax for the payload parameters. Section 11 provides information to the Internet Assigned Numbers Authority (IANA) on the media types and parameters defined in this document.
付録DはペイロードパラメタのためにAugmented BN記法(ABNF、[RFC4234])構文を定義します。 セクション11はメディアのAuthority(IANA)がタイプして、パラメタが本書では定義したインターネットAssigned民数記に情報を提供します。
Appendix C.6.5 defines the media type "audio/asc", a stored object for initializing mpeg4-generic renderers. As described in Appendix C.6, the audio/asc media type is assigned to the "rinit" parameter to specify an initialization data object for the default mpeg4-generic renderer. Note that RTP stream semantics are not defined for "audio/asc". Therefore, the "asc" subtype MUST NOT appear on the rtpmap line of a session description.
付録C.6.5は初期値設定mpeg4-ジェネリックレンダラーのためにメディアタイプ「オーディオ/asc」、保存されたオブジェクトを定義します。 Appendix C.6で説明されるように、オーディオ/ascメディアタイプはデフォルトmpeg4-ジェネリックレンダラーに初期化データ・オブジェクトを指定するために"rinit"パラメタに選任されます。 RTPストリーム意味論が「オーディオ/asc」のために定義されないことに注意してください。 したがって、"asc"「副-タイプ」はセッション記述のrtpmap系列に現れてはいけません。
C.1. Configuration Tools: Stream Subsetting
C.1。 構成ツール: ストリームSubsetting
As defined in Section 3.2 in the main text, the MIDI list of an RTP MIDI packet may encode any MIDI command that may legally appear on a MIDI 1.0 DIN cable.
主なテキストでセクション3.2で定義されるように、RTP MIDIパケットのMIDIリストはMIDI1.0DINケーブルの上に法的に現れるどんなMIDIコマンドもコード化するかもしれません。
In this appendix, we define two parameters (cm_unused and cm_used) that modify this default condition, by excluding certain types of MIDI commands from the MIDI list of all packets in a stream. For example, if a multimedia session partitions a MIDI name space into two RTP MIDI streams, the parameters may be used to define which commands appear in each stream.
この付録では、私たちはこのデフォルト条件を変更する2つのパラメタ(未使用とcm_が使用したcm_)を定義します、絶え間なくすべてのパケットのMIDIリストに、あるタイプのMIDIコマンドを入れないようにすることによって。 例えば、マルチメディアセッションがMIDI名前スペースを2つのRTP MIDIストリームに仕切るなら、パラメタは、どのコマンドが各ストリームに現れるかを定義するのに使用されるかもしれません。
In this appendix, we define a simple language for specifying MIDI command types. If a command type is assigned to cm_unused, the commands coded by the string MUST NOT appear in the MIDI list. If a command type is assigned to cm_used, the commands coded by the string MAY appear in the MIDI list.
この付録では、私たちは、MIDIコマンドタイプを指定するために簡単な言語を定義します。 コマンドタイプがcm_に未使用で選任されるなら、ストリングによってコード化されたコマンドはMIDIリストに現れてはいけません。 コマンドタイプが_が使用したcmに選任されるなら、ストリングによってコード化されたコマンドはMIDIリストに現れるかもしれません。
The parameter list may code multiple assignments to cm_used and cm_unused. Assignments have a cumulative effect and are applied in the order of appearance in the parameter list. A later assignment of a command type to the same parameter expands the scope of the earlier assignment. A later assignment of a command type to the opposite
パラメータ・リストは_が使用したcmとcm_に複数の課題を未使用でコード化するかもしれません。 課題は、累積している効果を持って、パラメータ・リストにおける外観の注文で適用されます。 同じパラメタへのコマンドタイプの後の課題は以前の課題の範囲を広くします。 正反対へのコマンドタイプの後の課題
Lazzaro & Wawrzynek Standards Track [Page 97] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[97ページ]。
parameter cancels (partially or completely) the effect of an earlier assignment.
パラメタは以前の課題の効果を取り消します(部分的か完全に)。
To initialize the stream subsetting system, "implicit" assignments to cm_unused and cm_used are processed before processing the actual assignments that appear in the parameter list. The System Common undefined commands (0xF4, 0xF5) and the System Real-Time Undefined commands (0xF9, 0xFD) are implicitly assigned to cm_unused. All other command types are implicitly assigned to cm_used.
ストリーム副設定システムを初期化するために、未使用とcm_が使用したcm_への「暗黙」の課題は処理する前に、処理されます。 System Commonの未定義のコマンド(0xF4、0xF5)とSystemレアル-時間Undefinedコマンド(0xF9、0xFD)はそれとなくcm_に未使用で割り当てられます。 他のすべてのコマンドタイプがそれとなく_が使用したcmに選任されます。
Note that the implicit assignments code the default behavior of an RTP MIDI stream as defined in Section 3.2 in the main text (namely, that all commands that may legally appear on a MIDI 1.0 DIN cable may appear in the stream). Also note that assignments of the System Common undefined commands (0xF4, 0xF5) apply to the use of these commands in the MIDI source command stream, not the special use of 0xF4 and 0xF5 in SysEx segment encoding defined in Section 3.2 in the main text.
暗黙の課題が主なテキストでセクション3.2で定義されるようにRTP MIDIストリームのデフォルトの振舞いをコード化することに注意してください(すなわち、ストリームですべてが、それがMIDI1.0DINケーブルの上に法的に現れるかもしれないと命令するように見えるかもしれません)。 また、System Commonの未定義のコマンド(0xF4、0xF5)の課題が主なテキストでセクション3.2で定義されたSysExセグメントコード化における0xF4と0xF5の特別な使用ではなく、MIDIソースコマンドストリームにおけるこれらのコマンドの使用に適用されることに注意してください。
As a rule, parameter assignments obey the following syntax (see Appendix D for ABNF):
原則として、パラメタ課題は以下の構文に従います(ABNFに関してAppendix Dを見てください):
<parameter> = [channel list]<command-type list>[field list]
<パラメタ>=[チャンネルリスト]<コマンドタイプリスト>。[分野リスト]
The command-type list is mandatory; the channel and field lists are optional.
コマンド型の並びは義務的です。 チャンネルと分野リストは任意です。
The command-type list specifies the MIDI command types for which the parameter applies. The command-type list is a concatenated sequence of one or more of the letters (ABCFGHJKMNPQTVWXYZ). The letters code the following command types:
コマンド型の並びはパラメタが申し込まれるMIDIコマンドタイプを指定します。 コマンド型の並びは手紙(ABCFGHJKMNPQTVWXYZ)の1つ以上の連結された系列です。 手紙は以下のコマンドタイプをコード化します:
o A: Poly Aftertouch (0xA)
o B: System Reset (0xFF)
o C: Control Change (0xB)
o F: System Time Code (0xF1)
o G: System Tune Request (0xF6)
o H: System Song Select (0xF3)
o J: System Common Undefined (0xF4)
o K: System Common Undefined (0xF5)
o N: NoteOff (0x8), NoteOn (0x9)
o P: Program Change (0xC)
o Q: System Sequencer (0xF2, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC)
o T: Channel Aftertouch (0xD)
o V: System Active Sense (0xFE)
o W: Pitch Wheel (0xE)
o A: ポリーAftertouch(0xA)o B: システムReset(0xFF)o C: Change(0xB)o Fを制御してください: システムTime Code(0xF1)o G: システムTune Request(0xF6)o H: システムSong Select(0xF3)o J: システムCommon Undefined(0xF4)o K: システムCommon Undefined(0xF5)o N: NoteOff(0×8)、NoteOn(0×9)o P: Change(0xC)o Qをプログラムしてください: システムSequencer(0xF2、0xF8、0xF9、0xFA、0xFB、0xFC)o T: チャンネルAftertouch(0xD)o V: システムActive Sense(0xFE)o W: 大歯車(0xE)
Lazzaro & Wawrzynek Standards Track [Page 98] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[98ページ]。
o X: SysEx (0xF0)
o Y: System Real-Time Undefined (0xF9)
o Z: System Real-Time Undefined (0xFD)
o X: SysEx(0xF0)o Y: システムレアル-時間Undefined(0xF9)o Z: システムリアルタイムで、未定義(0xFD)
In addition to the letters above, the letter M may also appear in the command-type list. The letter M refers to the MIDI parameter system (see definition in Appendix A.1 and in [MIDI]). An assignment of M to cm_unused codes that no RPN or NRPN transactions may appear in the MIDI list.
また、手紙に加えて、上に、文字Mはコマンド型の並びに現れるかもしれません。 文字MはMIDIパラメタシステムを示します(Appendix A.1と[MIDI]との定義を見てください)。 トランザクションがMIDIリストで見えるかもしれないcmの_の未使用のコードのMからそのノーRPNかNRPNの課題。
Note that if cm_unused is assigned the letter M, Control Change (0xB) commands for the controller numbers in the standard controller assignment might still appear in the MIDI list. For an explanation, see Appendix A.3.4 for a discussion of the "general-purpose" use of parameter system controller numbers.
cmであるならそれに注意してください。_未使用であることは、文字Mが割り当てられる場合、標準のコントローラ課題におけるコントローラ番号のためのControl Change(0xB)コマンドがMIDIリストにまだ現れているかもしれないということです。 説明に関しては、パラメタシステムコントローラ番号の「汎用」使用の議論に関してAppendix A.3.4を見てください。
In the text below, rules that apply to "MIDI voice channel commands" also apply to the letter M.
また、以下のテキストでは、「MIDI声のチャネル指令」に適用される規則は文字Mに適用されます。
The letters in the command-type list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCFGHJKMNPQTVWXYZ) that appear in the list MUST be ignored.
コマンド型の並びの手紙は、大文字しなければならなくて、アルファベット順に現れなければなりません。 リストに現れる(ABCFGHJKMNPQTVWXYZ)を除いた手紙を無視しなければなりません。
For MIDI voice channel commands, the channel list specifies the MIDI channels for which the parameter applies. If no channel list is provided, the parameter applies to all MIDI channels (0-15). The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc). Dots (i.e., "." characters) separate elements in the channel list.
MIDI声のチャネル指令として、チャンネルリストはパラメタが申し込まれるMIDIチャンネルを指定します。 チャンネルリストを全く提供しないなら、パラメタはすべてのMIDIチャンネル(0-15)に適用されます。 チャンネルリストは論理機番(0〜15)とダッシュで切り離された論理機番範囲(すなわち、0-5、8-12など)のリストの形を取ります。 「ドット(」 . 」 すなわち、キャラクタ)はチャンネルリストで要素を切り離します。
Recall that System commands do not have a MIDI channel associated with them. Thus, for most command-type letters that code System commands (B, F, G, H, J, K, Q, V, Y, and Z), the channel list is ignored.
SystemコマンドでMIDIチャンネルをそれらに関連づけないと思い出してください。 したがって、コードSystemが命令するほとんどのコマンドタイプライターの活字(B、F、G、H、J、K、Q、V、Y、およびZ)に関して、チャンネルリストは無視されます。
For the command-type letter X, the appearance of certain numbers in the channel list codes special semantics.
コマンドタイプライターの活字Xに関しては、チャンネルリストにおける、ある数の外観は特別な意味論をコード化します。
o The digit 0 codes that SysEx "cancel" sublists (Section 3.2 in
the main text) MUST NOT appear in the MIDI list.
o ケタ0はサブリスト(主なテキストのセクション3.2)がMIDIリストで見えてはいけないそのSysEx「キャンセル」をコード化します。
o The digit 1 codes that cancel sublists MAY appear in the MIDI
list (the default condition).
o サブリストを取り消すケタ1コードはMIDIリスト(デフォルト条件)に現れるかもしれません。
o The digit 2 codes that commands other than System Real-time MIDI
commands MUST NOT appear between SysEx command segments in the
MIDI list (the default condition).
o Systemレアル-時間MIDIコマンド以外のコマンドがMIDIのSysExコマンドセグメントの間で見えてはいけないケタ2コードは(デフォルト条件)を記載します。
Lazzaro & Wawrzynek Standards Track [Page 99] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[99ページ]。
o The digit 3 codes that any MIDI command type may appear between
SysEx command segments in the MIDI list, with the exception of
the segmented encoding of a second SysEx command (verbatim SysEx
commands are OK).
o 2番目のSysExコマンドの区分されたコード化を除いて、どんなMIDIコマンドもMIDIのSysExコマンドセグメントの間に現れるかもしれないのをタイプするケタ3コードは記載します(逐語的なSysExコマンドはOKです)。
For command-type X, the channel list MUST NOT contain both digits 0 and 1, and it MUST NOT contain both digits 2 and 3. For command-type X, channel list numbers other than the numbers defined above are ignored. If X does not have a channel list, the semantics marked "the default condition" in the list above apply.
コマンドでタイプしているXに関しては、チャンネルリストは両方のケタ0と1を含んではいけなくて、それは両方のケタ2と3を含んではいけません。 コマンドでタイプしているXに関しては、上で定義された数以外のチャンネルリスト番号は無視されます。 Xにチャンネルリストがないなら、上記のリストの「デフォルト条件」であるとマークされた意味論は適用されます。
The syntax for field lists in a parameter assignment follows the syntax for channel lists. If no field list is provided, the parameter applies to all controller or note numbers.
パラメタ課題における分野リストのための構文はチャンネルリストのための構文に従います。 分野リストを全く提供しないなら、パラメタはすべてのコントローラか注意番号に適用されます。
For command-type C (Control Change), the field list codes the controller numbers (0-255) for which the parameter applies.
コマンドタイプC(コントロールChange)のために、分野リストはパラメタが申し込まれるコントローラ番号(0-255)をコード化します。
For command-type M (Parameter System), the field list codes the Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the parameter applies. The number range 0-16383 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 corresponds to NRPN 16383).
コマンドタイプM(パラメタSystem)のために、分野リストはパラメタが申し込まれるRegistered Parameter民数記(RPNs)とNonによって登録されたParameter民数記(NRPNs)をコード化します。 数の範囲0-16383はRPNsを指定して、数の範囲16384-32767はNRPNsを指定します(16384がNRPN0に対応している、32767はNRPN16383に対応しています)。
For command-types N (NoteOn and NoteOff) and A (Poly Aftertouch), the field list codes the note numbers for which the parameter applies.
コマンドタイプN(NoteOnとNoteOff)とA(ポリーAftertouch)のために、分野リストはパラメタが申し込まれる注意番号をコード化します。
For command-types J and K (System Common Undefined), the field list consists of a single digit, which specifies the number of data octets that follow the command octet.
コマンドタイプJとK(システムCommon Undefined)のために、分野リストは一桁から成ります。(それは、コマンド八重奏に続くデータ八重奏の数を指定します)。
For command-type X (SysEx), the field list codes the number of data octets that may appear in a SysEx command. Thus, the field list 0-255 specifies SysEx commands with 255 or fewer data octets, the field list 256-4294967295 specifies SysEx commands with more than 255 data octets but excludes commands with 255 or fewer data octets, and the field list 0 excludes all commands.
コマンドタイプX(SysEx)に関しては、分野リストはSysExコマンドに現れるかもしれないデータ八重奏の数をコード化します。 したがって、分野リスト0-255は255か、より少ないデータ八重奏でSysExコマンドを指定します、そして、分野リスト256-4294967295は、255以上のデータ八重奏でSysExコマンドを指定しますが、255か、より少ないデータ八重奏でコマンドを除きます、そして、分野リスト0はすべてのコマンドを除きます。
A secondary parameter assignment syntax customizes command-type X (see Appendix D for complete ABNF):
セカンダリパラメタ課題構文はコマンドでタイプしているXをカスタム設計します(完全なABNFに関してAppendix Dを見てください):
<parameter> = "__" <h-list> ["_" <h-list>] "__"
<パラメタ>="__"<h-リスト>["_"<h-リスト>]"__"
The assignment defines the class of SysEx commands that obeys the semantics of the assigned parameter. The command class is specified by listing the permitted values of the first N data octets that follow the SysEx 0xF0 command octet. Any SysEx command whose first N data octets match the list is a member of the class.
課題は割り当てられたパラメタの意味論に従うSysExコマンドのクラスを定義します。 コマンドのクラスは、SysEx 0xF0コマンド八重奏に続く最初のNデータ八重奏の受入れられた値を記載することによって、指定されます。 最初のNデータ八重奏がリストに合っているどんなSysExコマンドもクラスの一員です。
Lazzaro & Wawrzynek Standards Track [Page 100] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[100ページ]。
Each <h-list> defines a data octet of the command, as a dot-separated
(".") list of one or more hexadecimal constants (such as "7F") or
dash-separated hexadecimal ranges (such as "01-1F"). Underscores
("_") separate each <h-list>. Double-underscores ("__") delineate
the data octet list.
それぞれの<h-リスト>がコマンドのデータ八重奏をaとドットによって切り離された状態で定義する、(「」、)、1つ以上の16進定数(「7F」などの)かダッシュで切り離された16進範囲(「01-1F」などの)のリスト。 強調("_")はそれぞれの<h-リスト>を切り離します。 二重強調("__")はデータ八重奏リストを図で表わします。
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to cm_used and cm_unused to specify complex behaviors.
この構文を使用して、各課題は1つのSysExコマンドのクラスを指定します。 セッション記述はいくつかの課題を複雑な振舞いを指定するためには未使用の_が使用したcmとcm_まで使用するかもしれません。
The example session description below illustrates the use of the stream subsetting parameters:
以下での例のセッション記述はパラメタを副設定するストリームの使用を例証します:
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 rtp-ミディ/44100a=fmtp: 96cmの_未使用の=ACGHJKNMPTVWXYZ。 cm_は_01_01__を=__7F_00-7F使用しました。
The session description configures the stream for use in clock applications. All voice channels are unused, as are all System Commands except those used for MIDI Time Code (command-type F, and the Full Frame SysEx command that is matched by the string assigned to cm_used), the System Sequencer commands (command-type Q), and System Reset (command-type B).
セッション記述は時計アプリケーションにおける使用のためにストリームを構成します。 すべての音声チャンネルが未使用です、MIDI Time Code(F、および_が使用したcmに割り当てられたストリングによって合わせられているFull Frame SysExコマンドをコマンドでタイプする)に使用されるもの以外のすべてのSystem Commands、System Sequencerコマンド(Qをコマンドでタイプする)、およびSystem Resetのように(Bをコマンドでタイプしてください)。
C.2. Configuration Tools: The Journalling System
C.2。 構成ツール: Journallingシステム
In this appendix, we define the payload format parameters that configure stream journalling and the recovery journal system.
この付録では、私たちは流れのjournallingを構成するペイロード形式パラメタと回復ジャーナルシステムを定義します。
The j_sec parameter (Appendix C.2.1) sets the journalling method for the stream. The j_update parameter (Appendix C.2.2) sets the recovery journal sending policy for the stream. Appendix C.2.2 also defines the sending policies of the recovery journal system.
j_秒のパラメタ(付録C.2.1)は流れのためのjournalling方法を設定します。 j_アップデートパラメタ(付録C.2.2)は流れのための回復ジャーナル送付方針を設定します。 また、付録C.2.2は回復ジャーナルシステムの送付方針を定義します。
Appendix C.2.3 defines several parameters that modify the recovery journal semantics. These parameters change the default recovery journal semantics as defined in Section 5 and Appendices A-B.
付録C.2.3は回復ジャーナル意味論を変更するいくつかのパラメタを定義します。 これらのパラメタはセクション5とAppendices A-Bで定義されるようにデフォルト回復ジャーナル意味論を変えます。
The journalling method for a stream is set at the start of a session and MUST NOT be changed thereafter. This requirement forbids changes to the j_sec parameter once a session has begun.
流れのためのjournalling方法をセッションの始めに設定して、その後、変えてはいけません。 セッションがいったん始まると、この要件はj_秒への変化にパラメタを禁じます。
Lazzaro & Wawrzynek Standards Track [Page 101] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[101ページ]。
A related requirement, defined in the appendix sections below, forbids the acceptance of parameter values that would violate the recovery journal mandate. In many cases, a change in one of the parameters defined in this appendix during an ongoing session would result in a violation of the recovery journal mandate for an implementation; in this case, the parameter change MUST NOT be accepted.
下の付録部分で定義された関連する要件は回復ジャーナル命令に違反するパラメタ値の承認を禁じます。 多くの場合、進行中のセッションの間この付録で定義されたパラメタの1つにおける変化は実現のための回復ジャーナル命令の違反をもたらすでしょう。 この場合、パラメータ変動を受け入れてはいけません。
C.2.1. The j_sec Parameter
C.2.1。 j_秒のParameter
Section 2.2 defines the default journalling method for a stream. Streams that use unreliable transport (such as UDP) default to using the recovery journal. Streams that use reliable transport (such as TCP) default to not using a journal.
セクション2.2は流れのためのデフォルトjournalling方法を定義します。 頼り無い輸送(UDPなどの)を使用する流れが回復ジャーナルを使用するのをデフォルトとします。 信頼できる輸送(TCPなどの)を使用する流れがジャーナルを使用しないのをデフォルトとします。
The parameter j_sec may be used to override this default. This memo defines two symbolic values for j_sec: "none", to indicate that all stream payloads MUST NOT contain a journal section, and "recj", to indicate that all stream payloads MUST contain a journal section that uses the recovery journal format.
パラメタj_秒は、このデフォルトをくつがえすのに使用されるかもしれません。 このメモはj_秒のための2つのシンボリックな値を定義します: 「なにもに、」すべての流れのペイロードがすべての流れのペイロードがジャーナル部を含まなければならないのを示すためにジャーナル部、および"recj"を含んではいけないのを示すために、それは回復ジャーナル形式を使用します。
For example, the j_sec parameter might be set to "none" for a UDP stream that travels between two hosts on a local network that is known to provide reliable datagram delivery.
例えば、パラメタがUDPの流れのための「なにも」に設定されるかもしれないj_秒のときに、それは信頼できるデータグラム配信を提供するのが知られている企業内情報通信網の2人のホストの間を旅行します。
The session description below configures a UDP stream that does not use the recovery journal:
以下でのセッション記述は回復ジャーナルを使用しないUDPの流れを構成します:
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 j_sec=none
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap:96rtp-ミディ/44100a=fmtp:96j_秒はなにもと等しくはありません。
Other IETF standards-track documents may define alternative journal formats. These documents MUST define new symbolic values for the j_sec parameter to signal the use of the format.
他のIETF標準化過程文書は代替のジャーナル書式を定義するかもしれません。 これらのドキュメントはj_秒のための新しいシンボリックな値を定義しなければなりません。形式の使用に合図するパラメタ。
Parties MUST NOT accept a j_sec value that violates the recovery journal mandate (see Section 4 for details). If a session description uses a j_sec value unknown to the recipient, the recipient MUST NOT accept the description.
党は回復ジャーナル命令に違反する値をj_秒受け入れてはいけません(詳細に関してセクション4を見てください)。 セッション記述がj_秒を使用するなら、受取人、受取人にとっての、未知の値は記述を受け入れてはいけません。
Lazzaro & Wawrzynek Standards Track [Page 102] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[102ページ]。
Special j_sec issues arise when sessions are managed by session management tools (like RTSP, [RFC2326]) that use SDP for "declarative usage" purposes (see the preamble of Section 6 for details). For these session management tools, SDP does not code transport details (such as UDP or TCP) for the session. Instead, server and client negotiate transport details via other means (for RTSP, the SETUP method).
「叙述的な用法」目的にSDPを使用するセッション管理ツール(RTSP、[RFC2326]のような)によってセッションが管理されるとき(詳細に関してセクション6に関する序文を見てください)、_秒が発行する特別番組jは起こります。 これらのセッション管理ツールのために、SDPはセッションのための輸送の詳細(UDPかTCPなどの)をコード化しません。 代わりに、他の手段(RTSPのためのSETUP方法)でサーバとクライアントは輸送の詳細を交渉します。
In this scenario, the use of the j_sec parameter may be ill-advised, as the creator of the session description may not yet know the transport type for the session. In this case, the session description SHOULD configure the journalling system using the parameters defined in the remainder of Appendix C.2, but it SHOULD NOT use j_sec to set the journalling status. Recall that if j_sec does not appear in the session description, the default method for choosing the journalling method is in effect (no journal for reliable transport, recovery journal for unreliable transport).
このシナリオ、パラメタがあさはかであるかもしれないj_秒の使用で、セッション記述の創造者がまだ輸送を知っていないかもしれないように、セッションのためにタイプしてください。 この場合、記述SHOULDがSHOULD NOTがj_秒を使用するしかし、Appendix C.2、それの残りで定義されたパラメタを使用することでjournallingシステムを構成するセッションはjournalling状態を設定しました。 事実上、j_秒がセッション記述に現れないなら、journalling方法を選ぶためのデフォルト方法が(信頼できる輸送のためのジャーナルがない、頼り無い輸送のための回復ジャーナル)であると思い出してください。
However, in declarative usage situations where the creator of the session description knows that journalling is always required or never required, the session description SHOULD use the j_sec parameter.
しかしながら、セッション記述の創造者がjournallingはいつも必要である、または決して必要でないことを知っている叙述的な用法状況で、セッション記述SHOULDがj_秒を使用します。パラメタ。
C.2.2. The j_update Parameter
C.2.2。 j_アップデートParameter
In Section 4, we use the term "sending policy" to describe the method a sender uses to choose the checkpoint packet identity for each recovery journal in a stream. In the sub-sections that follow, we normatively define three sending policies: anchor, closed-loop, and open-loop.
セクション4では、私たちは、それぞれの回復ジャーナルのために絶え間なく送付者がチェックポイントパケットのアイデンティティを選ぶのに使用する方法を説明するために「方針を送り」ながら、用語を使用します。 続く小区分では、私たちは標準に3つの送付方針を定義します: 閉ループしていて、開いている輪のアンカー。
As stated in Section 4, the default sending policy for a stream is the closed-loop policy. The j_update parameter may be used to override this default.
セクション4に述べられているように、流れのためのデフォルト送付方針は閉ループ方針です。 j_アップデートパラメタは、このデフォルトをくつがえすのに使用されるかもしれません。
We define three symbolic values for j_update: "anchor", to indicate that the stream uses the anchor sending policy, "open-loop", to indicate that the stream uses the open-loop sending policy, and "closed-loop", to indicate that the stream uses the closed-loop sending policy. See Appendix C.2.3 for examples session descriptions that use the j_update parameter.
私たちはj_のためのシンボリックな値がアップデートする3を定義します: 「アンカー」、流れがそれを示すのに「開いている輪」のアンカー送付方針を使用するのを示すのに、流れは転々流通送付方針を使用します、そして、「閉ループしてい」て、それを示すのに、流れが閉ループ送付方針を使用します。 j_アップデートパラメタを使用する例のセッション記述に関してAppendix C.2.3を見てください。
Parties MUST NOT accept a j_update value that violates the recovery journal mandate (Section 4).
党は回復ジャーナル命令(セクション4)に違反するj_アップデート値を受け入れてはいけません。
Other IETF standards-track documents may define additional sending policies for the recovery journal system. These documents MUST define new symbolic values for the j_update parameter to signal the
他のIETF標準化過程文書は回復ジャーナルシステムのために追加送付方針を定義するかもしれません。 これらのドキュメントはj_アップデートパラメタが示す新しいシンボリックな値を定義しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 103] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[103ページ]。
use of the new policy. If a session description uses a j_update value unknown to the recipient, the recipient MUST NOT accept the description.
新しい政策の使用。 セッション記述が受取人にとっての、未知のj_アップデート値を使用するなら、受取人は記述を受け入れてはいけません。
C.2.2.1. The anchor Sending Policy
C.2.2.1。 アンカーSending Policy
In the anchor policy, the sender uses the first packet in the stream as the checkpoint packet for all packets in the stream. The anchor policy satisfies the recovery journal mandate (Section 4), as the checkpoint history always covers the entire stream.
アンカー方針で、送付者はすべてのパケットにチェックポイントパケットとして流れに最初のパケットを流れに使用します。 チェックポイント歴史がいつも全体の流れをカバーするとき、アンカー方針は回復ジャーナル命令(セクション4)を満たします。
The anchor policy does not require the use of the RTP control protocol (RTCP, [RFC3550]) or other feedback from receiver to sender. Senders do not need to take special actions to ensure that received streams start up free of artifacts, as the recovery journal always covers the entire history of the stream. Receivers are relieved of the responsibility of tracking the changing identity of the checkpoint packet, because the checkpoint packet never changes.
アンカー方針はRTP制御プロトコル(RTCP、[RFC3550])か他のフィードバックの受信機から送付者までの使用を必要としません。 送付者は容認された流れが人工物から無料で始動するのを保証するために特別な行動を取る必要はありません、回復ジャーナルがいつも流れの全体の歴史をカバーするとき。 チェックポイントパケットの変化のアイデンティティを追跡する責任を受信機に取り除きます、チェックポイントパケットが決して変化しないので。
The main drawback of the anchor policy is bandwidth efficiency. Because the checkpoint history covers the entire stream, the size of the recovery journals produced by this policy usually exceeds the journal size of alternative policies. For single-channel MIDI data streams, the bandwidth overhead of the anchor policy is often acceptable (see Appendix A.4 of [NMP]). For dense streams, the closed-loop or open-loop policies may be more appropriate.
アンカー方針の主な欠点は帯域幅効率です。 チェックポイント歴史が全体の流れをカバーしているので、通常、この方針で製作された回復ジャーナルのサイズは代替的政策のジャーナルサイズを超えています。 単独のチャンネルMIDIデータ・ストリームにおいて、アンカー方針の帯域幅オーバーヘッドはしばしば許容できます([NMP]のAppendix A.4を見てください)。 濃い流れにおいて、閉ループしているか開いている輪の方針は、より適切であるかもしれません。
C.2.2.2. The closed-loop Sending Policy
C.2.2.2。 閉ループSending Policy
The closed-loop policy is the default policy of the recovery journal system. For each packet in the stream, the policy lets senders choose the smallest possible checkpoint history that satisfies the recovery journal mandate. As smaller checkpoint histories generally yield smaller recovery journals, the closed-loop policy reduces the bandwidth of a stream, relative to the anchor policy.
閉ループ方針は回復ジャーナルシステムのデフォルト方針です。 流れにおける各パケットに関しては、方針で、送付者は回復ジャーナル命令を満たす可能な限りわずかなチェックポイント歴史を選ぶことができます。 一般に、よりわずかなチェックポイント歴史が、より小さい回復ジャーナルをもたらすのに従って、閉ループ方針は流れの帯域幅を減少させます、アンカー方針に比例して。
The closed-loop policy relies on feedback from receiver to sender. The policy assumes that a receiver periodically informs the sender of the highest sequence number it has seen so far in the stream, coded in the 32-bit extension format defined in [RFC3550]. For RTCP, receivers transmit this information in the Extended Highest Sequence Number Received (EHSNR) field of Receiver Reports. RTCP Sender or Receiver Reports MUST be sent by any participant in a session with closed loop sending policy, unless another feedback mechanism has been agreed upon.
閉ループ方針は受信機から送付者までフィードバックを当てにします。 方針は、受信機が定期的に今までのところ[RFC3550]で定義された32ビットの拡大書式でコード化された流れで見た中で最も高い一連番号について送付者に知らせると仮定します。 RTCPに関しては、受信機はReceiver ReportsのExtended Highest Sequence Number Received(EHSNR)分野でこの情報を伝えます。 どんな関係者も方針を送るクローズドループとのセッションのときにRTCP SenderかReceiver Reportsを送らなければなりません、別のフィードバック・メカニズムが同意されていない場合。
Lazzaro & Wawrzynek Standards Track [Page 104] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[104ページ]。
The sender may safely use receiver sequence number feedback to guide checkpoint history management, because Section 4 requires that receivers repair indefinite artifacts whenever a packet loss event occur.
送付者はチェックポイント歴史管理を誘導するのに安全に受信機一連番号フィードバックを使用するかもしれません、セクション4が、パケット損失出来事が起こるときはいつも、受信機が無期人工物を修理するのを必要とするので。
We now normatively define the closed-loop policy. At the moment a sender prepares an RTP packet for transmission, the sender is aware of R >= 0 receivers for the stream. Senders may become aware of a receiver via RTCP traffic from the receiver, via RTP packets from a paired stream sent by the receiver to the sender, via messages from a session management tool, or by other means. As receivers join and leave a session, the value of R changes.
私たちは現在、標準に閉ループ方針を定義します。 流れにおいて、送付者は現在、送付者がトランスミッションのためにRTPパケットを準備するのを0台のR>=受信機を意識しています。 Sendersは受信機からのRTCP交通を通して受信機を意識するようになるかもしれません、受信機によって送られた対にされた流れから送付者までのRTPパケットを通して、セッション管理ツール、または他の手段によるメッセージで。 受信機がセッションに参加して、出発するのに従って、Rの値は変化します。
Each known receiver k (1 <= k <= R) is associated with a 32-bit extended packet sequence number M(k), where the extension reflects the sequence number rollover count of the sender.
それぞれの知られている受信機k(1<がk<=Rと等しいです)は32ビットの拡張パケット一連番号M(k)に関連しています。そこでは、拡大が送付者の一連番号ロールオーバーカウントを反映します。
If the sender has received at least one feedback report from receiver k, M(k) is the most recent report of the highest RTP packet sequence number seen by the receiver, normalized to reflect the rollover count of the sender.
送付者が受信機kから少なくとも1つのフィードバックレポートを受け取ったなら、M(k)は送付者のロールオーバーカウントを反映するために正常にされた受信機によって見られる中で最も高いRTPパケット一連番号の最新のレポートです。
If the sender has not received a feedback report from the receiver, M(k) is the extended sequence number of the last packet the sender transmitted before it became aware of the receiver. If the sender became aware of this receiver before it sent the first packet in the stream, M(k) is the extended sequence number of the first packet in the stream.
送付者が受信機からフィードバックレポートを受け取っていないなら、受信機を意識するようになる前にM(k)は送付者が伝えた最後のパケットの拡張配列番号です。流れで最初のパケットを送る前に送付者がこの受信機を意識するようになったなら、M(k)は流れにおいて、最初のパケットの拡張配列番号です。
Given this definition of M(), we now state the closed-loop policy. When preparing a new packet for transmission, a sender MUST choose a checkpoint packet with extended sequence number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. The policy does not restrict sender behavior in the R == 0 (no known receivers) case.
M()のこの定義を考えて、私たちは現在、閉ループ方針を述べます。 トランスミッションのために新しいパケットを準備するとき、送付者は拡張配列No.N、k<=R、どこR M(k)>がすべてのkのための(N--1)、1<と等しいようなもの=>=1があるチェックポイントパケットを選ばなければならないか。 方針は0(知られている受信機がない)R=場合における送付者の振舞いを制限しません。
Under the closed-loop policy as defined above, a sender may transmit packets whose checkpoint history is shorter than the session history (as defined in Appendix A.1). In this event, a new receiver that joins the stream may experience indefinite artifacts.
上で定義される閉ループ方針の下では、送付者はチェックポイント歴史がセッション歴史より短いパケットを伝えるかもしれません(Appendix A.1で定義されるように)。 この出来事では、流れに参加する新しい受信機は無期人工物を経験するかもしれません。
For example, if a Control Change (0xB) command for Channel Volume (controller number 7) was sent early in a stream, and later a new receiver joins the session, the closed-loop policy may permit all packets sent to the new receiver to use a checkpoint history that does not include the Channel Volume Control Change command. As a result, the new receiver experiences an indefinite artifact, and plays all notes on a channel too loudly or too softly.
例えば、早く絶え間なくChannel Volume(コントローラNo.7)のためのControl Change(0xB)コマンドを送って、新しい受信機が後でセッションに参加するなら、閉ループ方針は、新しい受信機に送られたすべてのパケットが英仏海峡Volume Control Changeコマンドを含んでいないチェックポイント歴史を費やすことを許可するかもしれません。 その結果、新しい受信機は、あまりにやかましいかあまりに静かに無期人工物を経験して、チャンネルに関するすべての音符を演奏します。
Lazzaro & Wawrzynek Standards Track [Page 105] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[105ページ]。
To address this issue, the closed-loop policy states that whenever a sender becomes aware of a new receiver, the sender MUST determine if the receiver would be subject to indefinite artifacts under the closed-loop policy. If so, the sender MUST ensure that the receiver starts the session free of indefinite artifacts.
この問題を記述するために、閉ループ方針は、新しい受信機を意識するようになるときはいつも、送付者が、受信機は閉ループ方針の下において無期人工物を受けることがあるかどうかと決心しなければならないと述べます。 そうだとすれば、送付者は、受信機が無期人工物を有でないセッションを始めるのを保証しなければなりません。
For example, to solve the Channel Volume issue described above, the sender may code the current state of the Channel Volume controller numbers in the recovery journal Chapter C, until it receives the first RTCP RR report that signals that a packet containing this Chapter C has been received.
例えば、上で説明された英仏海峡Volume問題を解決するために、送付者は英仏海峡Volumeでは、コントローラが回復ジャーナルで章Cに付番する現状をコード化するかもしれません、この章Cを含むパケットが受け取られたのを示す最初のRTCP RRレポートを受け取るまで。
In satisfying this requirement, senders MAY infer the initial MIDI state of the receiver from the session description. For example, the stream example in Section 6.2 has the initial state defined in [MIDI] for General MIDI.
この要件を満たす際に、送付者はセッション記述から受信機の初期のMIDI状態を推論するかもしれません。 例えば、セクション6.2の流れの例には、ジェネラルミディのために[MIDI]で定義された初期状態があります。
In a unicast RTP session, a receiver may safely assume that the sender is aware of its presence of a receiver from the first packet sent in the RTP stream. However, in other types of RTP sessions (multicast, conference focus, RTP translator/mixer), a receiver is often not able to determine if the sender is initially aware of its presence as a receiver.
ユニキャストRTPセッションのときに、受信機は、送付者がRTPの流れで送られた最初のパケットからの受信機の存在を意識していると安全に仮定するかもしれません。 しかしながら、他のタイプのRTPセッション(マルチキャスト、会議焦点、RTP翻訳者/ミキサー)のときに、受信機は、送付者が初めは受信機として存在を意識しているかどうかしばしば決定できるというわけではありません。
To address this issue, the closed-loop policy states that if a receiver participates in a session where it may have access to a stream whose sender is not aware of the receiver, the receiver MUST take actions to ensure that its rendered MIDI performance does not contain indefinite artifacts. These protections will be necessarily incomplete. For example, a receiver may monitor the Checkpoint Packet Seqnum for uncovered loss events, and "err on the side of caution" with respect to handling stuck notes due to lost MIDI NoteOff commands, but the receiver is not able to compensate for the lack of Channel Volume initialization data in the recovery journal.
この問題を記述するために、閉ループ方針は、受信機がそれが送付者が受信機を意識していない流れに近づく手段を持っているかもしれないセッションのときに関与するなら、受信機がレンダリングされたMIDI性能が無期人工物を含まないのを保証するために行動を取らなければならないと述べます。 これらの保護は必ず不完全になるでしょう。 例えば、受信機はむき出しの損失出来事のためにCheckpoint Packet Seqnumをモニターするかもしれません、そして、取り扱いに関する「警告の側で間違えてください」は無くなっているMIDI NoteOffコマンドのため注意を張り付けましたが、受信機は回復ジャーナルのChannel Volume初期化データの不足を補うことができません。
The receiver MUST NOT discontinue these protective actions until it is certain that the sender is aware of its presence. If a receiver is not able to ascertain sender awareness, the receiver MUST continue these protective actions for the duration of the session.
送付者が存在を意識しているのが、確かになるまで、受信機はこれらの保護的な動作を中止してはいけません。 受信機が送付者認識を確かめることができないなら、受信機はセッションの持続時間のためのこれらの保護的な動作を続けなければなりません。
Note that in a multicast session where all parties are expected to send and receive, the reception of RTCP receiver reports from the sender about the RTP stream a receiver is multicasting is evidence of the sender's awareness that the RTP stream multicast by the sender is being monitored by the receiver. Receivers may also obtain sender awareness evidence from session management tools, or by other means. In practice, ongoing observation of the Checkpoint Packet Seqnum to determine if the sender is taking actions to prevent loss events for
すべてのパーティーが発信して、受信すると予想されて、RTCP受信機のレセプションがRTPの流れに関する送付者から受信機がマルチキャスティングであると報告するマルチキャストセッションにおけるそれが送付者によるRTP流れのマルチキャストが受信機によってモニターされているという送付者の認識に関する証拠であることに注意してください。また、受信機はセッション管理ツール、または他の手段で送付者認識証拠を得てもよいです。 習慣、送付者が損失出来事を防ぐ行動を取っているかどうか決定するCheckpoint Packet Seqnumの進行中の観測で
Lazzaro & Wawrzynek Standards Track [Page 106] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[106ページ]。
a receiver is a good indication of sender awareness, as is the sudden appearance of recovery journal chapters with numerous Control Change controller data that was not foreshadowed by recent commands coded in the MIDI list shortly after sending an RTCP RR.
受信機は送付者認識の良いしるしです、RTCP RRを送ったすぐ後にMIDIリストでコード化された最近のコマンドで予示されなかった多数のControl Changeコントローラデータがある回復ジャーナル章の突然の外観のように。
The final set of normative closed-loop policy requirements concern how senders and receivers handle unplanned disruptions of RTCP feedback from a receiver to a sender. By "unplanned", we refer to disruptions that are not due to the signalled termination of an RTP stream, via an RTCP BYE or via session management tools.
要件が送付者と受信機がどうRTCPフィードバックの無計画な受信機から送付者までの分裂を扱うかに関する標準の閉ループ方針のファイナルセット。 「無計画」で、RTCP BYEを通してセッション管理ツールで私たちはRTPの流れの合図された終了のためでない分裂について言及します。
As defined earlier in this section, the closed-loop policy states that a sender MUST choose a checkpoint packet with extended sequence number N, such that M(k) >= (N - 1) for all k, 1 <= k <= R, where R >= 1. If the sender has received at least one feedback report from receiver k, M(k) is the most recent report of the highest RTP packet sequence number seen by the receiver, normalized to reflect the rollover count of the sender.
より早くこのセクションで定義されるように、k<=R、どこR送付者がM(k)>がすべてのkのための(N--1)、1<と等しいように拡張配列No.Nがあるチェックポイントパケットを選ばなければならない閉ループ政策ポジション=>=1であるか。 送付者が受信機kから少なくとも1つのフィードバックレポートを受け取ったなら、M(k)は送付者のロールオーバーカウントを反映するために正常にされた受信機によって見られる中で最も高いRTPパケット一連番号の最新のレポートです。
If this receiver k stops sending feedback to the sender, the M(k) value used by the sender reflects the last feedback report from the receiver. As time progresses without feedback from receiver k, this fixed M(k) value forces the sender to increase the size of the checkpoint history, and thus increases the bandwidth of the stream.
この受信機kが、フィードバックを送付者に送るのを止めるなら、送付者によって使用されたM(k)値は受信機からの最後のフィードバックレポートを反映します。受信機kからの時の進むにつれてフィードバックがなければ、これは、チェックポイント歴史のサイズを増加させるようにM(k)値の力に送付者を固定して、その結果、流れの帯域幅を増加させます。
At some point, the sender may need to take action in order to limit the bandwidth of the stream. In most envisioned uses of RTP MIDI, long before this point is reached, the SSRC time-out mechanism defined in [RFC3550] will remove the uncooperative receiver from the session (note that the closed-loop policy does not suggest or require any special sender behavior upon an SSRC time-out, other than the sender actions related to changing R, described earlier in this section).
何らかのポイントでは、送付者は、流れの帯域幅を制限するために行動を取る必要があるかもしれません。 このポイントに達しているずっと前のRTP MIDIのほとんどの思い描かれた用途で、[RFC3550]で定義されたSSRCタイムアウトメカニズムはセッション(より早くこのセクションで説明されたRを変えると関連する送付者動作を除いて、閉ループ方針がSSRCタイムアウトの少しの特別な送付者の振舞いも示しもしませんし、必要ともしないことに注意する)から非協力的な受信機を取り外すでしょう。
However, in rare situations, the bandwidth of the stream (due to a lack of feedback reports from the sender) may become too large to continue sending the stream to the receiver before the SSRC time-out occurs for the receiver. In this case, the closed-loop policy states that the sender should invoke the SSRC time-out for the receiver early.
しかしながら、まれな状況で、流れ(送付者からのフィードバックレポートの不足による)の帯域幅はSSRCタイムアウトが受信機のために起こる前に流れを受信機に送り続けることができないくらい大きくなるかもしれません。この場合、閉ループ方針は、送付者が受信機のために早くSSRCタイムアウトを呼び出すべきであると述べます。
We now discuss receiver responsibilities in the case of unplanned disruptions of RTCP feedback from receiver to sender.
私たちは現在、RTCPフィードバックの無計画な受信機から送付者までの分裂の場合で受信機責任について議論します。
In the unicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver stops receiving packets from the sender. The sender behavior imposed by the guardtime parameter (Appendix
ユニキャスト場合では、送付者が受信機のためにSSRCタイムアウトメカニズムを呼び出すなら、受信機は、送付者からパケットを受けるのを止めます。 送付者の振舞いがguardtimeパラメタででしゃばった、(付録
Lazzaro & Wawrzynek Standards Track [Page 107] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[107ページ]。
C.4.2) lets the receiver conclude that an SSRC time-out has occurred in a reasonable time period.
C.4.2) 受信機は、SSRCタイムアウトが妥当な期間に起こったと結論を下させます。
In this case of a time-out, a receiver MUST keep sending RTCP feedback, in order to re-establish the RTP flow from the sender. Unless the receiver expects a prompt recovery of the RTP flow, the receiver MUST take actions to ensure that the rendered MIDI performance does not exhibit "very long transient artifacts" (for example, by silencing NoteOns to prevent stuck notes) while awaiting reconnection of the flow.
タイムアウトのときにこの場合、受信機は、送付RTCPがフィードバックであることを保たなければなりません、送付者からのRTP流動を復職させるために。 受信機がRTP流動の迅速な回復を予想しない場合、受信機は、レンダリングされたMIDI性能が流れの再接続を待っている間「非常に長い一時的な人工物」(例えば張り付けられた注意を防ぐためにNoteOnsを黙らせることによって)を示さないのを保証するために行動を取らなければなりません。
In the multicast case, if a sender invokes the SSRC time-out mechanism for a receiver, the receiver may continue to receive packets, but the sender will no longer be using the M(k) feedback from the receiver to choose each checkpoint packet. If the receiver does not have additional information that precludes an SSRC time-out (such as RTCP Receiver Reports from the sender about an RTP stream the receiver is multicasting back to the sender), the receiver MUST monitor the Checkpoint Packet Seqnum to detect an SSRC time-out. If an SSRC time-out is detected, the receiver MUST follow the instructions for SSRC time-outs described for the unicast case above.
マルチキャスト場合では、送付者が受信機のためにSSRCタイムアウトメカニズムを呼び出すなら、受信機は、パケットを受け続けるかもしれませんが、送付者は、それぞれのチェックポイントパケットを選ぶのにもう受信機からM(k)フィードバックを使用しないでしょう。 受信機にSSRCタイムアウトを排除する追加情報がないなら(RTPに関する送付者からのRTCP Receiver Reportsが受信機を流すとき、そのようなものは送付者へのマルチキャスティング後部です)、受信機は、SSRCタイムアウトを検出するためにCheckpoint Packet Seqnumをモニターしなければなりません。 SSRCタイムアウトが検出されるなら、受信機はユニキャストケースのために上で説明されたSSRCタイムアウトのための指示に従わなければなりません。
Finally, we note that the closed-loop policy is suitable for use in RTP/RTCP sessions that use multicast transport. However, aspects of the closed-loop policy do not scale well to sessions with large numbers of participants. The sender state scales linearly with the number of receivers, as the sender needs to track the identity and M(k) value for each receiver k. The average recovery journal size is not independent of the number of receivers, as the RTCP reporting interval backoff slows down the rate of a full update of M(k) values. The backoff algorithm may also increase the amount of ancillary state used by implementations of the normative sender and receiver behaviors defined in Section 4.
最終的に、私たちは、閉ループ方針がマルチキャスト輸送を使用するRTP/RTCPセッションにおける使用に適していることに注意します。 しかしながら、閉ループ方針の局面は多くの関係者とのセッションまでよく比例しません。 送付者州のスケールは受信機の数で直線的です、送付者が、各受信機kのためにアイデンティティとM(k)値を追跡する必要があるとき。 平均した回復ジャーナルサイズは受信機の数から独立していません、RTCP報告間隔backoffがM(k)値の完全なアップデートの速度を減速させるのに従って。 また、backoffアルゴリズムは標準の送付者の実現で使用される付属の状態とセクション4で定義された受信機の振舞いの量を増加させるかもしれません。
C.2.2.3. The open-loop Sending Policy
C.2.2.3。 転々流通Sending Policy
The open-loop policy is suitable for sessions that are not able to implement the receiver-to-sender feedback required by the closed-loop policy, and that are also not able to use the anchor policy because of bandwidth constraints.
転々流通方針は受信機から送付者への閉ループ方針によって必要とされたフィードバックを実行できないで、また帯域幅規制のためにアンカー方針を使用できないセッションに適しています。
The open-loop policy does not place constraints on how a sender chooses the checkpoint packet for each packet in the stream. In the absence of such constraints, a receiver may find that the recovery journal in the packet that ends a loss event has a checkpoint history that does not cover the entire loss event. We refer to loss events of this type as uncovered loss events.
転々流通方針は各パケットのために送付者がどうチェックポイントパケットを選ぶかにおける規制を流れに置きません。 そのような規制がないとき、受信機は、損失出来事を終わらせるパケットの回復ジャーナルには全体の損失出来事に関しないチェックポイント歴史があるのがわかるかもしれません。 私たちはこのタイプの損失出来事をむき出しの損失出来事と呼びます。
Lazzaro & Wawrzynek Standards Track [Page 108] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[108ページ]。
To ensure that uncovered loss events do not compromise the recovery journal mandate, the open-loop policy assigns specific recovery tasks to senders, receivers, and the creators of session descriptions. The underlying premise of the open-loop policy is that the indefinite artifacts produced during uncovered loss events fall into two classes.
むき出しの損失出来事が回復ジャーナル命令で妥協しないのを保証するために、転々流通方針はセッション記述の送付者、受信機、および創造者に特定の回復タスクを割り当てます。 転々流通方針の基本的な前提によるむき出しの損失出来事の間に生産された無期人工物が2つのクラスになるということです。
One class of artifacts is recoverable indefinite artifacts. Receivers are able to repair recoverable artifacts that occur during an uncovered loss event without intervention from the sender, at the potential cost of unpleasant transient artifacts.
1つのクラスの人工物は回復可能な無期人工物です。 受信機はむき出しの損失出来事の間に送付者から介入なしで現れる回復可能な人工物を修理できます、不快な一時的な人工物の潜在的費用で。
For example, after an uncovered loss event, receivers are able to repair indefinite artifacts due to NoteOff (0x8) commands that may have occurred during the loss event, by executing NoteOff commands for all active NoteOns commands. This action causes a transient artifact (a sudden silent period in the performance), but ensures that no stuck notes sound indefinitely. We refer to MIDI commands that are amenable to repair in this fashion as recoverable MIDI commands.
例えば、むき出しの損失出来事の後に受信機は損失出来事の間に起こったかもしれないNoteOff(0×8)コマンドのため無期人工物を修理できます、すべての活発なNoteOnsコマンドのためのNoteOffコマンドを実行することによって。 この動作は、一時的な人工物(性能における突然の沈黙期)を引き起こしますが、張り付けられなかったそれが音に無期限に注意するのを確実にします。 私たちはこんなやり方で回復可能なMIDIが命令するように修理するのにおいて従順なMIDIコマンドを示します。
A second class of artifacts is unrecoverable indefinite artifacts. If this class of artifact occurs during an uncovered loss event, the receiver is not able to repair the stream.
人工物の二等は復しない無期人工物です。 このクラスの人工物がむき出しの損失出来事の間、現れるなら、受信機は流れを修理できません。
For example, after an uncovered loss event, receivers are not able to repair indefinite artifacts due to Control Change (0xB) Channel Volume (controller number 7) commands that have occurred during the loss event. A repair is impossible because the receiver has no way of determining the data value of a lost Channel Volume command. We refer to MIDI commands that are fragile in this way as unrecoverable MIDI commands.
例えば、むき出しの損失出来事の後に、受信機は損失出来事の間に起こっているControl Change(0xB)チャンネルVolume(コントローラNo.7)コマンドのため無期人工物を修理できません。 受信機には無くなっているChannel Volumeコマンドのデータ値を決定する方法が全くないので、修理は不可能です。 私たちは復しないMIDIが命令するようにこのようにこわれやすいMIDIコマンドを示します。
The open-loop policy does not specify how to partition the MIDI command set into recoverable and unrecoverable commands. Instead, it assumes that the creators of the session descriptions are able to come to agreement on a suitable recoverable/unrecoverable MIDI command partition for an application.
転々流通方針は回復可能で復しないコマンドにMIDIコマンドセットを仕切る方法を指定しません。 代わりに、それは、セッション記述の創造者がアプリケーションのための適当な回復可能であるか復しないMIDIコマンドパーティションの協定に来ることができると仮定します。
Given these definitions, we now state the normative requirements for the open-loop policy.
これらの定義を考えて、私たちは現在、転々流通方針のための標準の要件を述べます。
In the open-loop policy, the creators of the session description MUST use the ch_anchor parameter (defined in Appendix C.2.3) to protect all unrecoverable MIDI command types from indefinite artifacts, or alternatively MUST use the cm_unused parameter (defined in Appendix
セッション記述の創造者が転々流通方針で、無期人工物からすべての復しないMIDIコマンドタイプを保護するのにch_アンカーパラメタを使用しなければならないか(Appendix C.2.3では、定義されます)、またはあるいはまた、未使用でcm_を使用しなければならない、パラメタ、(Appendixでは、定義されます。
Lazzaro & Wawrzynek Standards Track [Page 109] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[109ページ]。
C.1) to exclude the command types from the stream. These options act to shield command types from artifacts during an uncovered loss event.
C.1) コマンドを除くのは流れからタイプされます。 これらのオプションは、むき出しの損失出来事の間、人工物からコマンドタイプを保護するために行動します。
In the open-loop policy, receivers MUST examine the Checkpoint Packet Seqnum field of the recovery journal header after every loss event, to check if the loss event is an uncovered loss event. Section 5 shows how to perform this check. If an uncovered loss event has occurred, a receiver MUST perform indefinite artifact recovery for all MIDI command types that are not shielded by ch_anchor and cm_unused parameter assignments in the session description.
転々流通方針で、受信機は、あらゆる損失出来事の後に損失出来事がむき出しの損失出来事であるかどうかチェックするために回復ジャーナルヘッダーのCheckpoint Packet Seqnum分野を調べなければなりません。 セクション5は、どのようにこのチェックを実行するかを示します。 むき出しの損失出来事が起こったなら、すべてのMIDIコマンドタイプがセッション記述における未使用のパラメタ課題をch_アンカーとcm_保護しなかったので、受信機は無期人工物回復を実行しなければなりません。
The open-loop policy does not place specific constraints on the sender. However, the open-loop policy works best if the sender manages the size of the checkpoint history to ensure that uncovered losses occur infrequently, by taking into account the delay and loss characteristics of the network. Also, as each checkpoint packet change incurs the risk of an uncovered loss, senders should only move the checkpoint if it reduces the size of the journal.
転々流通方針は特定の規制を送付者に置きません。 しかしながら、送付者がむき出しの損失がまれに発生するのを保証するためにチェックポイント歴史のサイズを管理するなら、転々流通方針はうまくいきます、ネットワークの遅れと損失の特性を考慮に入れることによって。 また、それぞれのチェックポイントパケット変化がむき出しの損失の危険を被るのに従って、ジャーナルのサイズを減少させる場合にだけ、送付者はチェックポイントを動かすべきです。
C.2.3. Recovery Journal Chapter Inclusion Parameters
C.2.3。 回復ジャーナル章の包含パラメタ
The recovery journal chapter definitions (Appendices A-B) specify under what conditions a chapter MUST appear in the recovery journal. In most cases, the definition states that if a certain command appears in the checkpoint history, a certain chapter type MUST appear in the recovery journal to protect the command.
回復ジャーナル章定義(付録A-B)は、章が回復ジャーナルにどんな条件のもとで現れなければならないかを指定します。 多くの場合、定義は、コマンドを保護するためにあるコマンドがチェックポイント歴史に現れるなら、ある章タイプが回復ジャーナルに載らなければならないと述べます。
In this section, we describe the chapter inclusion parameters. These parameters modify the conditions under which a chapter appears the journal. These parameters are essential to the use of the open-loop policy (Appendix C.2.2.3) and may also be used to simplify implementations of the closed-loop (Appendix C.2.2.2) and anchor (Appendix C.2.2.1) policies.
このセクションで、私たちは章包含パラメタについて説明します。 これらのパラメタは章がジャーナルに現れる状態を変更します。 これらのパラメタは、転々流通方針(付録C.2.2.3)の使用に不可欠であり、また、閉ループの実現(付録C.2.2.2)を簡素化して、(付録C.2.2.1)方針を据えつけるのに使用されるかもしれません。
Each parameter represents a type of chapter inclusion semantics. An assignment to a parameter declares which chapters (or chapter subsets) obey the inclusion semantics. We describe the assignment syntax for these parameters later in this section.
各パラメタは一種の章包含意味論を表します。 パラメタへのそれの章(または、章部分集合)が包含意味論に従う課題は宣言します。 私たちは後でこれらのパラメタのためにこのセクションで課題構文について説明します。
A party MUST NOT accept chapter inclusion parameter values that violate the recovery journal mandate (Section 4). All assignments of the subsetting parameters (cm_used and cm_unused) MUST precede the first assignment of a chapter inclusion parameter in the parameter list.
パーティーは回復ジャーナル命令(セクション4)に違反する章包含パラメタ値を受け入れてはいけません。 副設定パラメタのすべての課題、(cm、_中古、そして、cm_未使用、)、パラメータ・リストにおける、章包含パラメタの最初の課題に先行しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 110] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[110ページ]。
Below, we normatively define the semantics of the chapter inclusion parameters. For clarity, we define the action of parameters on complete chapters. If a parameter is assigned a subset of a chapter, the definition applies only to the chapter subset.
以下では、私たちが標準に章包含パラメタの意味論を定義します。 明快ために、私たちは完全な章へのパラメタの動作を定義します。 章の部分集合がパラメタに割り当てられるなら、定義は章部分集合だけに適用されます。
o ch_never. A chapter assigned to the ch_never parameter MUST NOT
appear in the recovery journal (Appendix A.4.1-2 defines
exceptions to this rule for Chapter M). To signal the exclusion
of a chapter from the journal, an assignment to ch_never MUST be
made, even if the commands coded by the chapter are assigned to
cm_unused. This rule simplifies the handling of commands types
that may be coded in several chapters.
o ch、_. _決してパラメタでないのがそうしなければならないchに割り当てられた章は回復ジャーナルに決して現れません(付録A.4.1-2は章Mのためにこの規則への例外を定義します)。 ジャーナルから章の除外に合図するために、ch_への課題を決してしてはいけません、章によってコード化されたコマンドがcm_に未使用で割り当てられても。 この規則は数章でコード化されるかもしれないコマンドタイプの取り扱いを簡素化します。
o ch_default. A chapter assigned to the ch_default parameter MUST
follow the default semantics for the chapter, as defined in
Appendices A-B.
o ch_デフォルト。 ch_デフォルトパラメタに割り当てられた章はAppendices A-Bで定義されるように章のためのデフォルト意味論に従わなければなりません。
o ch_anchor. A chapter assigned to the ch_anchor MUST obey a
modified version of the default chapter semantics. In the
modified semantics, all references to the checkpoint history are
replaced with references to the session history, and all
references to the checkpoint packet are replaced with references
to the first packet sent in the stream.
o ch_アンカー。 ch_アンカーに割り当てられた章はデフォルト章意味論の変更されたバージョンに従わなければなりません。 変更された意味論では、チェックポイント歴史のすべての参照をセッション歴史の参照に取り替えます、そして、チェックポイントパケットのすべての参照を流れで送られた最初のパケットの参照に取り替えます。
Parameter assignments obey the following syntax (see Appendix D for ABNF):
パラメタ課題は以下の構文に従います(ABNFに関してAppendix Dを見てください):
<parameter> = [channel list]<chapter list>[field list]
<パラメタ>=[チャンネルリスト]<章リスト>。[分野リスト]
The chapter list is mandatory; the channel and field lists are optional. Multiple assignments to parameters have a cumulative effect and are applied in the order of parameter appearance in a media description.
章リストは義務的です。 チャンネルと分野リストは任意です。 パラメタへの複数の課題が、累積している効果を持って、メディア記述におけるパラメタ外観の注文で適用されます。
To determine the semantics of a list of chapter inclusion parameter assignments, we begin by assuming an implicit assignment of all channel and system chapters to the ch_default parameter, with the default values for the channel list and field list for each chapter that are defined below.
章包含パラメタ課題のリストの意味論を決定するために、私たちは以下で定義される各章のためのチャンネルリストと分野リストのためにデフォルト値でオール・チャンネルとシステム章の暗黙の課題をch_デフォルトパラメタに仮定することによって、始めます。
We then interpret the semantics of the actual parameter assignments, using the rules below.
そして、以下の規則を使用して、私たちは実引数課題の意味論を解釈します。
A later assignment of a chapter to the same parameter expands the scope of the earlier assignment. In most cases, a later assignment of a chapter to a different parameter cancels (partially or completely) the effect of an earlier assignment.
同じパラメタへの章の後の課題は以前の課題の範囲を広くします。 多くの場合、異なったパラメタへの章の後の課題は以前の課題の効果を取り消します(部分的か完全に)。
Lazzaro & Wawrzynek Standards Track [Page 111] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[111ページ]。
The chapter list specifies the channel or system chapters for which the parameter applies. The chapter list is a concatenated sequence of one or more of the letters corresponding to the chapter types (ACDEFMNPQTVWX). In addition, the list may contain one or more of the letters for the sub-chapter types (BGHJKYZ) of System Chapter D.
章リストはパラメタが申し込まれるチャンネルかシステム章を指定します。 章リストは章タイプ(ACDEFMNPQTVWX)において、対応する手紙の1つ以上の連結された系列です。 さらに、リストが1つを含むかもしれませんか、またはサブチャプターのための一層の手紙がSystemの(BGHJKYZ)をタイプします。章D。
The letters in a chapter list MUST be uppercase and MUST appear in alphabetical order. Letters other than (ABCDEFGHJKMNPQTVWXYZ) that appear in the chapter list MUST be ignored.
章リストの手紙は、大文字しなければならなくて、アルファベット順に現れなければなりません。 章リストに現れる(ABCDEFGHJKMNPQTVWXYZ)を除いた手紙を無視しなければなりません。
The channel list specifies the channel journals for which this parameter applies; if no channel list is provided, the parameter applies to all channel journals. The channel list takes the form of a list of channel numbers (0 through 15) and dash-separated channel number ranges (i.e., 0-5, 8-12, etc.). Dots (i.e., "." characters) separate elements in the channel list.
チャンネルリストはこのパラメタが申し込まれるチャンネルジャーナルを指定します。 チャンネルリストを全く提供しないなら、パラメタはオール・チャンネルジャーナルに適用されます。 チャンネルリストは論理機番(0〜15)とダッシュで切り離された論理機番範囲(すなわち、0-5、8-12など)のリストの形を取ります。 「ドット(」 . 」 すなわち、キャラクタ)はチャンネルリストで要素を切り離します。
Several of the systems chapters may be configured to have special semantics. Configuration occurs by specifying a channel list for the systems channel, using the coding described below (note that MIDI Systems commands do not have a "channel", and thus the original purpose of the channel list does not apply to systems chapters). The expression "the digit N" in the text below refers to the inclusion of N as a "channel" in the channel list for a systems chapter.
いくつかのシステム章が、特別な意味論を持つために構成されるかもしれません。 構成はシステムチャンネルにチャンネルリストを指定することによって、起こります、以下で説明されたコード化を使用して(MIDI Systemsコマンドには「チャンネル」がなくて、またその結果、チャンネルリストの初心がシステム章に適用されないことに注意してください)。 以下のテキストの「ケタN」が参照する表現はシステム章のためにチャンネルという「チャンネル」としてのNの包含に記載します。
For the J and K Chapter D sub-chapters (undefined System Common), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.4 of Appendix B.1), the digit 1 codes that the parameter applies to the VALUE field of the command log, and the digit 2 codes that the parameter applies to the COUNT field of the command log.
JとK章のDサブチャプター(未定義のSystem Common)のために、パラメタが関連コマンドのLEGAL分野に適用するケタ0コードは(Appendix B.1の図B.1.4)(パラメタがコマンドログのVALUE分野、およびパラメタがコマンドログのCOUNT分野に適用するケタ2コードに適用するケタ1コード)を登録します。
For the Y and Z Chapter D sub-chapters (undefined System Real-time), the digit 0 codes that the parameter applies to the LEGAL field of the associated command log (Figure B.1.5 of Appendix B.1) and the digit 1 codes that the parameter applies to the COUNT field of the command log.
YとZ章のDサブチャプター(未定義のSystemレアル-時間)のために、パラメタが関連コマンドのLEGAL分野に適用するケタ0コードはパラメタがコマンドログのCOUNT分野に適用する(Appendix B.1の図B.1.5)とケタ1コードを登録します。
For Chapter Q (Sequencer State Commands), the digit 0 codes that the parameter applies to the default Chapter Q definition, which forbids the TIME field. The digit 1 codes that the parameter applies to the optional Chapter Q definition, which supports the TIME field.
章Q(シーケンサ州Commands)、パラメタがデフォルト章のQ定義に適用するケタ0コードのために。定義はタイム誌分野を禁じます。 パラメタがタイム誌分野を支持する任意の章のQ定義に適用するケタ1コード。
The syntax for field lists follows the syntax for channel lists. If no field list is provided, the parameter applies to all controller or note numbers. For Chapter C, if no field list is provided, the controller numbers do not use enhanced Chapter C encoding (Appendix A.3.3).
分野リストのための構文はチャンネルリストのための構文に従います。 分野リストを全く提供しないなら、パラメタはすべてのコントローラか注意番号に適用されます。 章Cのために、分野リストを全く提供しないなら、コントローラ番号は、(付録A.3.3)をコード化しながら、高められた章Cを使用しません。
Lazzaro & Wawrzynek Standards Track [Page 112] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[112ページ]。
For Chapter C, the field list may take on values in the range 0 to 255. A field value X in the range 0-127 refers to a controller number X, and indicates that the controller number does not use enhanced Chapter C encoding. A field value X in the range 128-255 refers to a controller number "X minus 128" and indicates the controller number does use the enhanced Chapter C encoding.
章Cのために、分野リストは範囲で0〜255に値を呈するかもしれません。 範囲0-127の分野値Xは、コントローラ番号Xを呼んで、コントローラ番号が高められた章C コード化を使用しないのを示します。 範囲128-255の分野値Xは、コントローラ番号「128を引いたX」について言及して、コントローラ番号が高められた章のCコード化を使用するのを示します。
Assignments made to configure the Chapter C encoding method for a controller number MUST be made to the ch_default or ch_anchor parameters, as assignments to ch_never act to exclude the number from the recovery journal (and thus the indicated encoding method is irrelevant).
コントローラ番号のために方法をコード化しながら章Cを構成するのがされた課題をch_デフォルトかch_アンカーパラメタにしなければなりません、ch_への課題が回復ジャーナルに数を入れないようにするために決して行動しないとき(その結果、示されたコード化方法は無関係です)。
A Chapter C field list MUST NOT encode conflicting information about the enhanced encoding status of a particular controller number. For example, values 0 and 128 MUST NOT both be coded by a field list.
特定のコントローラ番号の状態をコード化して、章のC分野リストは高めることの闘争情報をコード化してはいけません。 例えば、値0と128は分野リストによってともにコード化されてはいけません。
For Chapter M, the field list codes the Registered Parameter Numbers (RPNs) and Non-Registered Parameter Numbers (NRPNs) for which the parameter applies. The number range 0-16383 specifies RPNs, the number range 16384-32767 specifies NRPNs (16384 corresponds to NRPN 0, 32767 corresponds to NRPN 16383).
章Mのために、分野リストはパラメタが申し込まれるRegistered Parameter民数記(RPNs)とNonによって登録されたParameter民数記(NRPNs)をコード化します。 数の範囲0-16383はRPNsを指定して、数の範囲16384-32767はNRPNsを指定します(16384がNRPN0に対応している、32767はNRPN16383に対応しています)。
For Chapters N and A, the field list codes the note numbers for which the parameter applies. The note number range specified for Chapter N also applies to Chapter E.
第N章とAに関しては、分野リストはパラメタが申し込まれる注意番号をコード化します。 また、第N章に指定された注意数の範囲は章Eに適用されます。
For Chapter E, the digit 0 codes that the parameter applies to Chapter E note logs whose V bit is set to 0, and the digit 1 codes that the parameter applies to note logs whose V bit is set to 1.
章Eによって、パラメタが章Eに適用するケタ0コードはVビットが0、およびパラメタが当てはまるケタ1コードにVビットが1に設定されるログに注意するように設定されるログに注意します。
For Chapter X, the field list codes the number of data octets that may appear in a SysEx command that is coded in the chapter. Thus, the field list 0-255 specifies SysEx commands with 255 or fewer data octets, the field list 256-4294967295 specifies SysEx commands with more than 255 data octets but excludes commands with 255 or fewer data octets, and the field list 0 excludes all commands.
章Xのために、分野リストは章でコード化されるSysExコマンドに現れるかもしれないデータ八重奏の数をコード化します。 したがって、分野リスト0-255は255か、より少ないデータ八重奏でSysExコマンドを指定します、そして、分野リスト256-4294967295は、255以上のデータ八重奏でSysExコマンドを指定しますが、255か、より少ないデータ八重奏でコマンドを除きます、そして、分野リスト0はすべてのコマンドを除きます。
A secondary parameter assignment syntax customizes Chapter X (see Appendix D for complete ABNF):
二次パラメタ課題構文は章Xをカスタム設計します(完全なABNFに関してAppendix Dを見てください):
<parameter> = "__" <h-list> ["_" <h-list>] "__"
<パラメタ>="__"<h-リスト>["_"<h-リスト>]"__"
The assignment defines a class of SysEx commands whose Chapter X coding obeys the semantics of the assigned parameter. The command class is specified by listing the permitted values of the first N
課題は章のXコード化が割り当てられたパラメタの意味論に従うSysExコマンドのクラスを定義します。 コマンドのクラスは、最初のNの受入れられた値を記載することによって、指定されます。
Lazzaro & Wawrzynek Standards Track [Page 113] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[113ページ]。
data octets that follow the SysEx 0xF0 command octet. Any SysEx command whose first N data octets match the list is a member of the class.
SysEx 0xF0に続くデータ八重奏が八重奏を命令します。 最初のNデータ八重奏がリストに合っているどんなSysExコマンドもクラスの一員です。
Each <h-list> defines a data octet of the command, as a dot-separated
(".") list of one or more hexadecimal constants (such as "7F") or
dash-separated hexadecimal ranges (such as "01-1F"). Underscores
("_") separate each <h-list>. Double-underscores ("__") delineate
the data octet list.
それぞれの<h-リスト>がコマンドのデータ八重奏をaとドットによって切り離された状態で定義する、(「」、)、1つ以上の16進定数(「7F」などの)かダッシュで切り離された16進範囲(「01-1F」などの)のリスト。 強調("_")はそれぞれの<h-リスト>を切り離します。 二重強調("__")はデータ八重奏リストを図で表わします。
Using this syntax, each assignment specifies a single SysEx command class. Session descriptions may use several assignments to the same (or different) parameters to specify complex Chapter X behaviors. The ordering behavior of multiple assignments follows the guidelines for chapter parameter assignments described earlier in this section.
この構文を使用して、各課題は1つのSysExコマンドのクラスを指定します。 セッション記述は、複雑な章X 振舞いを指定するのに同じで(異なる)のパラメタにいくつかの課題を使用するかもしれません。 複数の課題の注文の振舞いは、より早くこのセクションで説明された章パラメタ課題のためのガイドラインに従います。
The example session description below illustrates the use of the chapter inclusion parameters:
以下での例のセッション記述は章包含パラメタの使用を例証します:
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; cm_used=__7E_00-7F_09_01.02.03__; cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; ch_anchor=P; ch_anchor=C7.64; ch_anchor=__7E_00-7F_09_01.02.03__; ch_anchor=__7F_00-7F_04_01.02__
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 rtp-ミディ/44100a=fmtp: 96j_アップデートは転々流通と等しいです。 _cm未使用の=ABCFGHJKMQTVWXYZ。 _が使用したcmは__7E_00-7Fの_09_01.02.03__と等しいです。 cm_は_04_01.02__を=__7F_00-7F使用しました。 _が使用したcmはC7.64と等しいです。 ch_はABCDEFGHJKMQTVWXYZと決して等しくはありません。 ch_は4.11-13Nと決して等しくはありません。 ch_アンカーはPと等しいです。 ch_アンカーはC7.64と等しいです。 chアンカー=__7_E_00-7Fの_09_01.02.03__。 chアンカー=__7_F_00-7F_04_01.02__
(The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp線を包装してあります; それはSDPの単線を包括します。)
The j_update parameter codes that the stream uses the open-loop policy. Most MIDI command-types are assigned to cm_unused and thus do not appear in the stream. As a consequence, the assignments to the first ch_never parameter reflect that most chapters are not in use.
j_はパラメタコードをアップデートします。流れは転々流通方針を使用します。 ほとんどのMIDIコマンドタイプは、cm_に未使用で割り当てられて、その結果、流れに現れません。 結果、1日への課題がパラメタを決してchしないように、ほとんどの章が使用中でないことを反映してください。
Chapter N for several MIDI channels is assigned to ch_never. Chapter N for MIDI channels other than 4, 11, 12, and 13 may appear in the recovery journal, using the (default) ch_default semantics. In practice, this assignment pattern would reflect knowledge about a resilient rendering method in use for the excluded channels.
数個のMIDIチャンネルのための第N章はchに決して割り当てられません。4、11以外のMIDIチャンネルのための第N章、12、および13は回復ジャーナルに載るかもしれません、(デフォルト)ch_デフォルト意味論を使用して。 習慣に、この課題パターンは除かれたチャンネルに、使用中の弾力がある表現方法に関する知識を反映するでしょう。
Lazzaro & Wawrzynek Standards Track [Page 114] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[114ページ]。
The MIDI Program Change command and several MIDI Control Change controller numbers are assigned to ch_anchor. Note that the ordering of the ch_anchor chapter C assignment after the ch_never command acts to override the ch_never assignment for the listed controller numbers (7 and 64).
MIDI Program ChangeコマンドといくつかのMIDI Control Changeコントローラ番号がch_アンカーに割り当てられます。 ch_の後のch_アンカー章C課題の注文が、行為がchをくつがえすと決して命令しないことに注意してください。記載されたコントローラ番号(7と64)のための課題。
The assignment of command-type X to cm_unused excludes most SysEx commands from the stream. Exceptions are made for General MIDI System On/Off commands and for the Master Volume and Balance commands, via the use of the secondary assignment syntax. The cm_used assignment codes the exception, and the ch_anchor assignment codes how these commands are protected in Chapter X.
cm_への未使用のXが最も遮断するコマンドタイプSysExの課題は流れから命令します。 例外はジェネラルミディSystem On/取り止めになっているコマンドとMaster VolumeとBalanceコマンドのために作られています、二次課題構文の使用で。 cm_は課題コードを使用しました。これらのコマンドが章Xに保護される例外、およびch_アンカー課題コード。
C.3. Configuration Tools: Timestamp Semantics
C.3。 構成ツール: タイムスタンプ意味論
The MIDI command section of the payload format consists of a list of commands, each with an associated timestamp. The semantics of command timestamps may be set during session configuration, using the parameters we describe in this section
ペイロード形式のMIDI指揮班はコマンドのリストと、それぞれ関連タイムスタンプで成ります。 私たちがこのセクションで説明するパラメタを使用して、コマンドタイムスタンプの意味論はセッション構成の間、設定されるかもしれません。
The parameter "tsmode" specifies the timestamp semantics for a stream. The parameter takes on one of three token values: "comex", "async", or "buffer".
パラメタ"tsmode"はタイムスタンプ意味論を流れに指定します。 パラメタは3つの象徴値の1つを帯びます: "comex"、"async"、または「バッファ。」
The default "comex" value specifies that timestamps code the execution time for a command (Appendix C.3.1) and supports the accurate transcoding Standard MIDI Files (SMFs, [MIDI]). The "comex" value is also RECOMMENDED for new MIDI user-interface controller designs. The "async" value specifies an asynchronous timestamp sampling algorithm for time-of-arrival sources (Appendix C.3.2). The "buffer" value specifies a synchronous timestamp sampling algorithm (Appendix C.3.3) for time-of-arrival sources.
デフォルト"comex"価値は、タイムスタンプがコマンド(付録C.3.1)のために実行時間をコード化すると指定して、正確なコード変換Standard MIDIファイル(SMFs、[MIDI])を支持します。 また、"comex"値は新しいMIDIユーザーインタフェースコントローラデザインのためのRECOMMENDEDです。 "async"値は到着時刻ソース(付録C.3.2)に非同期なタイムスタンプ標本抽出アルゴリズムを指定します。 「バッファ」値は同期タイムスタンプ標本抽出アルゴリズム(付録C.3.3)を到着時刻ソースに指定します。
Ancillary parameters MAY follow tsmode in a media description. We define these parameters in Appendices C.3.2-3 below.
付属のパラメタはメディア記述でtsmodeに続くかもしれません。 私たちは以下のAppendices C.3.2-3のこれらのパラメタを定義します。
C.3.1. The comex Algorithm
C.3.1。 comex Algorithm
The default "comex" (COMmand EXecution) tsmode value specifies the execution time for the command. With comex, the difference between two timestamps indicates the time delay between the execution of the commands. This difference may be zero, coding simultaneous execution.
デフォルト"comex"(COMmand EXecution)tsmode価値はコマンドに実行時間を指定します。 comexと共に、2つのタイムスタンプの違いはコマンドの実行の間の時間遅れを示します。 同時実行をコード化して、この違いはゼロであるかもしれません。
The comex interpretation of timestamps works well for transcoding a Standard MIDI File (SMF, [MIDI]) into an RTP MIDI stream, as SMFs code a timestamp for each MIDI command stored in the file. To transcode an SMF that uses metric time markers, use the SMF tempo map
タイムスタンプのcomex解釈はコード変換のために、Standard MIDIファイル(SMF、[MIDI])をRTP MIDIの流れの中をよく、扱います、SMFsがファイルに格納されたそれぞれのMIDIコマンドのためのタイムスタンプをコード化するとき。 「移-コード」へのメートル法の時間マーカーを使用するSMF、SMF速度が写像する使用
Lazzaro & Wawrzynek Standards Track [Page 115] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[115ページ]。
(encoded in the SMF as meta-events) to convert metric SMF timestamp units into seconds-based RTP timestamp units.
(SMFでは、メタ出来事としてコード化されます) 秒ベースのRTPタイムスタンプユニットにメートル法のSMFタイムスタンプユニットを変換するために。
New MIDI controller designs (piano keyboard, drum pads, etc.) that support RTP MIDI and that have direct access to sensor data SHOULD use comex interpretation for timestamps, so that simultaneous gestural events may be accurately coded by RTP MIDI.
RTP MIDIを支持して、センサデータSHOULDにダイレクトに近づく手段を持っている新しいMIDIコントローラデザイン(ピアノキーボード、ドラム・パッドなど)はタイムスタンプにcomex解釈を使用します、RTP MIDIが正確に同時のgestural出来事をコード化できるように。
Comex is a poor choice for transcoding MIDI 1.0 DIN cables [MIDI], for a reason that we will now explain. A MIDI DIN cable is an asynchronous serial protocol (320 microseconds per MIDI byte). MIDI commands on a DIN cable are not tagged with timestamps. Instead, MIDI DIN receivers infer command timing from the time of arrival of the bytes. Thus, two two-byte MIDI commands that occur at a source simultaneously are encoded on a MIDI 1.0 DIN cable with a 640 microsecond time offset. A MIDI DIN receiver is unable to tell if this time offset existed in the source performance or is an artifact of the serial speed of the cable. However, the RTP MIDI comex interpretation of timestamps declares that a timestamp offset between two commands reflects the timing of the source performance.
ComexはMIDI1.0DINが電報を打つコード変換[MIDI]、私たちが現在説明するつもりである理由のための不十分な選択です。 MIDI DINケーブルは非同期な連続のプロトコル(MIDIバイトあたり320マイクロセカンド)です。 DINケーブルにおけるMIDIコマンドはタイムスタンプでタグ付けをされません。 代わりに、MIDI DIN受信機はバイトの到着時刻からコマンドタイミングを推論します。 したがって、同時にソースに起こる2つの2バイトのMIDIコマンドがMIDI1.0DINケーブルの上で640マイクロセカンドの間の時間オフセットでコード化されます。 MIDI DIN受信機は、この時間オフセットがソース性能に存在したかどうかわからないか、ケーブルの連続の速度の人工物です。 しかしながら、タイムスタンプのRTP MIDI comex解釈は、2つのコマンドの間で相殺されたタイムスタンプがソース性能のタイミングを反映すると宣言します。
This semantic mismatch is the reason that comex is a poor choice for
transcoding MIDI DIN cables. Note that the choice of the RTP
timestamp rate (Section 6.1-2 in the main text) cannot fix this
inaccuracy issue. In the sections that follow, we describe two
alternative timestamp interpretations ("async" and "buffer") that are
a better match to MIDI 1.0 DIN cable timing, and to other MIDI time-
of-arrival sources.
この意味ミスマッチはcomexがコード変換MIDI DINケーブルのための不十分な選択である理由です。 RTPタイムスタンプレート(主なテキストのセクション6.1-2)の選択がこの不正確問題を修理できないことに注意してください。 従うセクションで、私たちは、より良いマッチである2つの代替のタイムスタンプ解釈("async"と「バッファ」)についてMIDI1.0DINケーブルタイミングと、そして、他のMIDI時間到着の源に説明します。
The "octpos", "linerate", and "mperiod" ancillary parameters (defined below) SHOULD NOT be used with comex.
「octpos」は、付属のパラメタ(以下では、定義される)SHOULD NOTを"linerateする"であると"mperiodする"です。comexと共に使用されます。
C.3.2. The async Algorithm
C.3.2。 async Algorithm
The "async" tsmode value specifies the asynchronous sampling of a MIDI time-of-arrival source. In asynchronous sampling, the moment an octet is received from a source, it is labelled with a wall-clock time value. The time value has RTP timestamp units.
"async"tsmode価値はMIDI到着時刻ソースの非同期な標本抽出を指定します。 ソースから八重奏を受けるとすぐに非同期な標本抽出では、それは柱時計時間的価値でラベルされます。 時間的価値には、RTPタイムスタンプユニットがあります。
The "octpos" ancillary parameter defines how RTP command timestamps are derived from octet time values. If octpos has the token value "first", a timestamp codes the time value of the first octet of the command. If octpos has the token value "last", a timestamp codes the time value of the last octet of the command. If the octpos parameter does not appear in the media description, the sender does not know which octet of the command the timestamp references (for example, the sender may be relying on an operating system service that does not specify this information).
"octpos"付属のパラメタは八重奏時間的価値からRTPコマンドタイムスタンプをどう得るかを定義します。 octposに象徴値が「最初に」あるなら、タイムスタンプはコマンドの最初の八重奏の時間的価値をコード化します。 octposに象徴値が「最後に」あるなら、タイムスタンプはコマンドの最後の八重奏の時間的価値をコード化します。 octposパラメタがメディア記述に現れないなら、送付者は、タイムスタンプがコマンドのどの八重奏に参照をつけるかを知りません(例えば、送付者はこの情報を指定しないオペレーティングシステムサービスに依存しているかもしれません)。
Lazzaro & Wawrzynek Standards Track [Page 116] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[116ページ]。
The octpos semantics refer to the first or last octet of a command as it appears on a time-of-arrival MIDI source, not as it appears in an RTP MIDI packet. This distinction is significant because the RTP coding may contain octets that are not present in the source. For example, the status octet of the first MIDI command in a packet may have been added to the MIDI stream during transcoding, to comply with the RTP MIDI running status requirements (Section 3.2).
octpos意味論はRTP MIDIパケットに現れるように参照するのではなく、到着時刻MIDIソースの上に載っているようにコマンドの1番目か最後の八重奏を参照します。 RTPコード化が存在していない八重奏を含むかもしれないので、この区別はソースで重要です。 例えば、パケットの最初のMIDIコマンドの状態八重奏は、状態要件(セクション3.2)を走らせるRTP MIDIに応じるためにコード変換の間、MIDIの流れに加えられるかもしれません。
The "linerate" ancillary parameter defines the timespan of one MIDI octet on the transmission medium of the MIDI source to be sampled (such as a MIDI 1.0 DIN cable). The parameter has units of nanoseconds, and takes on integral values. For MIDI 1.0 DIN cables, the correct linerate value is 320000 (this value is also the default value for the parameter).
"linerate"付属のパラメタは抽出されるべきMIDIソース(MIDI1.0DINケーブルなどの)のトランスミッション媒体の上で1つのMIDI八重奏のtimespanを定義します。 パラメタは、ユニットの数ナノ秒を持って、整数値を呈します。 1.0DINが電報を打つMIDIに関しては、正しいlinerate値は320000(また、この値はパラメタのためのデフォルト値である)です。
We now show a session description example for the async algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that assigns time values to every incoming octet of the source, and the sender uses the time values to label the first octet of each command in the RTP packet. This session description describes the transcoding:
私たちは現在、asyncアルゴリズムのためのセッション記述の例を示しています。 MIDI1.0DINがソースに電報を打つコード変換である送付者をRTPと考えてください。 送付者はソースのあらゆる入って来る八重奏に時間的価値を割り当てるコンピューティングプラットホームで走ります、そして、送付者はRTPパケットにおける、それぞれのコマンドの最初の八重奏をラベルするのに時間的価値を使用します。 このセッション記述はコード変換について説明します:
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=sendonly a=fmtp:96 tsmode=async; linerate=320000; octpos=first
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap: 96 rtp-ミディ/44100a=sendonly a=fmtp: 96tsmode=async。 linerate=320000。 octposは1番目と等しいです。
C.3.3. The buffer Algorithm
C.3.3。 バッファAlgorithm
The "buffer" tsmode value specifies the synchronous sampling of a MIDI time-of-arrival source.
「バッファ」tsmode価値はMIDI到着時刻ソースの同期標本抽出を指定します。
In synchronous sampling, octets received from a source are placed in a holding buffer upon arrival. At periodic intervals, the RTP sender examines the buffer. The sender removes complete commands from the buffer and codes those commands in an RTP packet. The command timestamp codes the moment of buffer examination, expressed in RTP timestamp units. Note that several commands may have the same timestamp value.
同期標本抽出では、ソースから受けられた八重奏は到着での把持バッファに置かれます。 周期的な間隔で、RTP送付者はバッファを調べます。 送付者は、バッファから完全なコマンドを取り除いて、RTPパケットでそれらのコマンドをコード化します。 コマンドタイムスタンプはRTPタイムスタンプユニットで言い表されたバッファ試験の瞬間をコード化します。 いくつかのコマンドには同じタイムスタンプ値があるかもしれないことに注意してください。
The "mperiod" ancillary parameter defines the nominal periodic sampling interval. The parameter takes on positive integral values and has RTP timestamp units.
"mperiod"付属のパラメタは名目上の周期的な標本抽出間隔を定義します。 パラメタは、上向きの整数値を呈して、RTPタイムスタンプユニットを持っています。
Lazzaro & Wawrzynek Standards Track [Page 117] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[117ページ]。
The "octpos" ancillary parameter, defined in Appendix C.3.1 for asynchronous sampling, plays a different role in synchronous sampling. In synchronous sampling, the parameter specifies the timestamp semantics of a command whose octets span several sampling periods.
非同期な標本抽出のためにAppendix C.3.1で定義された"octpos"付属のパラメタは同期標本抽出における異なる役割をプレーします。 同期標本抽出では、パラメタは八重奏がいくつかのサンプリング周期にわたるコマンドのタイムスタンプ意味論を指定します。
If octpos has the token value "first", the timestamp reflects the arrival period of the first octet of the command. If octpos has the token value "last", the timestamp reflects the arrival period of the last octet of the command. The octpos semantics refer to the first or last octet of the command as it appears on a time-of-arrival source, not as it appears in the RTP packet.
octposに象徴値が「最初に」あるなら、タイムスタンプはコマンドの最初の八重奏の到着一区切りを反映します。 octposに象徴値が「最後に」あるなら、タイムスタンプはコマンドの最後の八重奏の到着一区切りを反映します。 octpos意味論はRTPパケットに現れるように参照するのではなく、到着時刻ソースの上に載っているようにコマンドの1番目か最後の八重奏を参照します。
If the octpos parameter does not appear in the media description, the timestamp MAY reflect the arrival period of any octet of the command; senders use this option to signal a lack of knowledge about the timing details of the buffering process at sub-command granularity.
octposパラメタがメディア記述に現れないなら、タイムスタンプはコマンドのどんな八重奏の到着一区切りも反映するかもしれません。 送付者は、バッファリングの過程のタイミングの詳細に関してサブコマンド粒状で知識不足に合図するのにこのオプションを使用します。
We now show a session description example for the buffer algorithm. Consider a sender that is transcoding a MIDI 1.0 DIN cable source into RTP. The sender runs on a computing platform that places source data into a buffer upon receipt. The sender polls the buffer 1000 times a second, extracts all complete commands from the buffer, and places the commands in an RTP packet. This session description describes the transcoding:
私たちは現在、バッファアルゴリズムのためのセッション記述の例を示しています。 MIDI1.0DINがソースに電報を打つコード変換である送付者をRTPと考えてください。 送付者は領収書のバッファの中にソースデータを置くコンピューティングプラットホームで走ります。 1秒あたりのバッファ1000回に、抽出がすべて、終了する送付者投票は、バッファから命令して、RTPパケットにコマンドを置きます。 このセッション記述はコード変換について説明します:
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=sendonly a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 rtp-ミディ/44100a=sendonly a=fmtp: 96 tsmodeはバッファと等しいです。 linerate=320000。 octpos=はもちます。 mperiod=44
The mperiod value of 44 is derived by dividing the clock rate specified by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate and rounding to the nearest integer. Command timestamps might not increment by exact multiples of 44, as the actual sampling period might not precisely match the nominal mperiod value.
44のmperiod値は、rtpmap属性(44100Hz)によって最も近い整数への1000Hzのバッファ標本抽出率と一周で指定されたクロックレートを分割することによって、引き出されます。 タイムスタンプが実際のサンプリング周期として44の正確な倍数増加しないかもしれないコマンドは正確に名目上のmperiod値に合わないかもしれません。
C.4. Configuration Tools: Packet Timing Tools
C.4。 構成ツール: パケットタイミングツール
In this appendix, we describe session configuration tools for customizing the temporal behavior of MIDI stream packets.
この付録では、私たちはMIDI流れのパケットの時の動きをカスタマイズするためのセッション構成ツールについて説明します。
Lazzaro & Wawrzynek Standards Track [Page 118] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[118ページ]。
C.4.1. Packet Duration Tools
C.4.1。 パケット持続時間ツール
Senders control the granularity of a stream by setting the temporal
duration ("media time") of the packets in the stream. Short media
times (20 ms or less) often imply an interactive session. Longer
media times (100 ms or more) usually indicate a content streaming
session. The RTP AVP profile [RFC3551] recommends audio packet media
times in a range from 0 to 200 ms.
送付者は、流れでパケットの時の持続時間(「メディア時間」)を設定することによって、流れの粒状を制御します。 短いメディア回(20よりms)はしばしば対話的なセッションを含意します。 通常、より長いメディア回(より100より多くのms)は満足しているストリーミングのセッションを示します。 RTP AVPプロフィール[RFC3551]は範囲0〜200原稿のオーディオパケットメディア回数を推薦します。
By default, an RTP receiver dynamically senses the media time of packets in a stream and chooses the length of its playout buffer to match the stream. A receiver typically sizes its playout buffer to fit several audio packets and adjusts the buffer length to reflect the network jitter and the sender timing fidelity.
デフォルトで、RTP受信機は、ダイナミックに絶え間なくパケットのメディア時間を感じて、流れに合うように再生バッファの長さを選びます。 受信機は、いくつかのオーディオパケットに合うように再生バッファを通常に大きさで分けて、ネットワークジターと送付者タイミング信義を反映するようにバッファ長を調整します。
Alternatively, the packet media time may be statically set during session configuration. Session descriptions MAY use the RTP MIDI parameter "rtp_ptime" to set the recommended media time for a packet. Session descriptions MAY also use the RTP MIDI parameter "rtp_maxptime" to set the maximum media time for a packet permitted in a stream. Both parameters MAY be used together to configure a stream.
あるいはまた、パケットメディア時間はセッション構成の間、静的に決められるかもしれません。 セッション記述は、パケットのためのお勧めのメディア時間を決めるのに「rtp_ptime」というRTP MIDIパラメタを使用するかもしれません。 また、セッション記述は、絶え間なく受入れられたパケットのための最大のメディア時間を決めるのに「rtp_maxptime」というRTP MIDIパラメタを使用するかもしれません。 両方のパラメタは、流れを構成するのに一緒に使用されるかもしれません。
The values assigned to the rtp_ptime and rtp_maxptime parameters have the units of the RTP timestamp for the stream, as set by the rtpmap attribute (see Section 6.1). Thus, if rtpmap sets the clock rate of a stream to 44100 Hz, a maximum packet media time of 10 ms is coded by setting rtp_maxptime=441. As stated in the Appendix C preamble, the senders and receivers of a stream MUST agree on common values for rtp_ptime and rtp_maxptime if the parameters appear in the media description for the stream.
rtp_ptimeとrtp_maxptimeパラメタに割り当てられた値は流れのためのRTPタイムスタンプのユニットを持っています、rtpmap属性によって設定されるように(セクション6.1を見てください)。 したがって、rtpmapが44100Hzに流れのクロックレートを設定するなら、10msの最大のパケットメディア時間は、rtp_maxptime=441を設定することによって、コード化されます。 Appendix C序文に述べられているように、パラメタが流れのためのメディア記述に現れるなら、流れの送付者と受信機はrtp_ptimeとrtp_maxptimeのために共通の価値観に同意しなければなりません。
0 ms is a reasonable media time value for MIDI packets and is often used in low-latency interactive applications. In a packet with a 0 ms media time, all commands execute at the instant they are coded by the packet timestamp. The session description below configures all packets in the stream to have 0 ms media time:
0 msはMIDIパケットのための妥当なメディア時間的価値であり、低遅延対話型アプリケーションでしばしば使用されます。 0msメディア時間、コマンドが瞬間に実行するすべてがあるパケットでは、それらはパケットタイムスタンプによってコード化されます。 以下でのセッション記述は0msメディア時間を持つために流れですべてのパケットを構成します:
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 rtp_ptime=0; rtp_maxptime=0
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap: 96 rtp-ミディ/44100a=fmtp: 96rtp_ptime=0。 rtp_maxptime=0
Lazzaro & Wawrzynek Standards Track [Page 119] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[119ページ]。
The session attributes ptime and maxptime [RFC4566] MUST NOT be used to configure an RTP MIDI stream. Sessions MUST use rtp_ptime in lieu of ptime and MUST use rtp_maxptime in lieu of maxptime. RTP MIDI defines its own parameters for media time configuration because 0 ms values for ptime and maxptime are forbidden by [RFC3264] but are essential for certain applications of RTP MIDI.
RTP MIDIの流れを構成するのにセッション属性のptimeとmaxptime[RFC4566]を使用してはいけません。 セッションは、ptimeの代わりにrtp_ptimeを使用しなければならなくて、maxptimeの代わりにrtp_maxptimeを使用しなければなりません。 ptimeとmaxptimeのための0つのms値が[RFC3264]によって禁じられますが、RTP MIDIのあるアプリケーションに、不可欠であるので、RTP MIDIはメディア時間構成のためのそれ自身のパラメタを定義します。
See the Appendix C.7 examples for additional discussion about using rtp_ptime and rtp_maxptime for session configuration.
セッション構成にrtp_ptimeとrtp_maxptimeを使用するのと追加議論のためのAppendix C.7の例を見てください。
C.4.2. The guardtime Parameter
C.4.2。 guardtime Parameter
RTP permits a sender to stop sending audio packets for an arbitrary period of time during a session. When sending resumes, the RTP sequence number series continues unbroken, and the RTP timestamp value reflects the media time silence gap.
RTPは、送付者が、セッションの間の任意の期間の間、オーディオパケットを送るのを止めるのを可能にします。 履歴書を送るとき、RTP一連番号シリーズが続く、少しも壊れる、RTPタイムスタンプ価値はメディア時間沈黙相違を反映しません。
This RTP feature has its roots in telephony, but it is also well matched to interactive MIDI sessions, as players may fall silent for several seconds during (or between) songs.
このRTPの特徴は電話で起源を発しますが、また、それは対話的なMIDIセッションまでよく合わせられています、プレーヤーが(or between)歌の間の数秒間黙り込むとき。
Certain MIDI applications benefit from a slight enhancement to this RTP feature. In interactive applications, receivers may use on-line network models to guide heuristics for handling lost and late RTP packets. These models may work poorly if a sender ceases packet transmission for long periods of time.
あるMIDIアプリケーションはわずかな増進からこのRTPの特徴まで利益を得ます。 対話型アプリケーションでは、受信機は、無くなっていて遅いRTPパケットを扱うための発見的教授法を誘導するのにオンラインネットワークモデルを使用するかもしれません。 送付者が長期間の間、パケット伝送をやめるなら、これらのモデルは不十分に働くかもしれません。
Session descriptions may use the parameter "guardtime" to set a minimum sending rate for a media session. The value assigned to guardtime codes the maximum separation time between two sequential packets, as expressed in RTP timestamp units.
セッション記述は、メディアセッションの最小の送付速度を設定するのに"guardtime"というパラメタを使用するかもしれません。 値はRTPタイムスタンプユニットで言い表されるように2つの連続したパケットの間の最大の分離時間をguardtimeコードに割り当てました。
Typical guardtime values are 500-2000 ms. This value range is not a normative bound, and parties SHOULD be prepared to process values outside this range.
典型的なguardtime値は500-2000 原稿This値の範囲が標準のバウンドと、またはパーティーSHOULDでないということです。この範囲の外で値を処理するように用意してください。
The congestion control requirements for sender implementations (described in Section 8 and [RFC3550]) take precedence over the guardtime parameter. Thus, if the guardtime parameter requests a minimum sending rate, but sending at this rate would violate the congestion control requirements, senders MUST ignore the guardtime parameter value. In this case, senders SHOULD use the lowest minimum sending rate that satisfies the congestion control requirements.
送付者実装(セクション8と[RFC3550]では、説明される)のための輻輳制御要件はguardtimeパラメタの上で優先します。 したがって、guardtimeパラメタが最小の送付レートを要求しますが、発信がこのままでいくと輻輳制御要件に違反するなら、送付者はguardtimeパラメタ価値を無視しなければなりません。 この場合、送付者SHOULDは輻輳制御要件を満たす最も低い最小の送付レートを使用します。
Lazzaro & Wawrzynek Standards Track [Page 120] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[120ページ]。
Below, we show a session description that uses the guardtime parameter.
以下では、私たちがguardtimeパラメタを使用するセッション記述を示しています。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 rtp-midi/44100 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 rtp-ミディ/44100a=fmtp: 96guardtime=44100。 rtp_ptime=0。 rtp_maxptime=0
C.5. Configuration Tools: Stream Description
C.5。 構成ツール: ストリーム記述
As we discussed in Section 2.1, a party may send several RTP MIDI streams in the same RTP session, and several RTP sessions that carry MIDI may appear in a multimedia session.
私たちがセクションで2.1について議論したので、パーティーは同じRTPセッションのときにいくつかのRTP MIDIストリームを送るかもしれません、そして、MIDIを運ぶいくつかのRTPセッションがマルチメディアセッションのときに現れるかもしれません。
By default, the MIDI name space (16 channels + systems) of each RTP stream sent by a party in a multimedia session is independent. By independent, we mean three distinct things:
デフォルトで、マルチメディアセッションのときにパーティーによって送られたそれぞれのRTPストリームのMIDI名前スペース(16台のチャンネル+システム)は独立しています。 独立者で、私たちは3つの異なったものを言っています:
o If a party sends two RTP MIDI streams (A and B), MIDI voice
channel 0 in stream A is a different "channel 0" than MIDI voice
channel 0 in stream B.
o パーティーが2つのRTP MIDIストリーム(AとB)を送るなら、ストリームAにおけるMIDI音声チャンネル0はa異なっています。「ストリームBにおけるMIDI音声チャンネル0より何0インチも精神を集中してください。」
o MIDI voice channel 0 in stream B is not considered to be
"channel 16" of a 32-channel MIDI voice channel space whose
"channel 0" is channel 0 of stream A.
o 32チャンネルのMIDIのチャンネル16インチはチャンネルスペースを声に出します。ストリームBにおけるMIDI音声チャンネル0による考えられない、「だれの「チャンネル0インチはストリームAのチャンネル0であるか」。
o Streams sent by different parties over different RTP sessions,
or over the same RTP session but with different payload type
numbers, do not share the association that is shared by a MIDI
cable pair that cross-connects two devices in a MIDI 1.0 DIN
network. By default, this association is only held by streams
sent by different parties in the same RTP session that use the
same payload type number.
o ストリームが異なったパーティーによって異なったRTPセッションの上、または、セッションにもかかわらず、異なったペイロード形式数がある同じRTPの上に送られて、協会を共有しないでください、そして、すなわち、MIDIによって共有されて、MIDI1.0DINネットワークにおける2台のデバイスにどんなその十字接続にも電報を打たないでください。 デフォルトで、この協会が同じRTPセッションにおける同じペイロード形式数を使用する異なったパーティーによって送られたストリームによって行われるだけです。
In this appendix, we show how to express that specific RTP MIDI streams in a multimedia session are not independent but instead are related in one of the three ways defined above. We use two tools to express these relations:
この付録では、私たちは、マルチメディアセッションにおける特定のRTP MIDIストリームが独立していないとどのように言い表すかを示しますが、代わりに上で定義された3つの方法の1つで関係づけられます。 私たちはこれらの関係を言い表すのに2つのツールを使用します:
o The musicport parameter. This parameter is assigned a non-
negative integer value between 0 and 4294967295. It appears in
the fmtp lines of payload types.
o musicportパラメタ。 0と4294967295の間の非負の整数の値はこのパラメタに割り当てられます。 それはペイロードタイプのfmtp系列に現れます。
Lazzaro & Wawrzynek Standards Track [Page 121] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[121ページ]。
o The FID grouping attribute [RFC3388] signals that several RTP
sessions in a multimedia session are using the musicport
parameter to express an inter-session relationship.
o マルチメディアセッションのときにそのいくつかのRTPセッションの属性[RFC3388]信号を分類するFIDは、相互セッション関係を言い表すのにmusicportパラメタを使用しています。
If a multimedia session has several payload types whose musicport parameters are assigned the same integer value, streams using these payload types share an "identity relationship" (including streams that use the same payload type). Streams in an identity relationship share two properties:
マルチメディアセッションに同じ整数値がmusicportパラメタに割り当てられるいくつかのペイロードタイプがあるなら、これらのペイロードタイプを使用するストリームが「アイデンティティ関係」を共有します(同じペイロードタイプを使用するストリームを含んでいて)。 アイデンティティ関係におけるストリームは2つの特性を共有します:
o Identity relationship streams sent by the same party target the
same MIDI name space. Thus, if streams A and B share an
identity relationship, voice channel 0 in stream A is the same
"channel 0" as voice channel 0 in stream B.
o 同じパーティーによって送られたアイデンティティ関係小川は同じMIDI名前スペースを狙います。 したがって、ストリームAとBがアイデンティティ関係を共有するなら、ストリームAにおける音声チャンネル0は同じ「ストリームBにおける音声チャンネル0としてのチャンネル0インチ」です。
o Pairs of identity relationship streams that are sent by
different parties share the association that is shared by a MIDI
cable pair that cross-connects two devices in a MIDI 1.0 DIN
network.
o 異なったパーティーシェアによるMIDIによって共有される協会に送られるアイデンティティ関係ストリームのペアはMIDI1.0DINネットワークにおける2台のデバイスにどんなその十字接続にも電報を打ちません。
A party MUST NOT send two RTP MIDI streams that share an identity relationship in the same RTP session. Instead, each stream MUST be in a separate RTP session. As explained in Section 2.1, this restriction is necessary to support the RTP MIDI method for the synchronization of streams that share a MIDI name space.
パーティーは同じRTPセッションのときにアイデンティティ関係を共有する2つのRTP MIDIストリームを送ってはいけません。 代わりに、別々のRTPセッションのときに、各ストリームがあるに違いありません。 セクション2.1で説明されるように、この制限がMIDI名前スペースを共有するストリームの同期のためのRTP MIDIメソッドをサポートするのに必要です。
If a multimedia session has several payload types whose musicport parameters are assigned sequential values (i.e., i, i+1, ... i+k), the streams using the payload types share an "ordered relationship". For example, if payload type A assigns 2 to musicport and payload type B assigns 3 to musicport, A and B are in an ordered relationship.
マルチメディアセッションに連続した値(すなわち、i、i+1… i+k)がmusicportパラメタに割り当てられるいくつかのペイロードタイプがあるなら、ペイロードタイプを使用するストリームは「命令された関係」を共有します。 例えば、ペイロードタイプAが2をmusicportに割り当てて、ペイロードタイプBが3をmusicportに割り当てるなら、命令された関係にはAとBがあります。
Streams in an ordered relationship that are sent by the same party are considered by renderers to form a single larger MIDI space. For example, if stream A has a musicport value of 2 and stream B has a musicport value of 3, MIDI voice channel 0 in stream B is considered to be voice channel 16 in the larger MIDI space formed by the relationship. Note that it is possible for streams to participate in both an identity relationship and an ordered relationship.
レンダラーで、命令された関係における同じパーティーによって送られる小川がただ一つの、より大きいMIDIスペースを形成すると考えられます。 例えば、ストリームAには2のmusicport値があって、ストリームBに3のmusicport値があるなら、ストリームBにおけるMIDI音声チャンネル0は関係によって形成されたより大きいMIDIスペースの音声チャンネル16であると考えられます。 ストリームがアイデンティティ関係と命令された関係の両方に参加するのが、可能であることに注意してください。
We now state several rules for using musicport:
私たちは現在、musicportを使用するためのいくつかの規則を述べます:
o If streams from several RTP sessions in a multimedia session use
the musicport parameter, the RTP sessions MUST be grouped using
the FID grouping attribute defined in [RFC3388].
o マルチメディアセッションにおけるいくつかのRTPセッションからのストリームがmusicportパラメタを使用するなら、[RFC3388]で定義されたFID組分け属性を使用して、RTPセッションを分類しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 122] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[122ページ]。
o An ordered or identity relationship MUST NOT contain both native
RTP MIDI streams and mpeg4-generic RTP MIDI streams. An
exception applies if a relationship consists of sendonly and
recvonly (but not sendrecv) streams. In this case, the sendonly
streams MUST NOT contain both types of streams, and the recvonly
streams MUST NOT contain both types of streams.
o 命令されるかアイデンティティ関係はネイティブのRTP MIDIストリームとmpeg4-ジェネリックRTP MIDIストリームの両方を含んではいけません。関係がsendonlyとrecvonly(しかし、sendrecvでない)ストリームから成るなら、例外は適用されます。この場合sendonlyストリームは両方のタイプの流れを含んではいけません、そして、recvonlyストリームは両方のタイプの流れを含んではいけません。
o It is possible to construct identity relationships that violate
the recovery journal mandate (for example, sending NoteOns for a
voice channel on stream A and NoteOffs for the same voice
channel on stream B). Parties MUST NOT generate (or accept)
session descriptions that exhibit this flaw.
o 回復ジャーナル命令(例えば、音声チャンネルのためにストリームAにNoteOnsを送って、ストリームBの同じ音声チャンネルのためのNoteOffs)に違反するアイデンティティ関係を構成するのは可能です。 党はこの欠点を示すセッション記述を生成してはいけません(受け入れてください)。
o Other payload formats MAY define musicport media type
parameters. Formats would define these parameters so that their
sessions could be bundled into RTP MIDI name spaces. The
parameter definitions MUST be compatible with the musicport
semantics defined in this appendix.
o 他のペイロード形式はmusicportメディア型引数を定義するかもしれません。 形式は、RTP MIDI名前空間に彼らのセッションを投げ込むことができるようにこれらのパラメタを定義するでしょう。 パラメタ定義はこの付録で定義されるmusicport意味論と互換性があるに違いありません。
As a rule, at most one payload type in a relationship may specify a MIDI renderer. An exception to the rule applies to relationships that contain sendonly and recvonly streams but no sendrecv streams. In this case, one sendonly session and one recvonly session may each define a renderer.
原則として、最も1つでは、関係におけるペイロードタイプはMIDIレンダラーを指定するかもしれません。 規則への例外はsendonlyであってrecvonlyなストリームを含んでいますが、どんなsendrecvストリームも含まない関係に適用されます。この場合、1つのsendonlyセッションと1つのrecvonlyセッションがそれぞれレンダラーを定義するかもしれません。
Renderer specification in a relationship may be done using the tools
described in Appendix C.6. These tools work for both native streams
and mpeg4-generic streams. An mpeg4-generic stream that uses the
Appendix C.6 tools MUST set all "config" parameters to the empty
string ("").
関係におけるレンダラー仕様はAppendix C.6で説明されたツールを使用し終わるかもしれません。 これらのツールにネイティブのストリームとmpeg4-ジェネリックストリームの両方のために取り組みます。Appendix C.6ツールを使用するmpeg4-ジェネリックストリームがすべての「コンフィグ」パラメタを空のストリングに設定しなければならない、(「「)、」
Alternatively, for mpeg4-generic streams, renderer specification may
be done by setting one "config" parameter in the relationship to the
renderer configuration string, and all other config parameters to the
empty string ("").
あるいはまた、mpeg4-ジェネリックストリームにおいて、空のストリングにレンダラー構成ストリング、および他のすべてのコンフィグパラメタとの関係に1つの「コンフィグ」パラメタをはめ込むことによってレンダラー仕様をするかもしれない、(「「)、」
We now define sender and receiver rules that apply when a party sends several streams that target the same MIDI name space.
私たちは現在、パーティーが同じMIDI名前スペースを狙ういくつかのストリームを送るとき適用される送付者と受信機規則を定義します。
Senders MAY use the subsetting parameters (Appendix C.1) to predefine the partitioning of commands between streams, or they MAY use a dynamic partitioning strategy.
Sendersがストリームの間のコマンドの仕切りを事前に定義するのに、副設定パラメタ(付録C.1)を使用するかもしれませんか、またはそれらはダイナミックな仕切りの戦略を使用するかもしれません。
Receivers that merge identity relationship streams into a single MIDI command stream MUST maintain the structural integrity of the MIDI commands coded in each stream during the merging process, in the same way that software that merges traditional MIDI 1.0 DIN cable flows is
伝統的なMIDI1.0DINケーブル流れを合併するソフトウェアは合併しているプロセスの間の各ストリーム、同じようにコード化されたコマンドですが、ただ一つのMIDIコマンドストリームにアイデンティティ関係ストリームを合併する受信機はMIDIの構造的な保全を維持しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 123] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[123ページ]。
responsible for creating a merged command flow compatible with [MIDI].
[MIDI]と互換性があった状態で合併しているコマンド流動を引き起こすのに責任があります。
Senders MUST partition the name space so that the rendered MIDI performance does not contain indefinite artifacts (as defined in Section 4). This responsibility holds even if all streams are sent over reliable transport, as different stream latencies may yield indefinite artifacts. For example, stuck notes may occur in a performance split over two TCP streams, if NoteOn commands are sent on one stream and NoteOff commands are sent on the other.
Sendersは、レンダリングされたMIDI性能が無期人工物を含まない(セクション4で定義されるように)ように、スペースという名前を仕切らなければなりません。 信頼できる輸送の上にすべての小川を送っても、この責任は成立して、異なったストリームとして、潜在は無期人工物をもたらすかもしれません。 例えば、張り付けられた注意は2以上TCPが流す性能分裂で現れるかもしれません、1つのストリームでNoteOnコマンドを送って、もう片方でNoteOffコマンドを送るなら。
Senders MUST NOT split a Registered Parameter Name (RPN) or Non- Registered Parameter Name (NRPN) transaction appearing on a MIDI channel across multiple identity relationship sessions. Receivers MUST assume that the RPN/NRPN transactions that appear on different identity relationship sessions are independent and MUST preserve transactional integrity during the MIDI merge.
Sendersは複数のアイデンティティ関係セッションの向こう側にMIDIチャンネルで現れるRegistered Parameter Name(RPN)かNonの登録されたParameter Name(NRPN)トランザクションを分けてはいけません。 受信機は、異なったアイデンティティ関係セッションのときに現れるRPN/NRPNトランザクションが独立していて、MIDIマージの間取引の保全を保持しなければならないと仮定しなければなりません。
A simple way to safely partition voice channel commands is to place all MIDI commands for a particular voice channel into the same session. Safe partitioning of MIDI Systems commands may be more complicated for sessions that extensively use System Exclusive.
安全に声のチャネル指令を仕切る簡単な方法は同じセッションまで特定の音声チャンネルのためのすべてのMIDIコマンドを置くことです。 MIDI Systemsコマンドの安全な仕切りは手広くSystem Exclusiveを使用するセッションのためにさらに複雑にされるかもしれません。
We now show several session description examples that use the musicport parameter.
私たちは現在、musicportパラメタを使用するいくつかのセッション記述の例を示しています。
Our first session description example shows two RTP MIDI streams that drive the same General MIDI decoder. The sender partitions MIDI commands between the streams dynamically. The musicport values indicate that the streams share an identity relationship.
私たちの最初のセッション記述の例は同じジェネラルミディデコーダを動かす2つのRTP MIDIストリームを示しています。 送付者はダイナミックにストリームの間のMIDIコマンドを仕切ります。 musicport値は、ストリームがアイデンティティ関係を共有するのを示します。
Lazzaro & Wawrzynek Standards Track [Page 124] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[124ページ]。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 a=group:FID 1 2 c=IN IP4 192.0.2.94 m=audio 5004 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/44100 a=mid:1 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; config=7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000; musicport=12 m=audio 5006 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/44100 a=mid:2 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; musicport=12
IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例tが=グループ: FIDあたり0 0と等しい、1 2、c、=IN IP4、192.0、.2、.94m、=オーディオの5004RTP/AVP96a=rtpmap: 96 mpeg4-ジェネリック/44100a=中間:、1 a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 プロフィール平らなイドの=12。 コンフィグは7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000と等しいです。 musicport=12m=オーディオの5006RTP/AVP96a=rtpmap: 96 mpeg4-ジェネリック/44100a=中間:、2 a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それらはSDPの単線を包括します。)
Recall that Section 2.1 defines rules for streams that target the same MIDI name space. Those rules, implemented in the example above, require that each stream resides in a separate RTP session, and that the grouping mechanisms defined in [RFC3388] signal an inter-session relationship. The "group" and "mid" attribute lines implement this grouping mechanism.
セクション2.1が同じMIDI名前スペースを狙うストリームのために規則を定義すると思い出してください。 上記の例で実装されたそれらの規則は、各ストリームが別々のRTPセッションのときにあって、[RFC3388]で定義された組分けメカニズムが相互セッション関係を示すのを必要とします。 「グループ」と「中間」の属性系列はこの組分けメカニズムを実装します。
A variant on this example, whose session description is not shown, would use two streams in an identity relationship driving the same MIDI renderer, each with a different transport type. One stream would use UDP and would be dedicated to real-time messages. A second stream would use TCP [RFC4571] and would be used for SysEx bulk data messages.
セッション記述が示されないこの例の異形は同じMIDIレンダラーを運転しながら、アイデンティティ関係に2つのストリームを使用するでしょう、それぞれ異なった輸送タイプで。 1つの小川が、UDPを使用して、リアルタイムのメッセージに捧げられるでしょう。 2番目のストリームは、TCP[RFC4571]を使用して、SysExの大量のデータメッセージに使用されるでしょう。
Lazzaro & Wawrzynek Standards Track [Page 125] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[125ページ]。
In the next example, two mpeg4-generic streams form an ordered relationship to drive a Structured Audio decoder with 32 MIDI voice channels. Both streams reside in the same RTP session.
次の例では、2つのmpeg4-ジェネリックストリームが、32個のMIDI音声チャンネルでStructured Audioデコーダを動かすために命令された関係を形成します。 両方のストリームは同じRTPセッションのときにあります。
v=0 o=lazzaro 2520644554 2838152170 IN IP6 first.example.net s=Example t=0 0 m=audio 5006 RTP/AVP 96 97 c=IN IP6 2001:DB80::7F2E:172A:1E24 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; musicport=5 a=rtpmap:97 mpeg4-generic/44100 a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; musicport=6; render=synthetic; rinit="audio/asc"; url="http://example.com/cardinal.asc"; cid="azsldkaslkdjqpwojdkmsldkfpe"
0 0IN IP6v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5006RTP/AVPと等しい、96 97、c、IN IP6 2001: =DB80:、:7F2E: 172A:1E24 a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=13。 musicport=5 a=rtpmap: 97 mpeg4-ジェネリック/44100a=fmtp: 97streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=13。 musicport=6。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 urlは" http://example.com/cardinal.asc "と等しいです。 Cidは"azsldkaslkdjqpwojdkmsldkfpe"と等しいです。
(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それらはSDPの単線を包括します。)
The sequential musicport values for the two sessions establish the ordered relationship. The musicport=5 session maps to Structured Audio extended channels range 0-15, the musicport=6 session maps to Structured Audio extended channels range 16-31.
2つのセッションのための連続したmusicport値は命令された関係を確立します。 Structured Audioの拡張チャンネルへのmusicport=5セッション地図は0-15に及んで、Structured Audioの拡張チャンネルへのmusicport=6セッション地図は16-31に及びます。
Both config strings are empty. The configuration data is specified by parameters that appear in the fmtp line of the second media description. We define this configuration method in Appendix C.6.
両方のコンフィグストリングは空です。 コンフィギュレーション・データは2番目のメディア記述のfmtp系列に現れるパラメタによって指定されます。 私たちはAppendix C.6のこの構成メソッドを定義します。
Lazzaro & Wawrzynek Standards Track [Page 126] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[126ページ]。
The next example shows two RTP MIDI streams (one recvonly, one sendonly) that form a "virtual sendrecv" session. Each stream resides in a different RTP session (a requirement because sendonly and recvonly are RTP session attributes).
次の例はそのフォーム「仮想のsendrecv」セッションのときに2つのRTP MIDIストリーム(1recvonly、1sendonly)を示しています。 各ストリームは異なったRTPセッションのときにあります(sendonlyであって、recvonlyであるので、要件はRTPセッション属性です)。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 a=group:FID 1 2 c=IN IP4 192.0.2.94 m=audio 5004 RTP/AVP 96 a=sendonly a=rtpmap:96 mpeg4-generic/44100 a=mid:1 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; config=7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000; musicport=12 m=audio 5006 RTP/AVP 96 a=recvonly a=rtpmap:96 mpeg4-generic/44100 a=mid:2 a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; config=7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000; musicport=12
IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例tが=グループ: FIDあたり0 0と等しい、1 2、c、=IN IP4、192.0、.2、.94m、=オーディオの5004RTP/AVP96a=sendonly a=rtpmap: 96 mpeg4-ジェネリック/44100a=中間:、1 a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 プロフィール平らなイドの=12。 コンフィグは7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000と等しいです。 musicport=12m=オーディオの5006RTP/AVP96a=recvonly a=rtpmap: 96 mpeg4-ジェネリック/44100a=中間:、2 a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 プロフィール平らなイドの=12。 コンフィグは7A0A0000001A4D546864000000060000000100604D54726B0 000000600FF2F000と等しいです。 musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それらはSDPの単線を包括します。)
To signal the "virtual sendrecv" semantics, the two streams assign musicport to the same value (12). As defined earlier in this section, pairs of identity relationship streams that are sent by different parties share the association that is shared by a MIDI cable pair that cross-connects two devices in a MIDI 1.0 network. We use the term "virtual sendrecv" because streams sent by different parties in a true sendrecv session also have this property.
「仮想のsendrecv」意味論に合図するために、2つのストリームが同じ値(12)にmusicportを割り当てます。 より早く定義されて、このセクション、送られる組のアイデンティティ関係ストリームでは異なったパーティーが協会を共有するように、MIDIによって共有されて、MIDI1.0ネットワークにおける2台のデバイスにどんなその十字接続にも電報を打たないでください。 また、本当のsendrecvセッションのときに異なったパーティーによって送られた小川がこの特性を持っているので、私たちは「仮想のsendrecv」という用語を使用します。
As discussed in the preamble to Appendix C, the primary advantage of the virtual sendrecv configuration is that each party can customize the property of the stream it receives. In the example above, each stream defines its own "config" string that could customize the rendering algorithm for each party (in fact, the particular strings shown in this example are identical, because General MIDI is not a configurable MPEG 4 renderer).
序文でAppendix Cと議論するように、仮想のsendrecv構成のプライマリ利点は各当事者がそれが受けるストリームの特性をカスタム設計できるということです。 例では、上では、各ストリームが各当事者のためのレンダリングアルゴリズムをカスタム設計できたそれ自身の「コンフィグ」ストリングを定義します(事実上、この例で見せられた特定のストリングが同じです、ジェネラルミディが構成可能なMPEG4レンダラーでないので)。
Lazzaro & Wawrzynek Standards Track [Page 127] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[127ページ]。
C.6. Configuration Tools: MIDI Rendering
C.6。 構成ツール: ミディレンダリング
This appendix defines the session configuration tools for rendering.
この付録はレンダリングのためにセッション構成ツールを定義します。
The "render" parameter specifies a rendering method for a stream. The parameter is assigned a token value that signals the top-level rendering class. This memo defines four token values for render: "unknown", "synthetic", "api", and "null":
「レンダリング」パラメタはレンダリングメソッドをストリームに指定します。 トップレベルレンダリングのクラスを示すトークン値はパラメタに割り当てられます。 このメモが4つのトークン値を定義する、レンダリングします: 「未知」の、そして、「合成」の"api"、および「ヌル」:
o An "unknown" renderer is a renderer whose nature is unspecified.
It is the default renderer for native RTP MIDI streams.
o 「未知」のレンダラーは本質が不特定であるレンダラーです。 それはネイティブのRTP MIDIストリームのためのデフォルトレンダラーです。
o A "synthetic" renderer transforms the MIDI stream into audio
output (or sometimes into stage lighting changes or other
actions). It is the default renderer for mpeg4-generic RTP MIDI
streams.
o 「合成」のレンダラーはMIDIストリームをオーディオ出力(または時々舞台照明変化か他の動作に)に変えます。 それはmpeg4-ジェネリックRTP MIDIストリームのためのデフォルトレンダラーです。
o An "api" renderer presents the command stream to applications
via an Application Programmer Interface (API).
o "api"レンダラーはApplication Programmer Interface(API)を通してコマンドストリームをアプリケーションに提示します。
o The "null" renderer discards the MIDI stream.
o 「ヌル」のレンダラーはMIDIストリームを捨てます。
The "null" render value plays special roles during Offer/Answer negotiations [RFC3264]. A party uses the "null" value in an answer to reject an offered renderer. Note that rejecting a renderer is independent from rejecting a payload type (coded by removing the payload type from a media line) and rejecting a media stream (coded by zeroing the port of a media line that uses the renderer).
「ヌル」はOffer/答え交渉[RFC3264]の間、特別な役割を値の劇にします。 パーティーは、提供されたレンダラーを拒絶するのに答えに「ヌル」の値を使用します。 レンダラーを拒絶するのがペイロードタイプを拒絶して(メディア系列からペイロードタイプを外すことによって、コード化されます)、メディアストリームを拒絶するので(レンダラーを使用するメディア系列のポートのゼロを合わせることによって、コード化されます)独立していることに注意してください。
Other render token values MAY be registered with IANA. The token value MUST adhere to the ABNF for render tokens defined in Appendix D. Registrations MUST include a complete specification of parameter value usage, similar in depth to the specifications that appear throughout Appendix C.6 for "synthetic" and "api" render values. If a party is offered a session description that uses a render token value that is not known to the party, the party MUST NOT accept the renderer. Options include rejecting the renderer (using the "null" value), the payload type, the media stream, or the session description.
もう一方はIANAを値が示されるかもしれないトークンにします。 Appendix D.でトークンを定義するようにしてください。トークン値がABNFに付着しなければならない、Registrationsはパラメタ値の用法の完全な仕様を含まなければなりません、深さでは、Appendix C.6中で「合成品」に見えて、「apiに」値をレンダリングする仕様と同様です。 用途aがパーティーにおいて知られていないトークン値をするセッション記述をパーティーに提供するなら、パーティーはレンダラーを受け入れてはいけません。 オプションは、レンダラー(「ヌル」の値を使用する)、ペイロードタイプ、メディアストリーム、またはセッション記述を拒絶するのを含んでいます。
Other parameters MAY follow a render parameter in a parameter list. The additional parameters act to define the exact nature of the renderer. For example, the "subrender" parameter (defined in Appendix C.6.2) specifies the exact nature of the renderer.
aがパラメタを表す他のパラメタ5月の尾行はパラメタに記載します。 追加パラメタは、レンダラーの正確な自然を定義するために行動します。 例えば、"subrender"パラメタ(Appendix C.6.2では、定義される)はレンダラーの正確な自然を指定します。
Special rules apply to using the render parameter in an mpeg4-generic stream. We define these rules in Appendix C.6.5.
特別な規則が使用に適用される、mpeg4-ジェネリックストリームにパラメタを表してください。 私たちはAppendix C.6.5のこれらの規則を定義します。
Lazzaro & Wawrzynek Standards Track [Page 128] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[128ページ]。
C.6.1. The multimode Parameter
C.6.1。 マルチモードParameter
A media description MAY contain several render parameters. By default, if a parameter list includes several render parameters, a receiver MUST choose exactly one renderer from the list to render the stream. The "multimode" parameter may be used to override this default. We define two token values for multimode: "one" and "all":
メディア記述は数個を含むかもしれません。パラメタを表します。 パラメータ・リストが数個を含んでいるなら、デフォルトで、パラメタを表してください、そして、受信機は、ストリームをレンダリングするためにリストからちょうど1つのレンダラーを選ばなければなりません。 「マルチモード」パラメタは、このデフォルトをくつがえすのに使用されるかもしれません。 私たちはマルチモードのために2つのトークン値を定義します: 「1つ」と「すべて」:
o The default "one" value requests rendering by exactly one of the
listed renderers.
o デフォルト「1つ」価値はちょうど記載されたレンダラーの1つからレンダリングを要求します。
o The "all" value requests the synchronized rendering of the RTP
MIDI stream by all listed renderers, if possible.
o 可能であるなら、「すべて」値はすべての記載されたレンダラーからRTP MIDIストリームの連動しているレンダリングを要求します。
If the multimode parameter appears in a parameter list, it MUST appear before the first render parameter assignment.
マルチモードパラメタがパラメータ・リストに現れるなら、1番目がパラメタ課題を表す前にそれは現れなければなりません。
Render parameters appear in the parameter list in order of decreasing priority. A receiver MAY use the priority ordering to decide which renderer(s) to retain in a session.
レンダリング、優先権を減少させることの順にパラメタはパラメータ・リストに現れます。 受信機は、セッションのときにどのレンダラーを保有したらよいかを決めるのに優先権注文を使用するかもしれません。
If the "offer" in an Offer/Answer-style negotiation [RFC3264] contains a parameter list with one or more render parameters, the "answer" MUST set the render parameters of all unchosen renderers to "null".
答えOffer/スタイル交渉[RFC3264]における「申し出」が1があるパラメータ・リストを含んでいるか、または以上がパラメタを表すなら、「答え」がセットしなければならない、すべてのunchosenレンダラーのパラメタを「ヌル」に提供してください。
C.6.2. Renderer Specification
C.6.2。 レンダラー仕様
The render parameter (Appendix C.6 preamble) specifies, in a broad sense, what a renderer does with a MIDI stream. In this appendix, we describe the "subrender" parameter. The token value assigned to subrender defines the exact nature of the renderer. Thus, "render" and "subrender" combine to define a renderer, in the same way as MIME types and MIME subtypes combine to define a type of media [RFC2045].
レンダラーがMIDIストリームですることを(付録C.6序文)が広い意味で指定するパラメタにしてください。 この付録では、私たちは"subrender"パラメタについて説明します。 subrenderに割り当てられたトークン値はレンダラーの正確な自然を定義します。 したがって、「レンダリング」と"subrender"は結合して、レンダラーを定義します、MIMEの種類とMIME血液型亜型が結合して、一種のメディア[RFC2045]を定義するのと同様に。
If the subrender parameter is used for a renderer definition, it MUST appear immediately after the render parameter in the parameter list. At most one subrender parameter may appear in a renderer definition.
よりsubrenderなパラメタがレンダラー定義に使用されるなら、直後に現れなければならない、パラメータ・リストのパラメタを表してください。 高々、1つのsubrenderパラメタがレンダラー定義に現れるかもしれません。
This document defines one value for subrender: the value "default". The "default" token specifies the use of the default renderer for the stream type (native or mpeg4-generic). The default renderer for native RTP MIDI streams is a renderer whose nature is unspecified (see point 6 in Section 6.1 for details). The default renderer for mpeg4-generic RTP MIDI streams is an MPEG 4 Audio Object Type whose ID number is 13, 14, or 15 (see Section 6.2 for details).
このドキュメントはsubrenderのために1つの値を定義します: 値の「デフォルト。」 「デフォルト」トークンはデフォルトレンダラーのストリーム型(ネイティブかmpeg4-ジェネリック)の使用を指定します。 ネイティブのRTP MIDIストリームのためのデフォルトレンダラーは本質が不特定であるレンダラー(セクション6.1で詳細に関して点6がわかる)です。 mpeg4-ジェネリックRTP MIDIストリームのためのデフォルトレンダラーはID番号が13、14、または15であるMPEG4Audio Object Type(詳細に関してセクション6.2を見る)です。
Lazzaro & Wawrzynek Standards Track [Page 129] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[129ページ]。
If a renderer definition does not use the subrender parameter, the value "default" is assumed for subrender.
レンダラー定義がsubrenderパラメタを使用しないなら、値の「デフォルト」はsubrenderのために想定されます。
Other subrender token values may be registered with IANA. We now discuss guidelines for registering subrender values.
他のsubrenderトークン値はIANAに示されるかもしれません。 私たちは現在、subrender値を示すためのガイドラインについて議論します。
A subrender value is registered for a specific stream type (native or mpeg4-generic) and a specific render value (excluding "null" and "unknown"). Registrations for mpeg4-generic subrender values are restricted to new MPEG 4 Audio Object Types that accept MIDI input. The syntax of the token MUST adhere to the token definition in Appendix D.
subrender値は特定のストリーム型(ネイティブかmpeg4-ジェネリック)のために示されます、そして、詳細は値(「ヌル」と「未知」を除いた)をレンダリングします。 mpeg4-ジェネリックsubrender値のための登録証明書はMIDI入力を受け入れる新しいMPEG4Audio Object Typesに制限されます。 トークンの構文はAppendix Dとのトークン定義を固く守らなければなりません。
For "render=synthetic" renderers, a subrender value registration specifies an exact method for transforming the MIDI stream into audio (or sometimes into video or control actions, such as stage lighting). For standardized renderers, this specification is usually a pointer to a standards document, perhaps supplemented by RTP-MIDI-specific information. For commercial products and open-source projects, this specification usually takes the form of instructions for interfacing the RTP MIDI stream with the product or project software. A "render=synthetic" registration MAY specify additional Reset State commands for the renderer (Appendix A.1).
「=を合成するようにしてください」というレンダラーとして、subrender値の登録はMIDIストリームをオーディオ(または時々ビデオか舞台照明などのコントロール動作に)に変えるための正確なメソッドを指定します。 標準化されたレンダラーに関しては、通常、この仕様は恐らくRTP-MIDI-特殊情報によって補われた規格文書への指針です。 商品とオープンソース・プロジェクトのために、通常、この仕様は製品かプロジェクトソフトウェアにRTP MIDIストリームを接続するための指示の形を取ります。 登録が指定するかもしれない「=を合成するようにしてください」追加Reset州はレンダラー(付録A.1)のために命令します。
A "render=api" subrender value registration specifies how an RTP MIDI stream interfaces with an API (Application Programmers Interface). This specification is usually a pointer to programmer's documentation for the API, perhaps supplemented by RTP-MIDI-specific information.
「=apiをレンダリングしてください」というsubrender値の登録はRTP MIDIストリームがどうAPI(アプリケーションProgrammers Interface)に連結するかを指定します。 通常、この仕様は恐らくRTP-MIDI-特殊情報によって補われたAPIのためのプログラマのドキュメンテーションへの指針です。
A subrender registration MAY specify an initialization file (referred to in this document as an initialization data object) for the stream. The initialization data object MAY be encoded in the parameter list (verbatim or by reference) using the coding tools defined in Appendix C.6.3. An initialization data object MUST have a registered [RFC4288] media type and subtype [RFC2045].
subrender登録は初期化ファイルをストリームに指定するかもしれません(本書では初期化データ・オブジェクトに言及されます)。 初期化データ・オブジェクトはAppendix C.6.3で定義されたコーディング・ツールを使用するパラメータ・リスト(逐語的か参照による)でコード化されるかもしれません。 初期化データ・オブジェクトには、登録された[RFC4288]メディアタイプと「副-タイプ」[RFC2045]がなければなりません。
For "render=synthetic" renderers, the data object usually encodes initialization data for the renderer (sample files, synthesis patch parameters, reverberation room impulse responses, etc.).
「=を合成するようにしてください」というレンダラーに関しては、通常、データ・オブジェクトはレンダラー(サンプルファイル、統合パッチパラメタ、残響室インパルス応答など)のための初期化データをコード化します。
For "render=api" renderers, the data object usually encodes data about the stream used by the API (for example, for an RTP MIDI stream generated by a piano keyboard controller, the manufacturer and model number of the keyboard, for use in GUI presentation).
「=apiをレンダリングしてください」というレンダラーに関しては、API(例えばキーボードのピアノキーボードコントローラによって生成されたRTP MIDIストリーム、メーカー、および型番、GUIプレゼンテーションにおける使用のために)によって使用されるストリームに関して通常、データ・オブジェクトはデータを暗号化します。
Lazzaro & Wawrzynek Standards Track [Page 130] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[130ページ]。
Usually, only one initialization object is encoded for a renderer. If a renderer uses multiple data objects, the correct receiver interpretation of multiple data objects MUST be defined in the subrender registration.
1個の初期化オブジェクトだけがレンダラーのためにコード化されます。 レンダラーが複数のデータ・オブジェクトを使用するなら、subrender登録で複数のデータ・オブジェクトの正しい受信機解釈を定義しなければなりません。
A subrender value registration may also specify additional
parameters, to appear in the parameter list immediately after
subrender. These parameter names MUST begin with the subrender
value, followed by an underscore ("_"), to avoid name space
collisions with future RTP MIDI parameter names (for example, a
parameter "foo_bar" defined for subrender value "foo").
また、subrender値の登録は、subrender直後パラメータ・リストに現れるように追加パラメタを指定するかもしれません。 これらのパラメタ名は強調("_")があとに続いたsubrender値で将来のRTPミディパラメタ名との名前宇宙衝突を避け始めなければなりません(例えば、「foo_バー」というパラメタはsubrender値のために"foo"を定義しました)。
We now specify guidelines for interpreting the subrender parameter during session configuration.
私たちは現在、セッション構成の間、subrenderパラメタを解釈するためのガイドラインを指定します。
If a party is offered a session description that uses a renderer whose subrender value is not known to the party, the party MUST NOT accept the renderer. Options include rejecting the renderer (using the "null" value), the payload type, the media stream, or the session description.
subrender値がパーティーにおいて知られていないレンダラーを使用するセッション記述をパーティーに提供するなら、パーティーはレンダラーを受け入れてはいけません。 オプションは、レンダラー(「ヌル」の値を使用する)、ペイロードタイプ、メディアストリーム、またはセッション記述を拒絶するのを含んでいます。
Receivers MUST be aware of the Reset State commands (Appendix A.1) for the renderer specified by the subrender parameter and MUST insure that the renderer does not experience indefinite artifacts due to the presence (or the loss) of a Reset State command.
受信機は、subrenderパラメタによって指定されたレンダラーのためのReset州コマンド(付録A.1)を意識していなければならなくて、Reset州コマンドの存在(または、損失)のためレンダラーが無期人工物を経験しないのを保障しなければなりません。
C.6.3. Renderer Initialization
C.6.3。 レンダラー初期設定
If the renderer for a stream uses an initialization data object, an "rinit" parameter MUST appear in the parameter list immediately after the "subrender" parameter. If the renderer parameter list does not include a subrender parameter (recall the semantics for "default" in Appendix C.6.2), the "rinit" parameter MUST appear immediately after the "render" parameter.
ストリームのためのレンダラーが初期化データ・オブジェクトを使用するなら、"rinit"パラメタは"subrender"パラメタ直後パラメータ・リストに現れなければなりません。 レンダラーパラメータ・リストがsubrenderパラメタ(Appendix C.6.2の「デフォルト」のための意味論を思い出す)を含んでいないなら、"rinit"パラメタは「レンダリング」パラメタ直後現れなければなりません。
The value assigned to the rinit parameter MUST be the media type/subtype [RFC2045] for the initialization data object. If an initialization object type is registered with several media types, including audio, the assignment to rinit MUST use the audio media type.
rinitパラメタに割り当てられた値は初期化データ・オブジェクトのためのメディアタイプ/「副-タイプ」でなければなりません[RFC2045]。 初期化オブジェクト・タイプがオーディオを含むいくつかのメディアタイプに示されるなら、rinitへの課題はオーディオメディアタイプを使用しなければなりません。
RTP MIDI supports several parameters for encoding initialization data objects for renderers in the parameter list: "inline", "url", and "cid".
RTP MIDIはパラメータ・リストのレンダラーのために初期化データ・オブジェクトをコード化するためのいくつかのパラメタをサポートします: 「インライン」、"url"、および「Cid。」
If the "inline", "url", and/or "cid" parameters are used by a renderer, these parameters MUST immediately follow the "rinit" parameter.
「インライン」、"url"、そして/または、「Cid」パラメタがレンダラーによって使用されるなら、これらのパラメタはすぐに、"rinit"パラメタに従わなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 131] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[131ページ]。
If a "url" parameter appears for a renderer, an "inline" parameter MUST NOT appear. If an "inline" parameter appears for a renderer, a "url" parameter MUST NOT appear. However, neither "url" or "inline" is required to appear. If neither "url" or "inline" parameters follow "rinit", the "cid" parameter MUST follow "rinit".
"url"パラメタがレンダラーの弁護に出廷するなら、「インライン」のパラメタは現れてはいけません。 「インライン」のパラメタがレンダラーの弁護に出廷するなら、"url"パラメタは現れてはいけません。 しかしながら、"url"も「インライン」も、現れるのに必要ではありません。 "url"も「インライン」のパラメタも"rinit"に続かないなら、「Cid」パラメタは"rinit"に続かなければなりません。
The "inline" parameter supports the inline encoding of the data object. The parameter is assigned a double-quoted Base64 [RFC2045] encoding of the binary data object, with no line breaks. Appendix E.4 shows an example that constructs an inline parameter value.
「インライン」のパラメタはデータ・オブジェクトのインラインコード化をサポートします。 バイナリ・データオブジェクトがラインブレイクなしでコード化されながら、二重に引用されたBase64[RFC2045]はパラメタに割り当てられます。 付録E.4はインラインパラメタ値を構成する例を示しています。
The "url" parameter is assigned a double-quoted string representation of a Uniform Resource Locator (URL) for the data object. The string MUST specify a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY be used over TCP or MAY be used over a secure network transport, such as the method described in [RFC2818]. The media type/subtype for the data object SHOULD be specified in the appropriate HTTP transport header.
Uniform Resource Locator(URL)の二重引用文字列表現はデータ・オブジェクトのために"url"パラメタに割り当てられます。 ストリングはHyperText TransportプロトコルURL(HTTP、[RFC2616])を指定しなければなりません。 HTTPは、TCPの上で使用されるか、または安全なネットワーク輸送の上で使用されるかもしれません、[RFC2818]で説明されたメソッドなどのように。 指定されていて、メディアはデータ・オブジェクトSHOULDのために適切なHTTP輸送ヘッダーに/「副-タイプ」をタイプします。
The "cid" parameter supports data object caching. The parameter is assigned a double-quoted string value that encodes a globally unique identifier for the data object.
「Cid」パラメタはデータ・オブジェクトキャッシュをサポートします。 データ・オブジェクトのためのグローバルにユニークな識別子をコード化する二重引用文字列値はパラメタに割り当てられます。
A cid parameter MAY immediately follow an inline parameter, in which case the cid identifier value MUST be associated with the inline data object.
Cidパラメタはすぐにインラインパラメタに従うかもしれません、その場合、Cid識別子価値がインラインデータ・オブジェクトに関連しているに違いありません。
If a url parameter is present, and if the data object for the URL is expected to be unchanged for the life of the URL, a cid parameter MAY immediately follow the url parameter. The cid identifier value MUST be associated with the data object for the URL. A cid parameter assigned to the same identifier value SHOULD be specified following the data object type/subtype in the appropriate HTTP transport header.
urlパラメタが存在していて、URLのためのデータ・オブジェクトがURLの寿命に変わりがないと予想されるなら、Cidパラメタはすぐに、urlパラメタに従うかもしれません。 Cid識別子価値はURLのためのデータ・オブジェクトに関連しているに違いありません。 適切なHTTP輸送ヘッダーでデータオブジェクト・タイプ/「副-タイプ」に続いて、指定されていて、Cidパラメタは値のSHOULDを同じ識別子に割り当てました。
If a url parameter is present, and if the data object for the URL is expected to change during the life of the URL, a cid parameter MUST NOT follow the url parameter. A receiver interprets the presence of a cid parameter as an indication that it is safe to use a cached copy of the url data object; the absence of a cid parameter is an indication that it is not safe to use a cached copy, as it may change.
urlパラメタが存在していて、URLのためのデータ・オブジェクトがURLの寿命の間、変化すると予想されるなら、Cidパラメタはurlパラメタに従ってはいけません。 受信機はurlデータ・オブジェクトのキャッシュされたコピーを使用するのが安全であるという指示としてCidパラメタの存在を解釈します。 Cidパラメタの欠如はキャッシュされたコピーを使用するのが安全でないという指示です、変化するとき。
Finally, the cid parameter MAY be used without the inline and url parameters. In this case, the identifier references a local or distributed catalog of data objects.
最終的に、Cidパラメタはインラインとurlパラメタなしで使用されるかもしれません。 この場合、識別子はデータ・オブジェクトの地方の、または、分配されたカタログに参照をつけます。
Lazzaro & Wawrzynek Standards Track [Page 132] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[132ページ]。
In most cases, only one data object is coded in the parameter list for each renderer. For example, the default renderer for mpeg4- generic streams uses a single data object (see Appendix C.6.5 for example usage).
多くの場合、1個のデータ・オブジェクトだけが各レンダラーのためのパラメータ・リストでコード化されます。 例えば、mpeg4ジェネリックストリームのためのデフォルトレンダラーが単一のデータ・オブジェクトを使用する、(Appendix C.6.5を見てください、例えば、用法)
However, a subrender registration MAY permit the use of multiple data objects for a renderer. If multiple data objects are encoded for a renderer, each object encoding begins with an "rinit" parameter, followed by "inline", "url", and/or "cid" parameters.
しかしながら、subrender登録は複数のデータ・オブジェクトのレンダラーの使用を可能にするかもしれません。 複数のデータ・オブジェクトがレンダラーのためにコード化されるなら、それぞれのオブジェクトコード化は「インライン」、"url"、そして/または、「Cid」パラメタがあとに続いた"rinit"パラメタで始まります。
Initialization data objects MAY encapsulate a Standard MIDI File (SMF). By default, the SMFs that are encapsulated in a data object MUST be ignored by an RTP MIDI receiver. We define parameters to override this default in Appendix C.6.4.
初期設定データ・オブジェクトは、StandardがMIDIファイル(SMF)であるとカプセル化するかもしれません。 デフォルトで、RTP MIDI受信機でデータ・オブジェクトでカプセル化されるSMFsを無視しなければなりません。私たちは、Appendix C.6.4のこのデフォルトをくつがえすためにパラメタを定義します。
To end this section, we offer guidelines for registering media types for initialization data objects. These guidelines are in addition to the information in [RFC4288] [RFC4289].
このセクションを終わらせるために、私たちは初期化データ・オブジェクトのためにメディアタイプを示すためにガイドラインを提供します。 これらのガイドラインは[RFC4288][RFC4289]の情報に加えています。
Some initialization data objects are also capable of encoding MIDI note information and thus complete audio performances. These objects SHOULD be registered using the "audio" media type, so that the objects may also be used for store-and-forward rendering, and "application" media type, to support editing tools. Initialization objects without note storage, or initialization objects for non-audio renderers, SHOULD be registered only for an "application" media type.
また、いくつかの初期化データ・オブジェクトがMIDI注意情報とその結果完全なオーディオ性能をコード化できます。 これらのオブジェクトSHOULDが「オーディオ」メディアタイプを使用することで登録されて、したがって、また、オブジェクトが店とフォワードレンダリング、および「アプリケーション」メディアに使用されるかもしれないのは、編集ツールをサポートするためにタイプされます。 登録されていて、単に「アプリケーション」メディアがタイプされるので、初期設定は注意ストレージも、または非オーディオレンダラーのための初期化オブジェクト、SHOULDなしで反対します。
C.6.4. MIDI Channel Mapping
C.6.4。 ミディチャンネルマッピング
In this appendix, we specify how to map MIDI name spaces (16 voice channels + systems) onto a renderer.
この付録では、私たちはMIDI名前空間(16台の音声チャンネル+システム)をレンダラーに写像する方法を指定します。
In the general case:
司令官では、以下をケースに入れてください。
o A session may define an ordered relationship (Appendix C.5) that
presents more than one MIDI name space to a renderer.
o セッションは1MIDIに名前スペースを提示する命令された関係(付録C.5)をレンダラーと定義するかもしれません。
o A renderer may accept an arbitrary number of MIDI name spaces,
or it may expect a specific number of MIDI name spaces.
o レンダラーがMIDI名前空間の特殊活字の数字を受け入れるかもしれませんか、またはそれは特定の数のMIDI名前空間を予想するかもしれません。
A session description SHOULD provide a compatible MIDI name space to each renderer in the session. If a receiver detects that a session description has too many or too few MIDI name spaces for a renderer, MIDI data from extra stream name spaces MUST be discarded, and extra renderer name spaces MUST NOT be driven with MIDI data (except as described in Appendix C.6.4.1, below).
記述SHOULDがセッションのときにコンパチブルMIDI名前スペースを各レンダラーに提供するセッション。 受信機がそれを検出するなら、セッション記述には、レンダラーのための多く過ぎるかあまりにわずかなMIDI名前空間しかありません、そして、付加的なストリーム名前空間からのMIDIデータを捨てなければなりません、そして、付加的なレンダラー名前空間はMIDIデータ(Appendix C.6.4.1で説明されるのを除いて以下で)で追い立てられてはいけません。
Lazzaro & Wawrzynek Standards Track [Page 133] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[133ページ]。
If a parameter list defines several renderers and assigns the "all" token value to the multimode parameter, the same name space is presented to each renderer. However, the "chanmask" parameter may be used to mask out selected voice channels to each renderer. We define "chanmask" and other MIDI management parameters in the sub-sections below.
パラメータ・リストがいくつかのレンダラーを定義して、「すべて」トークン価値をマルチモードパラメタに割り当てるなら、同じ名前スペースは各レンダラーに提示されます。 しかしながら、"chanmask"パラメタは、選択された音声チャンネルを各レンダラーまで覆い隠すのに使用されるかもしれません。 私たちは以下の小区分で"chanmask"と他のMIDI管理パラメタを定義します。
C.6.4.1. The smf_info Parameter
C.6.4.1。 smf_インフォメーションParameter
The smf_info parameter defines the use of the SMFs encapsulated in renderer data objects (if any). The smf_info parameter also defines the use of SMFs coded in the smf_inline, smf_url, and smf_cid parameters (defined in Appendix C.6.4.2).
smf_インフォメーションパラメタは(もしあれば)のレンダラーデータ・オブジェクトでカプセル化されたSMFsの使用を定義します。 また、smf_インフォメーションパラメタはsmf_インラインでコード化されたSMFs、smf_url、およびsmf_Cidパラメタ(Appendix C.6.4.2では、定義される)の使用を定義します。
The smf_info parameter describes the "render" parameter that most recently precedes it in the parameter list. The smf_info parameter MUST NOT appear in parameter lists that do not use the "render" parameter, and MUST NOT appear before the first use of "render" in the parameter list.
smf_インフォメーションパラメタはごく最近パラメータ・リストでそれに先行する「レンダリング」パラメタについて説明します。 smf_インフォメーションパラメタは、「レンダリング」パラメタを使用しないパラメータ・リストに現れてはいけなくて、パラメータ・リストにおける「レンダリング」の最初の使用の前に現れてはいけません。
We define three token values for smf_info: "ignore", "sdp_start", and "identity":
私たちはsmf_インフォメーションのために3つのトークン値を定義します: 「無視」、「sdp_始め」、および「アイデンティティ」:
o The "ignore" value indicates that the SMFs MUST be discarded.
This behavior is the default SMF rendering behavior.
o 「無視」値は、SMFsを捨てなければならないのを示します。 この振舞いはデフォルトSMFレンダリングの振舞いです。
o The "sdp_start" value codes that SMFs MUST be rendered, and that
the rendering MUST begin upon the acceptance of the session
description. If a receiver is offered a session description
with a renderer that uses an smf_info parameter set to
sdp_start, and if the receiver does not support rendering SMFs,
the receiver MUST NOT accept the renderer associated with the
smf_info parameter. Options include rejecting the renderer (by
setting the "render" parameter to "null"), the payload type, the
media stream, or the entire session description.
o 「sdp_始め」値はレンダリングがSMFsをレンダリングしなければならなくて、セッション記述の承認のときに始めなければならないそれをコード化します。 受信機が、レンダリングがSMFsであるとサポートしないならsmf_インフォメーションパラメタセットをsdp_始めに使用するレンダラーがあるセッション記述を受信機に提供するなら、受信機は、レンダラーがsmf_インフォメーションパラメタに関連していると受け入れてはいけません。 オプションは、レンダラー(「レンダリング」パラメタを「ヌル」に設定するのによる)、ペイロードタイプ、メディアストリーム、または全体のセッション記述を拒絶するのを含んでいます。
o The "identity" value indicates that the SMFs code the identity
of the renderer. The value is meant for use with the "unknown"
renderer (see Appendix C.6 preamble). The MIDI commands coded
in the SMF are informational in nature and MUST NOT be presented
to a renderer for audio presentation. In typical use, the SMF
would use SysEx Identity Reply commands (F0 7E nn 06 02, as
defined in [MIDI]) to identify devices, and use device-specific
SysEx commands to describe current state of the devices (patch
memory contents, etc.).
o 「アイデンティティ」値は、SMFsがレンダラーのアイデンティティをコード化するのを示します。 値は「未知」のレンダラーがある使用のために意味されます(Appendix C.6序文を見てください)。 SMFでコード化されたMIDIコマンドは、現実に情報であり、オーディオプレゼンテーションのためにレンダラーに提示されてはいけません。 典型的な使用で、SMFはデバイスを特定するSysEx Identity Replyコマンド(中で定義されるとしてのF0 7E nn06 02[MIDI])を使用して、デバイス(パッチ記憶内容など)の現状について説明するデバイス特有のSysExコマンドを使用するでしょう。
Other smf_info token values MAY be registered with IANA. The token value MUST adhere to the ABNF for render tokens defined in Appendix
他のsmf_インフォメーショントークン値はIANAに示されるかもしれません。 値がABNFに付着しなければならないトークンは、Appendixでトークンを定義するようにレンダリングします。
Lazzaro & Wawrzynek Standards Track [Page 134] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[134ページ]。
D. Registrations MUST include a complete specification of parameter usage, similar in depth to the specifications that appear in this appendix for "sdp_start" and "identity".
D.登録証明書はパラメタ用法の完全な仕様を含まなければなりません、深さでは、この付録に「sdp_始め」と「アイデンティティ」に関して載っている仕様と同様です。
If a party is offered a session description that uses an smf_info parameter value that is not known to the party, the party MUST NOT accept the renderer associated with the smf_info parameter. Options include rejecting the renderer, the payload type, the media stream, or the entire session description.
パーティーにおいて知られていないsmf_インフォメーションパラメタ価値を使用するセッション記述をパーティーに提供するなら、パーティーは、レンダラーがsmf_インフォメーションパラメタに関連していると受け入れてはいけません。 オプションは、レンダラー、ペイロードタイプ、メディアストリーム、または全体のセッション記述を拒絶するのを含んでいます。
We now define the rendering semantics for the "sdp_start" token value in detail.
私たちは現在、「sdp_始め」トークン価値のために詳細にレンダリング意味論を定義します。
The SMFs and RTP MIDI streams in a session description share the same MIDI name space(s). In the simple case of a single RTP MIDI stream and a single SMF, the SMF MIDI commands and RTP MIDI commands are merged into a single name space and presented to the renderer. The indefinite artifact responsibilities for merged MIDI streams defined in Appendix C.5 also apply to merging RTP and SMF MIDI data.
セッション記述におけるSMFsとRTP MIDIストリームは同じMIDI名前スペースを共有します。 ただ一つのRTP MIDIストリームと独身のSMFの簡単な場合では、SMF MIDIコマンドとRTP MIDIコマンドは、ただ一つの名前スペースに合併されていて、レンダラーに提示されます。 また、Appendix C.5で定義された合併しているMIDIストリームへの無期人工物責任はRTPとSMF MIDIデータを合併するのに申請されます。
If a payload type codes multiple SMFs, the SMF name spaces are presented as an ordered entity to the renderer. To determine the ordering of SMFs for a renderer (which SMF is "first", which is "second", etc.), use the following rules:
ペイロードタイプが複数のSMFsをコード化するなら、SMF名前空間は命令された実体としてレンダラーに提示されます。 レンダラーのためにSMFsの注文を決定する、(「最初に」(「2番目」ですなど)がどのSMFであるか、)、以下の規則を使用してください:
o If the renderer uses a single data object, the order of
appearance of the SMFs in the object's internal structure
defines the order of the SMFs (the earliest SMF in the object is
"first", the next SMF in the object is "second", etc.).
o レンダラーが単一のデータ・オブジェクトを使用するなら、オブジェクトの内部の構造のSMFsの外観の注文はSMFsの注文を定義します(オブジェクトで最も前のSMFによる「最初に」オブジェクトの次のSMFが「2番目」であるのなどということです)。
o If multiple data objects are encoded for a renderer, the
appearance of each data object in the parameter list sets the
relative order of the SMFs encoded in each data object (SMFs
encoded in parameters that appear earlier in the list are
ordered before SMFs encoded in parameters that appear later in
the list).
o 複数のデータ・オブジェクトがレンダラーのためにコード化されるなら、パラメータ・リストにおける、それぞれのデータ・オブジェクトの外観は各データ・オブジェクトでコード化されたSMFsの相対オーダを設定します(後でリストに現れるパラメタでコード化されたSMFsの前で、より早くリストに現れるパラメタでコード化されたSMFsを注文します)。
o If SMFs are encoded in data objects parameters and in the
parameters defined in C.6.4.2, the relative order of the data
object parameters and C.6.4.2 parameters in the parameter list
sets the relative order of SMFs (SMFs encoded in parameters that
appear earlier in the list are ordered before SMFs in parameters
that appear later in the list).
o SMFsがデータ・オブジェクトパラメタとC.6.4.2で定義されたパラメタでコード化されるなら、データ・オブジェクトパラメタとパラメタの.2のパラメタがリストアップするC.6.4の相対オーダはSMFsの相対オーダを設定します(後でリストに現れるパラメタでSMFsの前で、より早くリストに現れるパラメタでコード化されたSMFsを注文します)。
Given this ordering of SMFs, we now define the mapping of SMFs to renderer name spaces. The SMF that appears first for a renderer maps to the first renderer name space. The SMF that appears second for a renderer maps to the second renderer name space, etc. If the
SMFsのこの注文を考えて、私たちは現在、レンダラー名前空間とSMFsに関するマッピングを定義します。 最初にレンダラーの弁護に出廷するSMFは最初のレンダラー名にスペースを写像します。 2番目に、レンダラーの弁護に出廷するSMFは2番目のレンダラーに名前スペースなどを写像します。 the
Lazzaro & Wawrzynek Standards Track [Page 135] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[135ページ]。
associated RTP MIDI streams also form an ordered relationship, the first SMF is merged with the first name space of the relationship, the second SMF is merged to the second name space of the relationship, etc.
また、関連RTP MIDIストリームは命令された関係を形成して、最初のSMFは関係の名スペースに合併されています、SMFが関係の2番目の名前スペースなどに合併されている秒に
Unless the streams and the SMFs both use MIDI Time Code, the time offset between SMF and stream data is unspecified. This restriction limits the use of SMFs to applications where synchronization is not critical, such as the transport of System Exclusive commands for renderer initialization, or human-SMF interactivity.
ストリームとSMFsがともにMIDI Time Codeを使用しないなら、SMFとストリームデータの間で相殺された時間は不特定です。 この制限はSMFsの使用を同期が重要でないアプリケーションに制限します、レンダラー初期化のためのSystem Exclusiveコマンド、または人間-SMF対話性の輸送などのように。
Finally, we note that each SMF in the sdp_start discussion above encodes exactly one MIDI name space (16 voice channels + systems). Thus, the use of the Device Name SMF meta event to specify several MIDI name spaces in an SMF is not supported for sdp_start.
最終的に、私たちは、sdp_の各SMFがちょうど1MIDIがスペース(16台の音声チャンネル+システム)と命名するエンコードを超えて議論を始めることに注意します。 したがって、SMFのいくつかのMIDI名前空間を指定するDevice Name SMFメタイベントの使用はsdp_始めにサポートされません。
C.6.4.2. The smf_inline, smf_url, and smf_cid Parameters
C.6.4.2。 smf_インライン、smf_url、およびsmf_Cid Parameters
In some applications, the renderer data object may not encapsulate SMFs, but an application may wish to use SMFs in the manner defined in Appendix C.6.4.1.
使用目的によっては、レンダラーデータ・オブジェクトはSMFsをカプセル化しないかもしれませんが、アプリケーションはAppendix C.6.4.1で定義された方法でSMFsを使用したがっているかもしれません。
The "smf_inline", "smf_url", and "smf_cid" parameters address this situation. These parameters use the syntax and semantics of the inline, url, and cid parameters defined in Appendix C.6.3, except that the encoded data object is an SMF.
「smf_インライン」、「smf_url」、および「smf_Cid」パラメタはこの状況を扱います。 これらのパラメタはパラメタがAppendix C.6.3で定義したインライン、url、およびCidの構文と意味論を使用します、コード化されたデータ・オブジェクトがSMFであるのを除いて。
The "smf_inline", "smf_url", and "smf_cid" parameters belong to the "render" parameter that most recently precedes it in the session description. The "smf_inline", "smf_url", and "smf_cid" parameters MUST NOT appear in parameter lists that do not use the "render" parameter and MUST NOT appear before the first use of "render" in the parameter list. If several "smf_inline", "smf_url", or "smf_cid" parameters appear for a renderer, the order of the parameters defines the SMF name space ordering.
「smf_インライン」、「smf_url」、および「smf_Cid」パラメタはごく最近セッション記述でそれに先行する「レンダリング」パラメタに属します。 「smf_インライン」、「smf_url」、および「smf_Cid」パラメタは、「レンダリング」パラメタを使用しないパラメータ・リストに現れてはいけなくて、パラメータ・リストにおける「レンダリング」の最初の使用の前に現れてはいけません。 いくつかの「smf_インライン」、「smf_url」、または「smf_Cid」パラメタがレンダラーの弁護に出廷するなら、パラメタの注文はSMF名前スペース注文を定義します。
C.6.4.3. The chanmask Parameter
C.6.4.3。 chanmask Parameter
The chanmask parameter instructs the renderer to ignore all MIDI voice commands for certain channel numbers. The parameter value is a concatenated string of "1" and "0" digits. Each string position maps to a MIDI voice channel number (system channels may not be masked). A "1" instructs the renderer to process the voice channel; a "0" instructs the renderer to ignore the voice channel.
chanmaskパラメタは、ある論理機番のためのすべてのMIDI音声命令を無視するようレンダラーに命令します。 パラメタ値が連結されたストリングである、「1インチと「0インチのケタ。」 位置がMIDI声の論理機番(システムチャンネルは仮面でないかもしれない)に写像する各ストリング。 「1インチは、音声チャンネルを処理するようレンダラーに命令します」。 「0インチは、音声チャンネルを無視するようレンダラーに命令します。」
The string length of the chanmask parameter value MUST be 16 (for a single stream or an identity relationship) or a multiple of 16 (for an ordered relationship).
chanmaskパラメタ価値のストリング長は、16(ただ一つのストリームかアイデンティティ関係のための)か16(命令された関係のための)の倍数であるに違いありません。
Lazzaro & Wawrzynek Standards Track [Page 136] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[136ページ]。
The chanmask parameter describes the "render" parameter that most recently precedes it in the session description; chanmask MUST NOT appear in parameter lists that do not use the "render" parameter and MUST NOT appear before the first use of "render" in the parameter list.
chanmaskパラメタはごく最近セッション記述でそれに先行する「レンダリング」パラメタについて説明します。 chanmaskは「レンダリング」パラメタを使用しないパラメータ・リストに現れてはいけなくて、パラメータ・リストにおける「レンダリング」の最初の使用の前に現れてはいけません。
The chanmask parameter describes the final MIDI name spaces presented to the renderer. The SMF and stream components of the MIDI name spaces may not be independently masked.
chanmaskパラメタは空間というレンダラーに提示された最終的なMIDI名について説明します。 空間というMIDI名のSMFとストリーム成分は独自にマスクをかけられないかもしれません。
If a receiver is offered a session description with a renderer that uses the chanmask parameter, and if the receiver does not implement the semantics of the chanmask parameter, the receiver MUST NOT accept the renderer unless the chanmask parameter value contains only "1"s.
受信機がchanmaskパラメタの意味論を実装しないならchanmaskパラメタを使用するレンダラーがあるセッション記述を受信機に提供して、chanmaskパラメタ価値が"1"s"だけ、を含んでいない場合、受信機はレンダラーを受け入れてはいけません。
C.6.5. The audio/asc Media Type
C.6.5。 オーディオ/ascメディアType
In Appendix 11.3, we register the audio/asc media type. The data object for audio/asc is a binary encoding of the AudioSpecificConfig data block used to initialize mpeg4-generic streams (Section 6.2 and [MPEGAUDIO]).
Appendix11.3では、私たちはオーディオ/ascメディアタイプを示します。 オーディオ/ascのためのデータ・オブジェクトはmpeg4-ジェネリックストリームを初期化するのに使用されるAudioSpecificConfigデータ・ブロック(セクション6.2と[MPEGAUDIO])をコード化するバイナリーです。
An mpeg4-generic parameter list MAY use the render, subrender, and rinit parameters with the audio/asc media type for renderer configuration. Several restrictions apply to the use of these parameters in mpeg4-generic parameter lists:
mpeg4-ジェネリックパラメータ・リストが使用するかもしれない、レンダラー構成のためにオーディオ/ascメディアタイプでパラメタをより多くのsubrenderにレンダリングして、rinitします。 いくつかの制限がmpeg4-ジェネリックパラメータ・リストにおけるこれらのパラメタの使用に適用されます:
o An mpeg4-generic media description that uses the render
parameter MUST assign the empty string ("") to the mpeg4-generic
"config" parameter. The use of the streamtype, mode, and
profile-level-id parameters MUST follow the normative text in
Section 6.2.
o それが使用するmpeg4-ジェネリックメディア記述、レンダリング、パラメタが空のストリングを割り当てなければならない、(「「)、mpeg4-ジェネリック「コンフィグ」パラメタに」 streamtype、モード、および平らなイドの輪郭を描いているパラメタの使用はセクション6.2の標準のテキストに従わなければなりません。
o Sessions that use identity or ordered relationships MUST follow
the mpeg4-generic configuration restrictions in Appendix C.5.
o アイデンティティを使用するセッションか命令された関係がAppendix C.5でのmpeg4-ジェネリック構成制限に続かなければなりません。
o The render parameter MUST be assigned the value "synthetic",
"unknown", "null", or a render value that has been added to the
IANA repository for use with mpeg4-generic RTP MIDI streams.
The "api" token value for render MUST NOT be used.
o 値の「合成品」を割り当てなければなりません、「未知である」というパラメタを表してください、「ヌルである」、aがRTP MIDIが. "api"トークン価値を流すmpeg4-ジェネリックがある使用のために高められた価値をIANA倉庫に提供する、レンダリング、使用されてはいけません。
o If a subrender parameter is present, it MUST immediately follow
the render parameter, and it MUST be assigned the token value
"default" or assigned a subrender value added to the IANA
repository for use with mpeg4-generic RTP MIDI streams. A
subrender parameter assignment may be left out of the renderer
configuration, in which case the implied value of subrender is
the default value of "default".
o mpeg4-ジェネリックRTP MIDIとの使用において、IANA倉庫に付加価値が付いた割り当てられたトークン値の「デフォルト」の、または、割り当てられたa subrenderがストリームであったに違いないならパラメタ、およびそれを表してください。subrenderパラメタが存在しているなら、すぐに続かなければならない、subrenderパラメタ課題はレンダラー構成から外されるかもしれなくて、その場合、subrenderの暗示している値は「デフォルト」のデフォルト値です。
Lazzaro & Wawrzynek Standards Track [Page 137] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[137ページ]。
o If the render parameter is assigned the value "synthetic" and
the subrender parameter has the value "default" (assigned or
implied), the rinit parameter MUST be assigned the value
"audio/asc", and an AudioSpecificConfig data object MUST be
encoded using the mechanisms defined in C.6.2-3. The
AudioSpecificConfig data MUST encode one of the MPEG 4 Audio
Object Types defined for use with mpeg4-generic in Section 6.2.
If the subrender value is other than "default", refer to the
subrender registration for information on the use of "audio/asc"
with the renderer.
o レンダリング、値はパラメタに「合成していた」状態で割り当てられて、subrenderパラメタには、値の「デフォルト」(割り当てられるか、または含意される)があって、値の「オーディオ/asc」をrinitパラメタに割り当てなければならなくて、C.6.2-3で定義されたメカニズムを使用して、AudioSpecificConfigデータ・オブジェクトをコード化しなければなりません。 AudioSpecificConfigデータは使用のためにmpeg4-ジェネリックでセクション6.2で定義されたMPEG4Audio Object Typesの1つをコード化しなければなりません。 「デフォルト」を除いて、subrender値があるなら、レンダラーがある「オーディオ/asc」の使用の情報のためのsubrender登録を参照してください。
o If the render parameter is assigned the value "null" or
"unknown", the data object MAY be omitted.
o 値の「ヌル」が割り当てられて、「未知である」というパラメタを表してください、そして、データ・オブジェクトは省略されてもよいです。
Several general restrictions apply to the use of the audio/asc media type in RTP MIDI:
いくつかの一般的な制限がRTP MIDIにおけるオーディオ/ascメディアタイプの使用に適用されます:
o A native stream MUST NOT assign "audio/asc" to rinit. The
audio/asc media type is not intended to be a general-purpose
container for rendering systems outside of MPEG usage.
o ネイティブのストリームは「オーディオ/asc」をrinitに割り当ててはいけません。 オーディオ/ascメディアタイプはMPEG用法の外にシステムを表すための一般用途コンテナであることを意図しません。
o The audio/asc media type defines a stored object type; it does
not define semantics for RTP streams. Thus, audio/asc MUST NOT
appear on an rtpmap line of a session description.
o オーディオ/ascメディアタイプは保存されたオブジェクト・タイプを定義します。 それはRTPストリームのために意味論を定義しません。その結果、オーディオ/ascはセッション記述のrtpmap系列に現れてはいけません。
Below, we show session description examples for audio/asc. The session description below uses the inline parameter to code the AudioSpecificConfig block for a mpeg4-generic General MIDI stream. We derive the value assigned to the inline parameter in Appendix E.4. The subrender token value of "default" is implied by the absence of the subrender parameter in the parameter list.
以下では、私たちがオーディオ/ascのためのセッション記述の例を示しています。 以下でのセッション記述は、mpeg4-ジェネリックジェネラルミディストリームのためのAudioSpecificConfigブロックをコード化するのにインラインパラメタを使用します。 私たちはAppendix E.4のインラインパラメタに割り当てられた値を引き出します。 「デフォルト」のsubrenderトークン価値はパラメータ・リストにおける、subrenderパラメタの欠如で含意されます。
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; render=synthetic; rinit="audio/asc"; inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 インラインは"egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"と等しいです。
(The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それはSDPの単線を包括します。)
Lazzaro & Wawrzynek Standards Track [Page 138] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[138ページ]。
The session description below uses the url parameter to code the AudioSpecificConfig block for the same General MIDI stream:
以下でのセッション記述は同じジェネラルミディストリームのためのAudioSpecificConfigブロックをコード化するのにurlパラメタを使用します:
v=0 o=lazzaro 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 m=audio 5004 RTP/AVP 96 c=IN IP4 192.0.2.94 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; render=synthetic; rinit="audio/asc"; url="http://example.net/oski.asc"; cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
0 0IN IP4v=0 o=lazzaroの2520644554 2838152170の最初の.example.net s=例t=mがオーディオの5004RTP/AVPと等しい、96、c、=IN IP4 192.0.2.94a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 urlは" http://example.net/oski.asc "と等しいです。 Cidは"xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"と等しいです。
(The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp系列を包装してあります; それはSDPの単線を包括します。)
C.7. Interoperability
C.7。 相互運用性
In this appendix, we define interoperability guidelines for two application areas:
この付録では、私たちは2つの応用分野のための相互運用性ガイドラインを定義します:
o MIDI content-streaming applications. RTP MIDI is added to
RTSP-based content-streaming servers, so that viewers may
experience MIDI performances (produced by a specified client-
side renderer) in synchronization with other streams (video,
audio).
o MIDIの内容のストリーミングのアプリケーション。 RTP MIDIはRTSPベースの内容のストリーミングのサーバに追加されます、ビューアーが他のストリーム(ビデオ、オーディオ)との同期でMIDI性能を経験できる(指定されたクライアントサイドレンダラーで、生産される)ように。
o Long-distance network musical performance applications. RTP
MIDI is added to SIP-based voice chat or videoconferencing
programs, as an alternative, or as an addition, to audio and/or
video RTP streams.
o 長距離のネットワーク演奏アプリケーション。 RTP MIDIは代替手段として、または、SIPベースのボイスチャットかテレビ会議プログラムか、追加として加えられます、オーディオ、そして/または、ビデオRTPストリームに。
For each application, we define a core set of functionality that all implementations MUST implement.
各アプリケーションのために、私たちはすべての実装が実装しなければならない1人の巻き癖の機能性を定義します。
The applications we address in this section are not an exhaustive list of potential RTP MIDI uses. We expect framework documents for other applications to be developed, within the IETF or within other organizations. We discuss other potential application areas for RTP MIDI in Section 1 of the main text of this memo.
私たちがこのセクションで扱うアプリケーションは潜在的RTP MIDI用途に関する完全なりストではありません。 私たちは、IETF以内か他の組織の中でフレームワークドキュメントが他のアプリケーションが開発されていると予想します。 私たちはRTP MIDIのためにこのメモの主な原本のセクション1で他の潜在的応用分野について議論します。
C.7.1. MIDI Content Streaming Applications
C.7.1。 ミディ内容ストリーミング・アプリケーション
In content-streaming applications, a user invokes an RTSP client to initiate a request to an RTSP server to view a multimedia session. For example, clicking on a web page link for an Internet Radio
内容のストリーミングのアプリケーションでは、ユーザは、マルチメディアセッションを見るためにRTSPサーバに要求を開始するためにRTSPクライアントを呼び出します。 例えば、インターネットRadioのためにウェブページリンクをクリックすること。
Lazzaro & Wawrzynek Standards Track [Page 139] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[139ページ]。
channel launches an RTSP client that uses the link's RTSP URL to contact the RTSP server hosting the radio channel.
チャンネルはラジオチャンネルをホスティングするRTSPサーバに連絡するのにリンクのRTSP URLを使用するRTSPクライアントを送り出します。
The content may be pre-recorded (for example, on-demand replay of yesterday's football game) or "live" (for example, football game coverage as it occurs), but in either case the user is usually an "audience member" as opposed to a "participant" (as the user would be in telephony).
内容は、あらかじめ記録されるか(例えば、昨日のフットボールの試合の要求次第の再生)、または「住むかもしれません」が(例えば、それとしてのフットボールの試合適用範囲は現れます)、どちらかの場合では、「関係者」と対照的に通常、ユーザは「聴衆のメンバー」(ユーザが電話にいるだろうというとき)です。
Note that these examples describe the distribution of audio content to an audience member. The interoperability guidelines in this appendix address RTP MIDI applications of this nature, not applications such as the transmission of raw MIDI command streams for use in a professional environment (recording studio, performance stage, etc.).
これらの例がオーディオ内容の分配について聴衆のメンバーに説明することに注意してください。 この付録の相互運用性ガイドラインはプロの環境(レコーディングスタジオ、性能ステージなど)における使用のために生のMIDIコマンドストリームの送信などの応用ではなく、この種のアプリケーションをRTP MIDIに扱います。
In an RTSP session, a client accesses a session description that is "declared" by the server, either via the RTSP DESCRIBE method, or via other means, such as HTTP or email. The session description defines the session from the perspective of the client. For example, if a media line in the session description contains a non-zero port number, it encodes the server's preference for the client's port numbers for RTP and RTCP reception. Once media flow begins, the server sends an RTP MIDI stream to the client, which renders it for presentation, perhaps in synchrony with video or other audio streams.
RTSPセッションのときに、クライアントはサーバ、RTSP DESCRIBEメソッドまたは他の手段で「宣言される」セッション記述にアクセスします、HTTPやメールのように。 セッション記述はクライアントの見解からセッションを定義します。 例えば、セッション記述におけるメディア系列が非ゼロポートナンバーを含んでいるなら、それはRTPとRTCPレセプションのためのクライアントのポートナンバーのためにサーバの好みをコード化します。 メディア流動がいったん始まると、サーバはRTP MIDIストリームをクライアントに送ります、恐らくビデオがある同期か他のオーディオストリームで。(そのクライアントは、プレゼンテーションのためにそれをレンダリングします)。
We now define the interoperability text for content-streaming RTSP applications.
私たちは現在、内容のストリーミングのRTSPアプリケーションのために相互運用性テキストを定義します。
In most cases, server interoperability responsibilities are described in terms of limits on the "reference" session description a server provides for a performance if it has no information about the capabilities of the client. The reference session is a "lowest common denominator" session that maximizes the odds that a client will be able to view the session. If a server is aware of the capabilities of the client, the server is free to provide a session description customized for the client in the DESCRIBE reply.
多くの場合、それにクライアントの能力の情報が全くないなら、サーバ相互運用性責任はサーバが性能に提供する「参照」セッション記述における限界で説明されます。 参照セッションはクライアントがセッションを見ることができるという可能性を最大にする「最小公分母」セッションです。 サーバがクライアントの能力を意識しているなら、サーバは無料でクライアントのためにカスタマイズされたセッション記述をDESCRIBE回答に提供できます。
Clients MUST support unicast UDP RTP MIDI streams that use the recovery journal with the closed-loop or the anchor sending policies. Clients MUST be able to interpret stream subsetting and chapter inclusion parameters in the session description that qualify the sending policies. Client support of enhanced Chapter C encoding is OPTIONAL.
クライアントは、閉ループがある回復ジャーナルを使用するユニキャストUDP RTP MIDIストリームかアンカー送付が方針であるとサポートしなければなりません。 クライアントはセッション記述における送付方針に資格を与えるストリーム副設定と章包含パラメタを解釈できなければなりません。 高められた章C コード化のクライアントサポートはOPTIONALです。
The reference session description offered by a server MUST send all RTP MIDI UDP streams as unicast streams that use the recovery journal and the closed-loop or anchor sending policies. Servers SHOULD use
サーバによって提供された参照セッション記述は回復ジャーナルと閉ループするかアンカー送付方針を使用するユニキャストストリームとしてすべてのRTP MIDI UDPストリームを送らなければなりません。 サーバSHOULD使用
Lazzaro & Wawrzynek Standards Track [Page 140] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[140ページ]。
the stream subsetting and chapter inclusion parameters in the reference session description, to simplify the rendering task of the client. Server support of enhanced Chapter C encoding is OPTIONAL.
参照セッション記述における副設定と章包含パラメタを流して、クライアントの表現タスクを簡素化してください。 高められた章C コード化のサーバサポートはOPTIONALです。
Clients and servers MUST support the use of RTSP interleaved mode (a method for interleaving RTP onto the RTSP TCP transport).
はさみ込まれて、クライアントとサーバはRTSPの使用を支持しなければなりません。モード(RTSP TCP輸送にRTPをはさみ込むための方法)。
Clients MUST be able to interpret the timestamp semantics signalled by the "comex" value of the tsmode parameter (i.e., the timestamp semantics of Standard MIDI Files [MIDI]). Servers MUST use the "comex" value for the "tsmode" parameter in the reference session description.
クライアントはtsmodeパラメタ(すなわち、Standard MIDIファイル[MIDI]のタイムスタンプ意味論)の"comex"値によって合図されたタイムスタンプ意味論を解釈できなければなりません。 サーバは"tsmode"パラメタに参照セッション記述に"comex"値を使用しなければなりません。
Clients MUST be able to process an RTP MIDI stream whose packets
encode an arbitrary temporal duration ("media time"). Thus, in
practice, clients MUST implement a MIDI playout buffer. Clients MUST
NOT depend on the presence of rtp_ptime, rtp_maxtime, and guardtime
parameters in the session description in order to process packets,
but they SHOULD be able to use these parameters to improve packet
processing.
クライアントはパケットが任意の時の持続時間(「メディア時間」)をコード化するRTP MIDIの流れを処理できなければなりません。 したがって、実際には、クライアントはMIDI再生バッファを実行しなければなりません。 クライアントはパケットを処理するためにrtp_ptime、rtp_maxtime、およびセッション記述におけるguardtimeパラメタの存在を当てにしてはいけなくて、唯一のそれらはSHOULDです。パケット処理を改良するこれらのパラメタを使用できてください。
Servers SHOULD strive to send RTP MIDI streams in the same way media servers send conventional audio streams: a sequence of packets that either all code the same temporal duration (non-normative example: 50 ms packets) or that code one of an integral number of temporal durations (non-normative example: 50 ms, 100 ms, 250 ms, or 500 ms packets). Servers SHOULD encode information about the packetization method in the rtp_ptime and rtp_maxtime parameters in the session description.
サーバSHOULDは、メディアサーバが従来のオーディオストリームを送る同じように流れをRTP MIDIに送るように努力します: 同じ時の持続時間(非標準の例: 50のmsパケット)をコード化するパケットのすべて、系列か整数の時の持続時間(非標準の例: 50ms、100ms、250ms、または500のmsパケット)のそのコード1。 サーバSHOULDはrtp_ptimeのpacketization方法とセッション記述におけるrtp_maxtimeパラメタの情報をコード化します。
Clients MUST be able to examine the render and subrender parameter, to determine if a multimedia session uses a renderer it supports. Clients MUST be able to interpret the default "one" value of the "multimode" parameter, to identify supported renderers from a list of renderer descriptions. Clients MUST be able to interpret the musicport parameter, to the degree that it is relevant to the renderers it supports. Clients MUST be able to interpret the chanmask parameter.
そして、クライアントが調べることができなければならない、レンダリング、subrenderパラメタ、確認するために、マルチメディアセッションはそれが支持するレンダラーを使用します。 クライアントは、「マルチモード」パラメタのデフォルト「1つ」価値を解釈して、レンダラー記述のリストから支持されたレンダラーを特定できなければなりません。 クライアントはmusicportパラメタを解釈できなければなりません、それが支持するレンダラーに関連しているという度合いに。 クライアントはchanmaskパラメタを解釈できなければなりません。
Clients supporting renderers whose data object (as encoded by a parameter value for "inline") could exceed 300 octets in size MUST support the url and cid parameters and thus must implement the HTTP protocol in addition to RTSP.
データ・オブジェクト(「インライン」のためにパラメタ値によってコード化されるように)がサイズにおける300の八重奏を超えることができたレンダラーを支持しているクライアントは、urlとCidパラメタを支持しなければならなくて、その結果、RTSPに加えたHTTPプロトコルを実行しなければなりません。
Servers MUST specify complete rendering systems for RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this requirement (Section 6.1), as the rendering method for such streams is "not specified".
サーバはRTP MIDIの流れの完全な表現システムを指定しなければなりません。最小量のRTP MIDI自然な流れがこの必要条件(セクション6.1)を満たさないことに注意してください、そのような流れのための表現方法が「指定されない」とき。
Lazzaro & Wawrzynek Standards Track [Page 141] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[141ページ]。
At the time of this memo, the only way for servers to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and C.6.5). As a consequence, the only rendering systems that may be presently used are General MIDI [MIDI], DLS 2 [DLS2], or Structured Audio [MPEGSA]. Note that the maximum inline value for General MIDI is well under 300 octets (and thus clients need not support the "url" parameter), and that the maximum inline values for DLS 2 and Structured Audio may be much larger than 300 octets (and thus clients MUST support the url parameter).
このメモ時点で、サーバが完全な表現システムを指定する唯一の方法はモードrtp-ミディ(セクション6.2とC.6.5)でmpeg4-ジェネリックRTP MIDIの流れを指定することです。 結果として、現在使用されるかもしれない唯一の表現システムが、一般MIDI[MIDI]DLS2[DLS2]かStructured Audio[MPEGSA]です。 ジェネラルミディのための最大のインライン値がはるかに300未満の八重奏(その結果、クライアントは"url"パラメタを支持する必要はない)であり、DLS2とStructured Audioに、最大のインライン値が300の八重奏よりはるかに大きいかもしれないことに注意してください(その結果、クライアントはurlパラメタを支持しなければなりません)。
We anticipate that the owners of rendering systems (both standardized and proprietary) will register subrender parameters for their renderers. Once registration occurs, native RTP MIDI sessions may use render and subrender (Appendix C.6.2) to specify complete rendering systems for RTSP content-streaming multimedia sessions.
私たちは、表現システム(標準化されたものと同様に独占である)の所有者がそれらのレンダラーのためのsubrenderパラメタを示すと予期します。 登録がいったん起こると、ネイティブのRTP MIDIセッションが使用されるかもしれない、レンダリング、そして、RTSPの内容のストリーミングのマルチメディアセッションの完全な表現システムを指定するsubrender(付録C.6.2)。
Servers MUST NOT use the sdp_start value for the smf_info parameter in the reference session description, as this use would require that clients be able to parse and render Standard MIDI Files.
サーバはsmf_インフォメーションパラメタに参照セッション記述にsdp_スタート値を使用してはいけません、この使用が、クライアントが分析して、MIDIファイルをStandardにすることができるのを必要とするだろうというとき。
Clients MUST support mpeg4-generic mode rtp-midi General MIDI (GM) sessions, at a polyphony limited by the hardware capabilities of the client. This requirement provides a "lowest common denominator" rendering system for content providers to target. Note that this requirement does not force implementors of a non-GM renderer (such as DLS 2 or Structured Audio) to add a second rendering engine. Instead, a client may satisfy the requirement by including a set of voice patches that implement the GM instrument set, and using this emulation for mpeg4-generic GM sessions.
クライアントはmpeg4-ジェネリックモードrtp-ミディジェネラルミディ(GM)セッションを支持しなければなりません、クライアントのハードウェア能力によって制限された対位法で。 この要件はコンテンツプロバイダーが狙う「最小公分母」表現システムを提供します。 非GMレンダラー(DLS2かStructured Audioなどの)の作成者がこの要件によってやむを得ず2番目の表現エンジンを加えないことに注意してください。 代わりに、クライアントは、設定されて、mpeg4-ジェネリックGMセッションにこのエミュレーションを使用することでGM器具を実行する1セットの音声パッチを含んでいることによって、要件を満たすかもしれません。
It is RECOMMENDED that servers use General MIDI as the renderer for the reference session description, because clients are REQUIRED to support it. We do not require General MIDI as the reference renderer, because for normative applications it is an inappropriate choice. Servers using General MIDI as a "lowest common denominator" renderer SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
サーバが参照セッション記述にレンダラーとしてジェネラルミディを使用するのは、RECOMMENDEDです、クライアントがそれを支持するREQUIREDであるので。 それが標準のアプリケーションのための不適当な選択であるので私たちは参照レンダラーとしてジェネラルミディを必要としません。 「最小公分母」レンダラーとしてのMIDI司令官にSHOULDを使用するサーバが対位法で限られたクライアントへの声の優先権を伝えるUniversalレアル-時間SysEx MIPメッセージ[SPMIDI]を使用します。
C.7.2. MIDI Network Musical Performance Applications
C.7.2。 ミディネットワーク演奏アプリケーション
In Internet telephony and videoconferencing applications, parties interact over an IP network as they would face-to-face. Good user experiences require low end-to-end audio latency and tight audiovisual synchronization (for "lip-sync"). The Session Initiation Protocol (SIP, [RFC3261]) is used for session management.
インターネット電話とテレビ会議アプリケーションでは、パーティーは彼らが面と向かって相互作用するようにIPネットワークの上に相互作用します。 良いユーザー・エクスペリエンスは低端から端へのオーディオの潜在ときつい視聴覚の同期(「口パク」のための)を必要とします。 Session Initiationプロトコル(SIP、[RFC3261])はセッション管理に使用されます。
Lazzaro & Wawrzynek Standards Track [Page 142] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[142ページ]。
In this appendix section, we define interoperability guidelines for using RTP MIDI streams in interactive SIP applications. Our primary interest is supporting Network Musical Performances (NMP), where musicians in different locations interact over the network as if they were in the same room. See [NMP] for background information on NMP, and see [RFC4696] for a discussion of low-latency RTP MIDI implementation techniques for NMP.
この付録部分で、私たちは対話的なSIPアプリケーションにおけるRTP MIDIの流れを使用するための相互運用性ガイドラインを定義します。 私たちの主要な関心はNetwork Musicalパフォーマンス(NMP)を支持しています。そこでは、まるでそれらが同じ部屋にあるかのように別の場所のミュージシャンがネットワークの上に相互作用します。 NMPの基礎的な情報に関して[NMP]を見てください、そして、低遅延RTP MIDI実現のテクニックの議論に関してNMPに関して[RFC4696]を見てください。
Note that the goal of NMP applications is telepresence: the parties should hear audio that is close to what they would hear if they were in the same room. The interoperability guidelines in this appendix address RTP MIDI applications of this nature, not applications such as the transmission of raw MIDI command streams for use in a professional environment (recording studio, performance stage, etc.).
NMPアプリケーションの目標がテレプレゼンスであることに注意してください: パーティーは彼らが同じ部屋にいたなら彼らが聞くことの近くにあるオーディオを聞くべきです。 この付録の相互運用性ガイドラインはプロの環境(レコーディングスタジオ、性能ステージなど)における使用のための未精製のMIDIコマンドの流れのトランスミッションなどの応用ではなく、この種のRTP MIDIアプリケーションを記述します。
We focus on session management for two-party unicast sessions that specify a renderer for RTP MIDI streams. Within this limited scope, the guidelines defined here are sufficient to let applications interoperate. We define the REQUIRED capabilities of RTP MIDI senders and receivers in NMP sessions and define how session descriptions exchanged are used to set up network musical performance sessions.
私たちはRTP MIDIの流れにレンダラーを指定する2パーティーのユニキャストセッションのためのセッション管理に焦点を合わせます。この限られた範囲の中では、ここで定義されたガイドラインは、アプリケーションが共同利用するために十分です。 私たちは、NMPセッションのときにRTP MIDI送付者と受信機のREQUIRED能力を定義して、交換されたセッション記述がネットワーク演奏セッションをセットアップするのにどう使用されるかを定義します。
SIP lets parties negotiate details of the session, using the Offer/Answer protocol [RFC3264]. However, RTP MIDI has so many parameters that "blind" negotiations between two parties using different applications might not yield a common session configuration.
Offer/答えプロトコル[RFC3264]を使用して、SIPはパーティーにセッションの詳細を交渉させることができます。 しかしながら、RTP MIDIには、異なったアプリケーションを使用している2回のパーティーの間の「盲目」の交渉が一般的なセッション構成をもたらすことができないようにとても多くのパラメタがあります。
Thus, we now define a set of capabilities that NMP parties MUST support. Session description offers whose options lie outside the envelope of REQUIRED party behavior risk negotiation failure. We also define session description idioms that the RTP MIDI part of an offer MUST follow, in order to structure the offer for simpler analysis.
したがって、私たちは現在、NMPパーティーが支持しなければならない1セットの能力を定義します。 REQUIREDパーティーの振舞いの封筒の外にオプションがあるセッション記述申し出は交渉失敗の危険を冒します。 また、私たちは申し出のRTP MIDI部分が従わなければならないセッション記述熟語を定義します、より簡単な分析のための申し出を構造化するために。
We use the term "offerer" for the party making a SIP offer, and "answerer" for the party answering the offer. Finally, we note that unless it is qualified by the adjective "sender" or "receiver", a statement that a party MUST support X implies that it MUST support X for both sending and receiving.
私たちは、SIP申し出をしているパーティーに「申出人」という用語を使用して、申し出に答えるパーティーに"answerer"を使用します。 最終的に、私たちは、それが形容詞的「送付者」か「受信機」によって資格がない場合、パーティーがXを支持しなければならないという声明が、発信と受信の両方のためのXを支持しなければならないのを含意することに注意します。
If an offerer wishes to define a "sendrecv" RTP MIDI stream, it may use a true sendrecv session or the "virtual sendrecv" construction described in the preamble to Appendix C and in Appendix C.5. A true sendrecv session indicates that the offerer wishes to participate in a session where both parties use identically configured renderers. A virtual sendrecv session indicates that the offerer is willing to
申出人が"sendrecv"RTP MIDIの流れを定義したいなら、それはAppendix Cへの序文とAppendix C.5で説明された本当のsendrecvセッションか「仮想のsendrecv」工事を使用するかもしれません。 本当のsendrecvセッションは、申出人が双方が同様に構成されたレンダラーを使用するセッションのときに参加したがっているのを示します。 申出人が望んでいるセッションが示す仮想のsendrecv
Lazzaro & Wawrzynek Standards Track [Page 143] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[143ページ]。
participate in a session where the two parties may be using different renderer configurations. Thus, parties MUST be prepared to see both real and virtual sendrecv sessions in an offer.
2回のパーティーが異なったレンダラー構成を使用しているかもしれないセッションのときに、参加してください。 したがって、パーティーは本当のものと申し出における同様に仮想のsendrecvセッションを見る用意ができていなければなりません。
Parties MUST support unicast UDP transport of RTP MIDI streams. These streams MUST use the recovery journal with the closed-loop or anchor sending policies. These streams MUST use the stream subsetting and chapter inclusion parameters to declare the types of MIDI commands that will be sent on the stream (for sendonly streams) or will be processed (for recvonly streams), including the size limits on System Exclusive commands. Support of enhanced Chapter C encoding is OPTIONAL.
党はRTP MIDIの流れのユニキャストUDP輸送を支持しなければなりません。これらの流れは閉ループするかアンカー送付方針がある回復ジャーナルを使用しなければなりません。 これらの流れは流れ(sendonlyの流れのための)に送るか、または処理する(recvonlyの流れのために)MIDIコマンドのタイプを宣言するのに流れの副設定と章包含パラメタを使用しなければなりません、System Exclusiveコマンドにおけるサイズ限界を含んでいて。 高められた章C コード化のサポートはOPTIONALです。
Note that both TCP and multicast UDP support are OPTIONAL. We make TCP OPTIONAL because we expect NMP renderers to rely on data objects (signalled by "rinit" and associated parameters) for initialization at the start of the session, and only to use System Exclusive commands for interactive control during the session. These interactive commands are small enough to be protected via the recovery journal mechanism of RTP MIDI UDP streams.
TCPとマルチキャストUDPサポートの両方がOPTIONALであることに注意してください。 NMPレンダラーがセッションの始めでの初期化のために、データ・オブジェクト("rinit"と関連パラメタで、合図される)を当てにして、対話的なコントロールにセッションの間、単にSystem Exclusiveコマンドを使用すると予想するので、私たちはTCP OPTIONALを作ります。 これらの対話的なコマンドは小さく、RTP MIDI UDPの回復ジャーナルメカニズムで保護できるくらい流れるということです。
We now discuss timestamps, packet timing, and packet sending algorithms.
私たちは現在、タイムスタンプ、パケットタイミング、およびパケット送付アルゴリズムについて議論します。
Recall that the tsmode parameter controls the semantics of command timestamps in the MIDI list of RTP packets.
tsmodeパラメタがRTPパケットのMIDIリストのコマンドタイムスタンプの意味論を制御すると思い出してください。
Parties MUST support clock rates of 44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz. Parties MUST support streams using the "comex", "async", and "buffer" tsmode values. Recvonly offers MUST offer the default "comex".
党は44.1kHz、48kHz、88.2kHz、および96kHzのクロックレートを支持しなければなりません。 "comex"、"async"、および「バッファ」tsmode値を使用して、党は流れを支持しなければなりません。 Recvonly申し出はデフォルト"comex"を提供しなければなりません。
Parties MUST support a wide range of packet temporal durations: from rtp_ptime and rtp_maxptime values of 0, to rtp_ptime and rtp_maxptime values that code 100 ms. Thus, receivers MUST be able to implement a playout buffer.
党はさまざまなパケットの時の持続時間を支持しなければなりません: 0のrtp_ptimeとrtp_maxptime値からrtp_ptimeとrtp_まで、maxptimeはそのコード100原稿Thusを評価して、受信機は再生バッファを実行できなければなりません。
Offers and answers MUST present rtp_ptime, rtp_maxptime, and guardtime values that support the latency that users would expect in the application, subject to bandwidth constraints. As senders MUST abide by values set for these parameters in a session description, a receiver SHOULD use these values to size its playout buffer to produce the lowest reliable latency for a session. Implementers should refer to [RFC4696] for information on packet sending algorithms for latency-sensitive applications. Parties MUST be able to implement the semantics of the guardtime parameter, for times from 5 ms to 5000 ms.
申し出と答えはユーザがアプリケーションで帯域幅規制を条件として予想する潜在を支持する値をrtp_ptime、rtp_maxptime、およびguardtimeに提示しなければなりません。 送付者がとどまらなければならないとき、セッション記述、受信機のこれらのパラメタに設定された値で、SHOULDはこれらの値を再生がセッションのために最も低い信頼できる潜在を生産するためにバッファリングするサイズまで使用します。 Implementersは潜在敏感なアプリケーションのためのパケット送付アルゴリズムの情報について[RFC4696]について言及するはずです。 党は5msから5000年の原稿まで何倍もguardtimeパラメタの意味論を実行できなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 144] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[144ページ]。
We now discuss the use of the render parameter.
私たちが現在使用について議論する、パラメタを表してください。
Sessions MUST specify complete rendering systems for all RTP MIDI streams. Note that a minimal RTP MIDI native stream does not meet this requirement (Section 6.1), as the rendering method for such streams is "not specified".
セッションはすべてのRTP MIDIの流れの完全な表現システムを指定しなければなりません。最小量のRTP MIDI自然な流れがこの必要条件(セクション6.1)を満たさないことに注意してください、そのような流れのための表現方法が「指定されない」とき。
At the time this writing, the only way for parties to specify a complete rendering system is to specify an mpeg4-generic RTP MIDI stream in mode rtp-midi (Section 6.2 and C.6.5). We anticipate that the owners of rendering systems (both standardized and proprietary) will register subrender values for their renderers. Once IANA registration occurs, native RTP MIDI sessions may use render and subrender (Appendix C.6.2) to specify complete rendering systems for SIP network musical performance multimedia sessions.
時の、この書くこと、パーティーが完全な表現システムを指定する唯一の方法はモードrtp-ミディ(セクション6.2とC.6.5)でmpeg4-ジェネリックRTP MIDIの流れを指定することです。 私たちは、表現システム(標準化されたものと同様に独占である)の所有者がそれらのレンダラーのためにsubrender値を示すと予期します。 IANA登録がいったん起こると、ネイティブのRTP MIDIセッションが使用されるかもしれない、レンダリング、そして、SIPネットワーク演奏マルチメディアセッションの完全な表現システムを指定するsubrender(付録C.6.2)。
All parties MUST support General MIDI (GM) sessions, at a polyphony limited by the hardware capabilities of the party. This requirement provides a "lowest common denominator" rendering system, without which practical interoperability will be quite difficult. When using GM, parties SHOULD use Universal Real-Time SysEx MIP message [SPMIDI] to communicate the priority of voices to polyphony-limited clients.
すべてのパーティーがパーティーのハードウェア能力によって制限された対位法でジェネラルミディ(GM)セッションを支持しなければなりません。 この要件は「最小公分母」表現システムを提供します。(実用的な相互運用性はそれなしでかなり難しくなるでしょう)。 GMを使用するとき、パーティーSHOULDは対位法で限られたクライアントへの声の優先権を伝えるUniversalレアル-時間SysEx MIPメッセージ[SPMIDI]を使用します。
Note that this requirement does not force implementors of a non-GM renderer (for mpeg4-generic sessions, DLS 2, or Structured Audio) to add a second rendering engine. Instead, a client may satisfy the requirement by including a set of voice patches that implement the GM instrument set, and using this emulation for mpeg4-generic GM sessions. We require GM support so that an offerer that wishes to maximize interoperability may do so by offering GM if its preferred renderer is not accepted by the answerer.
非GMレンダラー(mpeg4-ジェネリックセッション、DLS2、またはStructured Audioのための)の作成者がこの要件によってやむを得ず2番目の表現エンジンを加えないことに注意してください。 代わりに、クライアントは、設定されて、mpeg4-ジェネリックGMセッションにこのエミュレーションを使用することでGM器具を実行する1セットの音声パッチを含んでいることによって、要件を満たすかもしれません。 私たちは、相互運用性を最大にしたがっている申出人が都合のよいレンダラーがanswererによって受け入れられないならGMを提供することによってそうすることができるように、GMサポートを必要とします。
Offerers MUST NOT present several renderers as options in a session description by listing several payload types on a media line, as Section 2.1 uses this construct to let a party send several RTP MIDI streams in the same RTP session.
申出人はセッション記述におけるオプションとしていくつかのペイロードタイプをメディア線に記載することによって、いくつかのレンダラーを提示してはいけません、パーティーに同じRTPセッションにおけるいくつかのRTP MIDIの流れを送らせるのにセクション2.1がこの構造物を使用するとき。
Instead, an offerer wishing to present rendering options SHOULD offer a single payload type that offers several renderers. In this construct, the parameter list codes a list of render parameters (each followed by its support parameters). As discussed in Appendix C.6.1, the order of renderers in the list declares the offerer's preference. The "unknown" and "null" values MUST NOT appear in the offer. The answer MUST set all render values except the desired renderer to "null". Thus, "unknown" MUST NOT appear in the answer.
代わりに、SHOULDが単独のペイロードタイプを提供する表現オプションにそれを提示したがっている申出人はいくつかのレンダラーを提供します。 この構造物に、リストがリストをコード化するパラメタはパラメタを表します(それぞれがサポートパラメタで続きました)。 Appendix C.6.1で議論するように、リストにおける、レンダラーの注文は申出人の好みを宣言します。 「未知」の、そして、「ヌル」の値は申し出に現れてはいけません。 答えはすべてが値をするセット「ヌル」への必要なレンダラーがそうしなければなりません。 したがって、「未知」は答えに現れてはいけません。
Lazzaro & Wawrzynek Standards Track [Page 145] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[145ページ]。
We use SHOULD instead of MUST in the first sentence in the paragraph above, because this technique does not work in all situations (example: an offerer wishes to offer both mpeg4-generic renderers and native RTP MIDI renderers as options). In this case, the offerer MUST present a series of session descriptions, each offering a single renderer, until the answerer accepts a session description.
の代わりにする、私たちがSHOULDを使用する、このテクニックがすべての状況で利かないので(例: 申出人はオプションとしてmpeg4-ジェネリックレンダラーとネイティブのRTP MIDIレンダラーの両方を提供したがっています)、上のパラグラフにおける最初の文でそうしなければなりません。 この場合、申出人は一連のセッション記述を提示しなければなりません、それぞれ単一のレンダラーを提供して、answererがセッション記述を受け入れるまで。
Parties MUST support the musicport, chanmask, subrender, rinit, and inline parameters. Parties supporting renderers whose data object (as encoded by a parameter value for "inline") could exceed 300 octets in size MUST support the url and cid parameters and thus must implement HTTP protocol. Note that in mpeg4-generic, General MIDI data objects cannot exceed 300 octets, but DLS 2 and Structured Audio data objects may. Support for the other rendering parameters (smf_cif, smf_info, smf_inline, smf_url) is OPTIONAL.
党はmusicport、chanmask、subrender、rinit、およびインラインパラメタを支持しなければなりません。 データ・オブジェクト(「インライン」のためにパラメタ値によってコード化されるように)がサイズにおける300の八重奏を超えることができたレンダラーを支持する党は、urlとCidパラメタを支持しなければならなくて、その結果、HTTPプロトコルを実行しなければなりません。 mpeg4一般的で、一般のMIDIデータ・オブジェクトのそれは300の八重奏を超えることができるのではなく、データ・オブジェクトがそうするDLS2とStructured Audioを超えていることに注意してください。 他の表現パラメタ(smf_cif、smf_インフォメーション、smf_インライン、smf_url)のサポートはOPTIONALです。
Thus far in this document, our discussion has assumed that the only MIDI flows that drive a renderer are the network flows described in the session description. In NMP applications, this assumption would require two rendering engines: one for local use by a party, a second for the remote party.
これまでのところ、このドキュメントでは、私たちの議論は、レンダラーを運転する唯一のMIDI流れがセッション記述で説明されたネットワーク流れであると仮定しました。 NMPアプリケーションでは、この仮定は2台の表現エンジンを必要とするでしょう: 1秒のパーティーによるリモートパーティーの地方の使用のためにもの。
In practice, applications may wish to have both parties share a single rendering engine. In this case, the session description MUST use a virtual sendrecv session and MUST use the stream subsetting and chapter inclusion parameters to allocate which MIDI channels are intended for use by a party. If two parties are sharing a MIDI channels, the application MUST ensure that appropriate MIDI merging occurs at the input to the renderer.
実際には、双方はアプリケーションで単一の表現エンジンを共有したがっているかもしれません。 この場合、セッション記述は、仮想のsendrecvセッションを使用しなければならなくて、流れの副設定を使用しなければなりません、そして、割り当てるMIDIが向ける章包含パラメタは使用のためにパーティーによって意図されます。 2回のパーティーが共有しているなら、MIDIは精神を集中して、アプリケーションは、適切なMIDI合併が入力のときにレンダラーに起こるのを確実にしなければなりません。
We now discuss the use of (non-MIDI) audio streams in the session.
私たちは現在、セッションにおける(非MIDI)オーディオストリームの使用について議論します。
Audio streams may be used for two purposes: as a "talkback" channel for parties to converse, or as a way to conduct a performance that includes MIDI and audio channels. In the latter case, offers MUST use sample rates and the packet temporal durations for the audio and MIDI streams that support low-latency synchronized rendering.
オーディオストリームは2つの目的に使用されるかもしれません: "talkback"として、話すパーティー、またはMIDIを含んでいる性能を行う方法とオーディオがチャネルを開設するように、精神を集中してください。 後者の場合では、申し出はオーディオに見本郵送料率とパケットの時の持続時間を使用しなければなりません、そして、低遅延を支持するMIDIの流れが表現を同時にさせました。
Lazzaro & Wawrzynek Standards Track [Page 146] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[146ページ]。
We now show an example of an offer/answer exchange in a network musical performance application (next page). Below, we show an offer that complies with the interoperability text in this appendix section.
私たちは現在、ネットワーク演奏アプリケーション(次のページ)における申し出/答え交換に関する例を示しています。 以下では、私たちがこの付録部分の相互運用性テキストに従う申し出を示しています。
v=0 o=first 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 a=group:FID 1 2 c=IN IP4 192.0.2.94 m=audio 16112 RTP/AVP 96 a=recvonly a=mid:1 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; ch_default=2M0.1.2; cm_default=X0-16; rtp_ptime=0; rtp_maxptime=0; guardtime=44100; musicport=1; render=synthetic; rinit="audio/asc"; inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" m=audio 16114 RTP/AVP 96 a=sendonly a=mid:2 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; ch_default=1M0.1.2; cm_default=X0-16; rtp_ptime=0; rtp_maxptime=0; guardtime=44100; musicport=1; render=synthetic; rinit="audio/asc"; inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
v=0oが=グループ: FIDあたり最初に、IN IP4 2520644554 2838152170の最初の.example.net s=例t=0 0と等しい、1 2、c、=IN IP4、192.0、.2、.94m、=オーディオの16112RTP/AVP96a=recvonly aが等しい、中間、: 1 a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABCFGHJKMNPQTVWXYZ。 _が使用したcmは2NPTWと等しいです。 cm_中古の=2C0.1.7.10.11.64.121、.123。 2M0.1の.2cmの_が使用したcm=_は=X0-16を使用しました。 ch_はABCDEFGHJKMNPQTVWXYZと決して等しくはありません。 ch_デフォルトは2NPTWと等しいです。 ch_デフォルト=2C0.1.7.10.11.64.121.123。 ch_デフォルトは2M0.1.2と等しいです。 cm_デフォルトはX0-16と等しいです。 rtp_ptime=0。 rtp_maxptime=0。 guardtime=44100。 musicport=1。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 インラインは"egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"m=オーディオの16114RTP/AVP96a=sendonly aと=中間であることで等しいです: 2a=rtpmap: 96mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABCFGHJKMNPQTVWXYZ。 _が使用したcmは1NPTWと等しいです。 cm_中古の=1C0.1.7.10.11.64.121、.123。 1M0.1の.2cmの_が使用したcm=_は=X0-16を使用しました。 ch_はABCDEFGHJKMNPQTVWXYZと決して等しくはありません。 ch_デフォルトは1NPTWと等しいです。 ch_デフォルト=1C0.1.7.10.11.64.121.123。 ch_デフォルトは1M0.1.2と等しいです。 cm_デフォルトはX0-16と等しいです。 rtp_ptime=0。 rtp_maxptime=0。 guardtime=44100。 musicport=1。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 インラインは"egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"と等しいです。
(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; it comprises a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp線を包装してあります; それはSDPの単線を包括します。)
The owner line (o=) identifies the session owner as "first".
所有者線(o=)は、セッション所有者が「1番目」であると認識します。
The session description defines two MIDI streams: a recvonly stream on which "first" receives a performance, and a sendonly stream that "first" uses to send a performance. The recvonly port number encodes the ports on which "first" wishes to receive RTP (16112) and RTCP (16113) media at IP4 address 192.0.2.94. The sendonly port number
セッション記述は2つのMIDIの流れを定義します: recvonlyの流れはどの「1番目」でそれが「最初に」性能を送るのに使用する性能、およびsendonlyの流れを受け取るか。 recvonlyポートナンバーがアドレスがIP4に「最初に」とRTP(16112)とRTCP(16113)メディアを受け取りたがっているポートをコード化する、192.0、.2、.94 sendonlyポートナンバー
Lazzaro & Wawrzynek Standards Track [Page 147] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[147ページ]。
encodes the port on which "first" wishes to receive RTCP for the stream (16115).
RTCPが「最初に」と流れ(16115)を受信したがっているポートをコード化します。
The musicport parameters code that the two streams share and identity relationship and thus form a virtual sendrecv stream.
2つの流れが共有するmusicportパラメタコード、アイデンティティ関係、およびその結果仮想のsendrecvが流すフォーム。
Both streams are mpeg4-generic RTP MIDI streams that specify a General MIDI renderer. The stream subsetting parameters code that the recvonly stream uses MIDI channel 1 exclusively for voice commands, and that the sendonly stream uses MIDI channel 2 exclusively for voice commands. This mapping permits the application software to share a single renderer for local and remote performers.
両方の流れはジェネラルミディレンダラーを指定するmpeg4-ジェネリックRTP MIDIの流れです。 recvonlyが流すパラメタコードを副設定する流れは排他的に音声命令にMIDIチャンネル1を使用します、そして、sendonlyの流れが排他的に声にMIDIチャンネル2を使用するのは命令します。 このマッピングは、アプリケーション・ソフトが地方の、そして、リモートなパフォーマーのために単一のレンダラーを共有することを許可します。
Lazzaro & Wawrzynek Standards Track [Page 148] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[148ページ]。
We now show the answer to the offer.
私たちは現在、申し出の答えを示しています。
v=0 o=second 2520644554 2838152170 IN IP4 second.example.net s=Example t=0 0 a=group:FID 1 2 c=IN IP4 192.0.2.105 m=audio 5004 RTP/AVP 96 a=sendonly a=mid:1 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=2NPTW; cm_used=2C0.1.7.10.11.64.121.123; cm_used=2M0.1.2 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; ch_default=2NPTW; ch_default=2C0.1.7.10.11.64.121.123; ch_default=2M0.1.2; cm_default=X0-16; rtp_ptime=0; rtp_maxptime=882; guardtime=44100; musicport=1; render=synthetic; rinit="audio/asc"; inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA" m=audio 5006 RTP/AVP 96 a=recvonly a=mid:2 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABCFGHJKMNPQTVWXYZ; cm_used=1NPTW; cm_used=1C0.1.7.10.11.64.121.123; cm_used=1M0.1.2 cm_used=X0-16; ch_never=ABCDEFGHJKMNPQTVWXYZ; ch_default=1NPTW; ch_default=1C0.1.7.10.11.64.121.123; ch_default=1M0.1.2; cm_default=X0-16; rtp_ptime=0; rtp_maxptime=0; guardtime=88200; musicport=1; render=synthetic; rinit="audio/asc"; inline="egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"
2番目の2520644554 2838152170のIN IP4 2番目のv=0o=.example.net s=例tが=グループ: FIDあたり0 0と等しい、1 2、c、=IN IP4、192.0、.2、.105m、=オーディオの5004RTP/AVP96a=sendonly aが等しい、中間、: 1 a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABCFGHJKMNPQTVWXYZ。 _が使用したcmは2NPTWと等しいです。 cm_中古の=2C0.1.7.10.11.64.121、.123。 2M0.1の.2cmの_が使用したcm=_は=X0-16を使用しました。 ch_はABCDEFGHJKMNPQTVWXYZと決して等しくはありません。 ch_デフォルトは2NPTWと等しいです。 ch_デフォルト=2C0.1.7.10.11.64.121.123。 ch_デフォルトは2M0.1.2と等しいです。 cm_デフォルトはX0-16と等しいです。 rtp_ptime=0。 rtp_maxptime=882。 guardtime=44100。 musicport=1。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 インラインは"egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"m=オーディオの5006RTP/AVP96a=recvonly aと=中間であることで等しいです: 2a=rtpmap: 96mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABCFGHJKMNPQTVWXYZ。 _が使用したcmは1NPTWと等しいです。 cm_中古の=1C0.1.7.10.11.64.121、.123。 1M0.1の.2cmの_が使用したcm=_は=X0-16を使用しました。 ch_はABCDEFGHJKMNPQTVWXYZと決して等しくはありません。 ch_デフォルトは1NPTWと等しいです。 ch_デフォルト=1C0.1.7.10.11.64.121.123。 ch_デフォルトは1M0.1.2と等しいです。 cm_デフォルトはX0-16と等しいです。 rtp_ptime=0。 rtp_maxptime=0。 guardtime=88200。 musicport=1。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 インラインは"egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA"と等しいです。
(The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp線を包装してあります; それらはSDPの単線を包括します。)
The owner line (o=) identifies the session owner as "second".
所有者線(o=)は、セッション所有者が「2番目」であると認識します。
The port numbers for both media streams are non-zero; thus, "second" has accepted the session description. The stream marked "sendonly" in the offer is marked "recvonly" in the answer, and vice versa, coding the different view of the session held by "session". The IP4 number (192.0.2.105) and the RTP (5004 and 5006) and RTCP (5005 and 5007) have been changed by "second" to match its transport wishes.
両方のメディアの流れのためのポートナンバーは非ゼロです。 したがって、「2番目」はセッション記述を受け入れました。 申し出における"sendonly"であるとマークされた流れは答えにおける"recvonly"であるとマークされます、逆もまた同様に、「セッション」によって行われるセッションの異なった視点をコード化して。 IP4番号、(192.0 .2 輸送願望を合わせるために「2番目」までに.105、)RTP(5004と5006)、およびRTCP(5005と5007)を変えました。
Lazzaro & Wawrzynek Standards Track [Page 149] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[149ページ]。
In addition, "second" has made several parameter changes: rtp_maxptime for the sendonly stream has been changed to code 2 ms (441 in clock units), and the guardtime for the recvonly stream has been doubled. As these parameter modifications request capabilities that are REQUIRED to be implemented by interoperable parties, "second" can make these changes with confidence that "first" can abide by them.
さらに、「2番目」は数回のパラメータ変動を作りました: 2ms(クロックユニットの441)をコード化するためにsendonlyの流れのためのrtp_maxptimeを変えました、そして、recvonlyの流れのためのguardtimeを倍にしました。 これらのパラメタ変更が、共同利用できるパーティーによって実行されるようREQUIREDである能力に要求するとき、「2番目」は「1番目」がそれらを守ることができるという自信をもってこれらの変更を行うことができます。
D. Parameter Syntax Definitions
D。 パラメタ構文定義
In this appendix, we define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form (ABNF, [RFC4234]). When using these parameters with SDP, all parameters MUST appear on a single fmtp attribute line of an RTP MIDI media description. For mpeg4-generic RTP MIDI streams, this line MUST also include any mpeg4-generic parameters (usage described in Section 6.2). An fmtp attribute line may be defined (after [RFC3640]) as:
この付録では、私たちはRTP MIDIメディア型引数のためにAugmented BN記法(ABNF、[RFC4234])で構文を定義します。 SDPがあるこれらのパラメタを使用するとき、すべてのパラメタがRTP MIDIメディア記述のただ一つのfmtp属性線の上に現れなければなりません。 また、mpeg4-ジェネリックRTP MIDIの流れのために、この線はどんなmpeg4-ジェネリックパラメタ(セクション6.2で説明された用法)も含まなければなりません。 fmtp属性線は以下と定義されるかもしれません([RFC3640]の後に)。
; ; SDP fmtp line definition ;
; ; SDP fmtpは定義を裏打ちします。
fmtp = "a=fmtp:" token SP param-assign 0*(";" SP param-assign) CRLF
fmtpが等しい、「a=fmtp:」 象徴SP param-案配0*、(「」、;、SP param-案配) CRLF
where <token> codes the RTP payload type. Note that white space MUST NOT appear between the "a=fmtp:" and the RTP payload type.
<象徴>がRTPペイロードをコード化するところでは、タイプしてください。 その余白が現れてはいけないことに注意してください、「a=fmtp:」 そして、RTPペイロードタイプ。
We now define the syntax of the parameters defined in Appendix C. The definition takes the form of the incremental assembly of the <param-assign> token. See [RFC3640] for the syntax of the mpeg4-generic parameters discussed in Section 6.2.
私たちは現在、Appendix C.で定義されたパラメタの構文を定義します。定義は<のparam案配している>象徴の増加のアセンブリの形を取ります。 セクション6.2で議論したmpeg4-ジェネリックパラメタの構文に関して[RFC3640]を見てください。
; ; ; top-level definition for all parameters ; ;
; ; ; すべてのパラメタのためのトップレベル定義。 ;
; ; Parameters defined in Appendix C.1
; ; Appendix C.1で定義されたパラメタ
param-assign = ("cm_unused=" (([channel-list] command-type
[f-list]) / sysex-data))
=をparam割り当ててください。(「cm、_」 [チャンネルリスト]がコマンドでタイプする未使用の=[f-リスト) /sysexデータ)
param-assign =/ ("cm_used=" (([channel-list] command-type
[f-list]) / sysex-data))
=/をparam割り当ててください。(「cm_は=を使用した」(sysex[チャンネルリスト]コマンドタイプ[f-リスト)/データ))
Lazzaro & Wawrzynek Standards Track [Page 150] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[150ページ]。
; ; Parameters defined in Appendix C.2
; ; Appendix C.2で定義されたパラメタ
param-assign =/ ("j_sec=" ("none" / "recj" / *ietf-extension))
=/をparam割り当ててください。(「j_秒=」(「なにも」/"recj"/*ietf-拡大))
param-assign =/ ("j_update=" ("anchor" / "closed-loop" /
"open-loop" / *ietf-extension))
=/をparam割り当ててください。(「j_アップデート=」(「アンカー」/「閉ループする」/「転々流通」/*ietf-拡大))
param-assign =/ ("ch_default=" (([channel-list] chapter-list
[f-list]) / sysex-data))
=/をparam割り当ててください。(sysex「ch_デフォルト=」[チャンネルリスト]章リスト[f-リスト)/データ)
param-assign =/ ("ch_never=" (([channel-list] chapter-list
[f-list]) / sysex-data))
=/をparam割り当ててください。(「=を決してchしない」(sysex[チャンネルリスト]章リスト[f-リスト)/データ))
param-assign =/ ("ch_anchor=" (([channel-list] chapter-list
[f-list]) / sysex-data))
=/をparam割り当ててください。(sysex「ch_アンカー=」[チャンネルリスト]章リスト[f-リスト)/データ)
; ; Parameters defined in Appendix C.3
; ; Appendix C.3で定義されたパラメタ
param-assign =/ ("tsmode=" ("comex" / "async" / "buffer"))
=/をparam割り当ててください。(「tsmode=」("comex"/"async"/「バッファ」))
param-assign =/ ("linerate=" nonzero-four-octet)
=/をparam割り当ててください。(「linerate=」非零four八重奏)
param-assign =/ ("octpos=" ("first" / "last"))
=/をparam割り当ててください。(「octpos=」(「1番目」/「最終」))
param-assign =/ ("mperiod=" nonzero-four-octet)
=/をparam割り当ててください。(「mperiod=」非零four八重奏)
; ; Parameter defined in Appendix C.4
; ; Appendix C.4で定義されたパラメタ
param-assign =/ ("guardtime=" nonzero-four-octet)
=/をparam割り当ててください。(「guardtime=」非零four八重奏)
param-assign =/ ("rtp_ptime=" four-octet)
=/をparam割り当ててください。(「rtp_ptime=」の4八重奏)
param-assign =/ ("rtp_maxptime=" four-octet)
=/をparam割り当ててください。(「rtp_maxptime=」の4八重奏)
; ; Parameters defined in Appendix C.5
; ; Appendix C.5で定義されたパラメタ
param-assign =/ ("musicport=" four-octet)
=/をparam割り当ててください。(「musicport=」の4八重奏)
Lazzaro & Wawrzynek Standards Track [Page 151] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[151ページ]。
; ; Parameters defined in Appendix C.6
; ; Appendix C.6で定義されたパラメタ
param-assign =/ ("chanmask=" ( 1*( 16( "0" / "1" ) )))
=/をparam割り当ててください。(「chanmaskは等しい」、(1*、(16、(「0インチ/、「1インチ)」
param-assign =/ ("cid=" double-quote cid-block
double-quote)
=/をparam割り当ててください。(「Cid=」二重引用文のCidブロックの二重引用文)
param-assign =/ ("inline=" double-quote base-64-block
double-quote)
=/をparam割り当ててください。(「インライン=」二重引用文の64が妨げるベースの二重引用文)
param-assign =/ ("multimode=" ("all" / "one"))
=/をparam割り当ててください。(「マルチモード=」(「すべて」/「1つ」))
param-assign =/ ("render=" ("synthetic" / "api" / "null" /
"unknown" / *extension))
=/をparam割り当ててください。(「=をレンダリングする」(「合成」/"api"/「ヌル」/「未知」/*拡大))
param-assign =/ ("rinit=" mime-type "/" mime-subtype)
=/をparam割り当ててください。「(」 「rinitは」 パントマイムタイプと等しく」/パントマイム-「副-タイプ」)
param-assign =/ ("smf_cid=" double-quote cid-block
double-quote)
=/をparam割り当ててください。(「smf_Cid=」二重引用文のCidブロックの二重引用文)
param-assign =/ ("smf_info=" ("ignore" / "identity" /
"sdp_start" / *extension))
=/をparam割り当ててください。(「smf_インフォメーション=」(「無視」/「アイデンティティ」/「sdp_始め」/*拡大))
param-assign =/ ("smf_inline=" double-quote base-64-block
double-quote)
=/をparam割り当ててください。(「smf_インライン=」二重引用文の64が妨げるベースの二重引用文)
param-assign =/ ("smf_url=" double-quote uri-element
double-quote)
=/をparam割り当ててください。(「smf_url=」二重引用文のuri-要素の二重引用文)
param-assign =/ ("subrender=" ("default" / *extension))
=/をparam割り当ててください。(「subrender=」(「デフォルト」/*拡大))
param-assign =/ ("url=" double-quote uri-element
double-quote)
=/をparam割り当ててください。(「url=」二重引用文のuri-要素の二重引用文)
; ; list definitions for the cm_ command-type ;
; ; cm_のためにタイプを命令して定義を記載してください。
command-type = command-part1 command-part2 command-part3
コマンドタイプはコマンド-part1コマンド-part2コマンド-part3と等しいです。
command-part1 = (*1"A") (*1"B") (*1"C") (*1"F") (*1"G") (*1"H")
「コマンド-part1が等しい、(*1"A、」、)、(*1"B、」、)、(*1"C、」、)、(*1"F、」、)、(*1"G、」、)「(*1"H、」、)
command-part2 = (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")
「コマンド-part2が等しい、(*1"J、」、)、(*1"K、」、)、(*1"M、」、)、(*1"N、」、)、(*1"P、」、)「(*1"Q、」、)
command-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")
「コマンド-part3が等しい、(*1"T、」、)、(*1"V、」、)、(*1"W、」、)、(*1"X、」、)、(*1"Y、」、)「(*1"Z、」、)
Lazzaro & Wawrzynek Standards Track [Page 152] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[152ページ]。
; ; list definitions for the ch_ chapter-list ;
; ; ch_章リストのための定義を記載してください。
chapter-list = ch-part1 ch-part2 ch-part3
章リスト=ch-part1 ch-part2 ch-part3
ch-part1 = (*1"A") (*1"B") (*1"C") (*1"D") (*1"E") (*1"F") (*1"G")
「ch-part1が等しい、(*1"A、」、)、(*1"B、」、)、(*1"C、」、)、(*1"D、」、)、(*1"E、」、)、(*1"F、」、)「(*1"G、」、)
ch-part2 = (*1"H") (*1"J") (*1"K") (*1"M") (*1"N") (*1"P") (*1"Q")
「ch-part2が等しい、(*1"H、」、)、(*1"J、」、)、(*1"K、」、)、(*1"M、」、)、(*1"N、」、)、(*1"P、」、)「(*1"Q、」、)
ch-part3 = (*1"T") (*1"V") (*1"W") (*1"X") (*1"Y") (*1"Z")
「ch-part3が等しい、(*1"T、」、)、(*1"V、」、)、(*1"W、」、)、(*1"X、」、)、(*1"Y、」、)「(*1"Z、」、)
; ; list definitions for the ch_ channel-list ;
; ; ch_チャンネルリストのための定義を記載してください。
channel-list = midi-chan-element *("." midi-chan-element)
チャンネルリスト=ミディchan要素*(「. 」 ミディchan要素、)
midi-chan-element = midi-chan / midi-chan-range
ミディchanミディchan要素=ミディ-chan/範囲
midi-chan-range = midi-chan "-" midi-chan
ミディchan範囲=ミディ-chan「-」ミディ-chan
; decimal value of left midi-chan
; MUST be strictly less than decimal
; value of right midi-chan
; 左のミディ-chanのデシマル値。 小数より厳密に少なくなければなりません。 右のミディ-chanの値
midi-chan = %d0-15
ミディ-chan=%d0-15
; ; list definitions for the ch_ field list (f-list) ;
; ; ch_分野リスト(f-リスト)のための定義を記載してください。
f-list = midi-field-element *("." midi-field-element)
f-リスト=ミディフィールド要素*(「. 」 ミディフィールド要素、)
midi-field-element = midi-field / midi-field-range
ミディ分野のミディフィールド要素=ミディ分野/範囲
midi-field-range = midi-field "-" midi-field
;
; decimal value of left midi-field
; MUST be strictly less than decimal
; value of right midi-field
ミディ分野の範囲はミディ分野「-」ミディ分野と等しいです。 ; 左のミディ分野のデシマル値。 小数より厳密に少なくなければなりません。 正しいミディ分野の値
midi-field = four-octet
;
; large range accommodates Chapter M
; RPN (0-16383) and NRPN (16384-32767)
; parameters, and Chapter X octet sizes.
ミディ分野は4八重奏と等しいです。 ; 広い範囲は章Mに対応します。 RPN(0-16383)とNRPN(16384-32767)。 パラメタ、および章X 八重奏サイズ。
Lazzaro & Wawrzynek Standards Track [Page 153] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[153ページ]。
; ; definitions for ch_ sysex-data ;
; ; ch_sysex-データのための定義。
sysex-data = "__" h-list *("_" h-list) "__"
sysex-データは"__"h-リスト*("_"h-リスト)"__"と等しいです。
h-list = hex-field-element *("." hex-field-element)
h-リスト=十六進法フィールド要素*(「. 」 十六進法フィールド要素、)
hex-field-element = hex-octet / hex-field-range
十六進法分野の十六進法フィールド要素=十六進法八重奏/範囲
hex-field-range = hex-octet "-" hex-octet
;
; hexadecimal value of left hex-octet
; MUST be strictly less than hexadecimal
; value of right hex-octet
十六進法分野の範囲は十六進法八重奏「-」十六進法八重奏と等しいです。 ; 左の十六進法八重奏の16進値。 16進より厳密に少なくなければなりません。 正しい十六進法八重奏の値
hex-octet = 2("0" / "1" / "2"/ "3" / "4" /
"5" / "6" / "7" / "8" / "9" /
"A" / "B" / "C" / "D" / "E" / "F")
;
; rewritten version of hex-octet in [RFC2045]
; (page 23).
; note that a-f are not permitted, only A-F.
; hex-octet values MUST NOT exceed 7F.
十六進法八重奏=2、(「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/、「7インチ/、「8インチ/、「9インチ/「A」/「B」/「C」/「D」/「E」/「F」)、;、」 ; [RFC2045]の十六進法八重奏の書き直されたバージョン。 (23ページ。) ; 唯一のA-F、a-fをある注意が可能にしませんでした。 ; 十六進法八重奏値は7Fを超えてはいけません。
; ; definitions for rinit parameter ;
; ; rinitパラメタのための定義。
mime-type = "audio" / "application"
パントマイムタイプは「オーディオ」/「アプリケーション」と等しいです。
mime-subtype = token
;
; See Appendix C.6.2 for registration
; requirements for rinit type/subtypes.
パントマイム-「副-タイプ」は象徴と等しいです。 ; 登録に関してAppendix C.6.2を見てください。 rinitタイプ/血液型亜型のための要件。
; ; definitions for base64 encoding ; copied from [RFC4566]
; ; base64コード化のための定義。 模造します。[RFC4566]
base-64-block = *base64-unit [base64-pad]
64が妨げるベースは*base64-ユニットと等しいです。[base64-パッド]
base64-unit = 4base64-char
base64-ユニット=4base64-炭
base64-pad = 2base64-char "==" / 3base64-char "="
3base64-炭のbase64-パッド=2base64-炭「=」/「=」
base64-char = %x41-5A / %x61-7A / %x30-39 / "+" / "/"
; A-Z, a-z, 0-9, "+" and "/"
「base64-炭=%x41-5A/%x61-7A/%x30-39/「+」/」/、」、。 「」 1Zの、そして、1zの0-9、「+」、および/」
Lazzaro & Wawrzynek Standards Track [Page 154] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[154ページ]。
; ; generic rules ;
; ; 一般的な規則。
ietf-extension = token
;
; ietf-extension may only be defined in
; standards-track RFCs.
ietf-拡大は象徴と等しいです。 ; ietf-拡大は中で定義されるだけであるかもしれません。 標準化過程RFCs。
extension = token
;
; extension may be defined by filing
; a registration with IANA.
拡大は象徴と等しいです。 ; 拡大はファイリングで定義されるかもしれません。 IANAとの登録。
four-octet = %d0-4294967295
; unsigned encoding of 32-bits
4八重奏の=%d0-4294967295。 32ビットの無記名のコード化
nonzero-four-octet = %d1-4294967295
; unsigned encoding of 32-bits, ex-zero
非零four八重奏=%d1-4294967295。 32ビット、元のゼロの無記名のコード化
uri-element = URI-reference
; as defined in [RFC3986]
uri-要素はURI参照と等しいです。 定義されたコネとして[RFC3986]
double-quote = %x22
二重引用文=%x22
; the double-quote (") character
; 二重引用文、(「)、キャラクタ、」
token = 1*token-char
; copied from [RFC4566]
象徴は1*象徴炭と等しいです。 模造します。[RFC4566]
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39 / %x41-5A / %x5E-7E
; copied from [RFC4566]
%x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7象徴炭=E。 模造します。[RFC4566]
cid-block = 1*cid-char
Cidブロック=1*Cid炭
cid-char = token-char cid-char =/ "@" cid-char =/ "," cid-char =/ ";" cid-char =/ ":" cid-char =/ "\" cid-char =/ "/" cid-char =/ "[" cid-char =/ "]" cid-char =/ "?" cid-char =/ "="
」 「象徴炭のCid Cid炭=炭は/"@"Cid炭=/と等しい」Cid炭の=/、」、;、」 「Cid炭は/と等しい」:、」 」 「Cid炭の「\」Cid=/炭は/と等しく」/Cid炭「[「Cid炭は/と等しい」]」Cid=/炭=/“?"Cid炭の=/「=」
Lazzaro & Wawrzynek Standards Track [Page 155] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[155ページ]。
;
; add back in the tspecials [RFC2045], except for
; double-quote and the non-email safe () <>
; note that "cid" defined above ensures that
; cid-block is enclosed with double-quotes
; ; tspecials[RFC2045]を加えてください、。 二重引用文と非メール金庫()<>。 上で定義された「Cid」がそれを確実にすることに注意してください。 Cidブロックは二重引用符まで囲まれます。
; external references ; URI-reference: from [RFC3986]
; 外部参照。 URI参照: from[RFC3986]
; ; End of ABNF
; ; ABNFの端
The mpeg4-generic RTP payload [RFC3640] defines a "mode" parameter that signals the type of MPEG stream in use. We add a new mode value, "rtp-midi", using the ABNF rule below:
mpeg4-ジェネリックRTPペイロード[RFC3640]はMPEGの流れのタイプを使用中に示す「モード」パラメタを定義します。 以下のABNF規則を使用して、私たちは新型値、「rtp-ミディ」を加えます:
; ; mpeg4-generic mode parameter extension ;
; ; mpeg4-ジェネリックモードパラメタ拡張子。
mode =/ "rtp-midi"
; as described in Section 6.2 of this memo
モード=/「rtpミディ」。 このメモのセクション6.2では、説明されます。
E. A MIDI Overview for Networking Specialists
E。 ネットワーク専門家のためのミディ概観
This appendix presents an overview of the MIDI standard, for the benefit of networking specialists new to musical applications. Implementors should consult [MIDI] for a normative description of MIDI.
この付録は音楽のアプリケーションに新しいネットワーク専門家の利益のMIDI規格の概観を提示します。 作成者はMIDIの標準の記述のために[MIDI]に相談するべきです。
Musicians make music by performing a controlled sequence of physical movements. For example, a pianist plays by coordinating a series of key presses, key releases, and pedal actions. MIDI represents a musical performance by encoding these physical gestures as a sequence of MIDI commands. This high-level musical representation is compact but fragile: one lost command may be catastrophic to the performance.
ミュージシャンは、物理的な運動の制御系列を実行することによって、愛の音楽を合奏します。 例えば、ピアニストは、一連の主要なプレス、主要なリリース、およびペダル動作を調整することによって、プレーします。 MIDIは、MIDIの系列が命令するようにこれらの物理的なジェスチャーをコード化することによって、演奏を表します。 このハイレベルの音楽の表現は、コンパクトですが、こわれやすいです: 1つの無くなっているコマンドが性能に壊滅的であるかもしれません。
MIDI commands have much in common with the machine instructions of a microprocessor. MIDI commands are defined as binary elements. Bitfields within a MIDI command have a regular structure and a specialized purpose. For example, the upper nibble of the first command octet (the opcode field) codes the command type. MIDI commands may consist of an arbitrary number of complete octets, but most MIDI commands are 1, 2, or 3 octets in length.
MIDIコマンドには、マイクロプロセッサの機械語命令と共用して多くがあります。 MIDIコマンドは2進素子と定義されます。 MIDIコマンドの中のBitfieldsには、通常の構造と専門化している目的があります。 例えば、最初のコマンド八重奏(opcode分野)の上側の少量がコマンドタイプをコード化します。 MIDIコマンドは完全な八重奏の特殊活字の数字から成るかもしれませんが、ほとんどのMIDIコマンドが、長さが1、2、または3つの八重奏です。
Lazzaro & Wawrzynek Standards Track [Page 156] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[156ページ]。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Channel Voice Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| NoteOff (end a note) | 1000cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| NoteOn (start a note) | 1001cccc 0nnnnnnn 0vvvvvvv |
|-------------------------------------------------------------|
| PTouch (Polyphonic Aftertouch) | 1010cccc 0nnnnnnn 0aaaaaaa |
|-------------------------------------------------------------|
| CControl (Controller Change) | 1011cccc 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| PChange (Program Change) | 1100cccc 0ppppppp |
|-------------------------------------------------------------|
| CTouch (Channel Aftertouch) | 1101cccc 0aaaaaaa |
|-------------------------------------------------------------|
| PWheel (Pitch Wheel) | 1110cccc 0xxxxxxx 0yyyyyyy |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | チャンネル音声メール| Bitfieldパターン| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | NoteOff(音を終わらせます)| 1000cccc 0nnnnnnn 0vvvvvvv| |-------------------------------------------------------------| | NoteOn(注意を始めます)| 1001cccc 0nnnnnnn 0vvvvvvv| |-------------------------------------------------------------| | PTouch(ポリフォニーの残触覚)| 1010cccc 0nnnnnnn 0aaaaaaa| |-------------------------------------------------------------| | CControl(コントローラ変化)| 1011cccc 0xxxxxxx 0yyyyyyy| |-------------------------------------------------------------| | PChange(プログラム変化)| 1100cccc 0ppppppp| |-------------------------------------------------------------| | CTouch(チャンネル残触覚)| 1101cccc 0aaaaaaa| |-------------------------------------------------------------| | PWheel(大歯車)| 1110cccc 0xxxxxxx 0yyyyyyy| -------------------------------------------------------------
Figure E.1 -- MIDI Channel Messages
図E.1--ミディチャンネルメッセージ
Lazzaro & Wawrzynek Standards Track [Page 157] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[157ページ]。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Common Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Exclusive | 11110000, followed by a |
| | list of 0xxxxxx octets, |
| | followed by 11110111 |
|-------------------------------------------------------------|
| MIDI Time Code Quarter Frame | 11110001 0xxxxxxx |
|-------------------------------------------------------------|
| Song Position Pointer | 11110010 0xxxxxxx 0yyyyyyy |
|-------------------------------------------------------------|
| Song Select | 11110011 0xxxxxxx |
|-------------------------------------------------------------|
| Undefined | 11110100 |
|-------------------------------------------------------------|
| Undefined | 11110101 |
|-------------------------------------------------------------|
| Tune Request | 11110110 |
|-------------------------------------------------------------|
| System Exclusive End Marker | 11110111 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | システムの一般的なメッセージ| Bitfieldパターン| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | システム排他的です。| aがあとに続いた11110000| | | 0xxxxxx八重奏のリスト| | | 11110111はあとに続いています。| |-------------------------------------------------------------| | ミディ時間コード4分の1フレーム| 11110001 0xxxxxxx| |-------------------------------------------------------------| | 歌の位置のポインタ| 11110010 0xxxxxxx 0yyyyyyy| |-------------------------------------------------------------| | 歌の選びます。| 11110011 0xxxxxxx| |-------------------------------------------------------------| | 未定義| 11110100 | |-------------------------------------------------------------| | 未定義| 11110101 | |-------------------------------------------------------------| | 旋律要求| 11110110 | |-------------------------------------------------------------| | システムの排他的なエンドマーカー| 11110111 | -------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| System Realtime Messages | Bitfield Pattern |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Clock | 11111000 |
|-------------------------------------------------------------|
| Undefined | 11111001 |
|-------------------------------------------------------------|
| Start | 11111010 |
|-------------------------------------------------------------|
| Continue | 11111011 |
|-------------------------------------------------------------|
| Stop | 11111100 |
|-------------------------------------------------------------|
| Undefined | 11111101 |
|-------------------------------------------------------------|
| Active Sense | 11111110 |
|-------------------------------------------------------------|
| System Reset | 11111111 |
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | システムリアルタイムでメッセージ| Bitfieldパターン| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 時計| 11111000 | |-------------------------------------------------------------| | 未定義| 11111001 | |-------------------------------------------------------------| | 始め| 11111010 | |-------------------------------------------------------------| | 続いてください。| 11111011 | |-------------------------------------------------------------| | 停止| 11111100 | |-------------------------------------------------------------| | 未定義| 11111101 | |-------------------------------------------------------------| | アクティブな感覚| 11111110 | |-------------------------------------------------------------| | システム・リセット| 11111111 | -------------------------------------------------------------
Figure E.2 -- MIDI System Messages
図E.2--ミディシステムメッセージ
Lazzaro & Wawrzynek Standards Track [Page 158] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[158ページ]。
Figure E.1 and E.2 show the MIDI command family. There are three major classes of commands: voice commands (opcode field values in the range 0x8 through 0xE), system common commands (opcode field 0xF, commands 0xF0 through 0xF7), and system real-time commands (opcode field 0xF, commands 0xF8 through 0xFF). Voice commands code the musical gestures for each timbre in a composition. Systems commands perform functions that usually affect all voice channels, such as System Reset (0xFF).
図E.1とE.2はMIDIコマンド家を見せています。 3つの主要なクラスのコマンドがあります: 声は(0xEを通した範囲0x8のopcode分野値)、システム一般的なコマンド(opcodeは0xFをさばきます、と0xF0は0xF7を通して命令する)、およびシステムのリアルタイムのコマンドを命令します(opcodeは0xFをさばきます、と0xF8は0xFFを通して命令します)。 音声命令は構成における各音色のための音楽のジェスチャーをコード化します。 システムコマンドは通常、System Resetなどのすべての音声チャンネル(0xFF)に影響する機能を実行します。
E.1. Commands Types
E.1。 タイプを命令します。
Voice commands execute on one of 16 MIDI channels, as coded by its 4-bit channel field (field cccc in Figure E.1). In most applications, notes for different timbres are assigned to different channels. To support applications that require more than 16 channels, MIDI systems use several MIDI command streams in parallel, to yield 32, 48, or 64 MIDI channels.
音声命令は16MIDIの1つでチャンネルを処刑します、4ビットのチャンネル分野(図E.1の分野cccc)によってコード化されるように。 ほとんどのアプリケーションでは、異なった音色のための注意は異なったチャンネルに割り当てられます。 16個以上のチャンネルを必要とするアプリケーションを支持するなら、MIDIシステムは、32、48、または64個のMIDIチャンネルをもたらすのに平行でいくつかのMIDIコマンドの流れを使用します。
As an example of a voice command, consider a NoteOn command (opcode 0x9), with binary encoding 1001cccc 0nnnnnnn 0aaaaaaa. This command signals the start of a musical note on MIDI channel cccc. The note has a pitch coded by the note number nnnnnnn, and an onset amplitude coded by note velocity aaaaaaa.
音声命令に関する例として、バイナリーが1001cccc 0nnnnnnn 0aaaaaaaをコード化していて、NoteOnがコマンド(opcode0x9)であると考えてください。 このコマンドはMIDIチャンネルccccにおける音符の始まりを示します。 注意で、注意番号nnnnnnn、および注意速度aaaaaaaによってコード化された開始振幅でピッチをコード化します。
Other voice commands signal the end of notes (NoteOff, opcode 0x8), map a specific timbre to a MIDI channel (PChange, opcode 0xC), or set the value of parameters that modulate the timbral quality (all other voice commands). The exact meaning of most voice channel commands depends on the rendering algorithms the MIDI receiver uses to generate sound. In most applications, a MIDI sender has a model (in some sense) of the rendering method used by the receiver.
他の音声命令は、メモ(NoteOff、opcode0x8)の端を示すか、MIDIチャンネル(PChange、opcode 0xC)への特定の音色を写像するか、またはtimbral品質(他のすべての音声命令)を調節するパラメタの値を設定します。 ほとんどの声のチャネル指令の正確な意味はMIDI受信機が音を発生させるのに使用する表現アルゴリズムによります。 ほとんどのアプリケーションでは、MIDI送付者は受信機で、表現方法のモデル(何らかの意味における)を使用させます。
System commands perform a variety of global tasks in the stream, including "sequencer" playback control of pre-recorded MIDI commands (the Song Position Pointer, Song Select, Clock, Start, Continue, and Stop messages), SMPTE time code (the MIDI Time Code Quarter Frame command), and the communication of device-specific data (the System Exclusive messages).
システム・コマンドは流れでさまざまなグローバルなタスクを実行します、あらかじめ記録されたMIDIコマンドの「シーケンサ」再生コントロール(Song Position Pointer、Song Select、Clock、Start、Continue、およびStopメッセージ)、SMPTEタイム・コード(MIDI Time Code Quarter Frameコマンド)、および装置特有のデータに関するコミュニケーション(System Exclusiveメッセージ)を含んでいて。
E.2. Running Status
E.2。 走行状態
All MIDI command bitfields share a special structure: the leading bit of the first octet is set to 1, and the leading bit of all subsequent octets is set to 0. This structure supports a data compression system, called running status [MIDI], that improves the coding efficiency of MIDI.
すべてのMIDIが、bitfieldsが特別な構造を共有すると命令します: 最初の八重奏の主なビットは1に設定されます、そして、すべてのその後の八重奏の主なビットは0に設定されます。 この構造はMIDIのコード化効率を高める走行状態[MIDI]と呼ばれるデータ圧縮システムをサポートします。
Lazzaro & Wawrzynek Standards Track [Page 159] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[159ページ]。
In running status coding, the first octet of a MIDI voice command may be dropped if it is identical to the first octet of the previous MIDI voice command. This rule, in combination with a convention to consider NoteOn commands with a null third octet as NoteOff commands, supports the coding of note sequences using two octets per command.
走行状態コード化では、それが前のMIDI音声命令の最初の八重奏と同じであるなら、MIDI音声命令の最初の八重奏は落とされるかもしれません。 NoteOffが命令するように3番目のヌル八重奏によるNoteOnコマンドを考えるコンベンションと組み合わせて、この規則は、1コマンドあたり2つの八重奏を使用することで注意系列のコード化を支持します。
Running status coding is only used for voice commands. The presence of a system common message in the stream cancels running status mode for the next voice command. However, system real-time messages do not cancel running status mode.
走行状態コード化は音声命令に使用されるだけです。 流れにおける、システムの一般的なメッセージの存在は次の音声命令のための走行状態モードを取り消します。 しかしながら、システムのリアルタイムのメッセージは走行状態モードを取り消しません。
E.3. Command Timing
E.3。 コマンドタイミング
The bitfield formats in Figures E.1 and E.2 do not encode the execution time for a command. Timing information is not a part of the MIDI command syntax itself; different applications of the MIDI command language use different methods to encode timing.
bitfieldは図でE.1をフォーマットします、そして、E.2はコマンドのために実行時間をコード化しません。 タイミング情報はMIDIコマンド構文自体の一部ではありません。 MIDIコマンド言語の異なった応用はタイミングをコード化する異なった方法を使用します。
For example, the MIDI command set acts as the transport layer for MIDI 1.0 DIN cables [MIDI]. MIDI cables are short asynchronous serial lines that facilitate the remote operation of musical instruments and audio equipment. Timestamps are not sent over a MIDI 1.0 DIN cable. Instead, the standard uses an implicit "time of arrival" code. Receivers execute MIDI commands at the moment of arrival.
例えば、MIDI1.0DINのためのトランスポート層が[MIDI]に電報を打つとき、MIDIコマンドセットは行動します。 MIDIケーブルは楽器とオーディオ設備のリモート操作を容易にする短い非同期なシリアル・ラインです。 タイムスタンプはMIDI1.0DINケーブルの上に送られません。 代わりに、規格は暗黙の「到着時刻」コードを使用します。 受信機は到着の瞬間でのMIDIコマンドを実行します。
In contrast, Standard MIDI Files (SMFs, [MIDI]), a file format for representing complete musical performances, add an explicit timestamp to each MIDI command, using a delta encoding scheme that is optimized for statistics of musical performance. SMF timestamps usually code timing using the metric notation of a musical score. SMF meta-events are used to add a tempo map to the file, so that score beats may be accurately converted into units of seconds during rendering.
対照的に、Standard MIDIファイル(SMFs、[MIDI])(完全な演奏を表すためのファイル形式)はそれぞれのMIDIコマンドに明白なタイムスタンプを追加します、演奏の統計のために最適化される計画をコード化するデルタを使用して。 通常、SMFタイムスタンプは、楽譜のメートル法の記法を使用することでタイミングをコード化します。 SMFメタ出来事はア・テンポ地図をファイルに追加するのに使用されます、正確に表現の間のユニットの秒にスコアビートを変換できるように。
E.4. AudioSpecificConfig Templates for MMA Renderers
E.4。 MMAレンダラーのためのAudioSpecificConfigテンプレート
In Section 6.2 and Appendix C.6.5, we describe how session descriptions include an AudioSpecificConfig data block to specify a MIDI rendering algorithm for mpeg4-generic RTP MIDI streams.
セクション6.2とAppendix C.6.5では、私たちはセッション記述がmpeg4-ジェネリックRTP MIDIの流れのためのMIDI表現アルゴリズムを指定するためにどうAudioSpecificConfigデータ・ブロックを含むかを説明します。
The bitfield format of AudioSpecificConfig is defined in [MPEGAUDIO]. StructuredAudioSpecificConfig, a key data structure coded in AudioSpecificConfig, is defined in [MPEGSA].
AudioSpecificConfigのbitfield書式は[MPEGAUDIO]で定義されます。 StructuredAudioSpecificConfig(AudioSpecificConfigでコード化された重要なデータ構造)は[MPEGSA]で定義されます。
For implementors wishing to specify Structured Audio renderers, a full understanding of [MPEGSA] and [MPEGAUDIO] is essential. However, many implementors will limit their rendering options to the two MIDI Manufacturers Association renderers that may be specified in
Structured Audioレンダラーを指定したがっている作成者にとって、[MPEGSA]と[MPEGAUDIO]の十分な理解は不可欠です。 しかしながら、多くの作成者が彼らの表現オプションをそれが指定されるかもしれない2つのMIDI Manufacturers Associationレンダラーに制限するでしょう。
Lazzaro & Wawrzynek Standards Track [Page 160] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[160ページ]。
AudioSpecificConfig: General MIDI (GM, [MIDI]) and Downloadable Sounds 2 (DLS 2, [DLS2]).
AudioSpecificConfig: ジェネラルミディ(GM、[ミディ])とダウンローダブルな音2(dl2、[DLS2])。
To aid these implementors, we reproduce the AudioSpecificConfig bitfield formats for a GM renderer and a DLS 2 renderer below. We have checked these bitfields carefully and believe they are correct. However, we stress that the material below is informative, and that [MPEGAUDIO] and [MPEGSA] are the normative definitions for AudioSpecificConfig.
これらの作成者を支援するために、私たちはGMレンダラーと以下のDLS2レンダラーのためにAudioSpecificConfig bitfield形式を再生させます。 私たちは、丹念にこれらのbitfieldsをチェックして、彼らが正しいと信じています。 しかしながら、私たちは以下の材料が有益であり、[MPEGAUDIO]と[MPEGSA]がAudioSpecificConfigのための標準の定義であると強調します。
As described in Section 6.2, a minimal mpeg4-generic session description encodes the AudioSpecificConfig binary bitfield as a hexadecimal string (whose format is defined in [RFC3640]) that is assigned to the "config" parameter. As described in Appendix C.6.3, a session description that uses the render parameter encodes the AudioSpecificConfig binary bitfield as a Base64-encoded string assigned to the "inline" parameter, or in the body of an HTTP URL assigned to the "url" parameter.
セクション6.2で説明されるように、最小量のmpeg4-ジェネリックセッション記述は「コンフィグ」パラメタに割り当てられる16進ストリング(書式は[RFC3640]で定義される)としてAudioSpecificConfigの2進のbitfieldをコード化します。 Appendix C.6.3、それが使用するセッション記述で説明される、「インライン」のパラメタに割り当てられた、Base64によってコード化されたストリング、または"url"パラメタに割り当てられた1つのHTTP URLのボディーでAudioSpecificConfigの2進のbitfieldをパラメタエンコードにしてください。
Below, we show a simplified binary AudioSpecificConfig bitfield format, suitable for sending and receiving GM and DLS 2 data:
以下では、私たちが送付に適当な簡易型の2進のAudioSpecificConfig bitfield形式、GMを受けて、およびDLSに2つのデータを示しています:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AOTYPE |FREQIDX|CHANNEL|SACNK| FILE_BLK 1 (required) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|SACNK| FILE_BLK 2 (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1|SACNK| FILE_BLK N (optional) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| (first "0" bit terminates FILE_BLK list)
+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AOTYPE|FREQIDX|チャンネル|SACNK| _BLK1(必要です)をファイルしてください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|SACNK| _BLK2(任意の)をファイルしてください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |1|SACNK| _BLK N(任意の)をファイルしてください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| (最初に、「0インチのビットがファイル_BLKリストを終える、)、」 +-+-+
Figure E.3 -- Simplified AudioSpecificConfig
図E.3--簡易型のAudioSpecificConfig
The 5-bit AOTYPE field specifies the Audio Object Type as an unsigned integer. The legal values for use with mpeg4-generic RTP MIDI streams are "15" (General MIDI), "14" (DLS 2), and "13" (Structured Audio). Thus, receivers that do not support all three mpeg4-generic renderers may parse the first 5 bits of an AudioSpecificConfig coded in a session description and reject sessions that specify unsupported renderers.
5ビットのAOTYPE分野は符号のない整数としてAudio Object Typeを指定します。 mpeg4-ジェネリックRTP MIDIの流れによる使用のための法定価格がそうである、「15インチ(ジェネラルミディ)、「14インチ(dl2)、および「13インチ(オーディオを構造化します)。」 したがって、すべての3つのmpeg4-ジェネリックレンダラーを支持するというわけではない受信機は、セッション記述でコード化されたAudioSpecificConfigの最初の5ビットを分析して、サポートされないレンダラーを指定するセッションを拒絶するかもしれません。
The 4-bit FREQIDX field specifies the sampling rate of the renderer. We show the mapping of FREQIDX values to sampling rates in Figure E.4. Senders MUST specify a sampling frequency that matches the RTP clock rate, if possible; if not, senders MUST specify the escape
4ビットのFREQIDX分野はレンダラーの標本抽出率を指定します。 私たちはFREQIDX値に関するマッピングを図E.4の標本抽出率に示しています。 Sendersは可能であるならRTPクロックレートに合っているサンプリング周波数を指定しなければなりません。 そうでなければ、送付者はエスケープを指定しなければなりません。
Lazzaro & Wawrzynek Standards Track [Page 161] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[161ページ]。
value. Receivers MUST consult the RTP clock parameter for the true sampling rate if the escape value is specified.
値。 エスケープ値が指定されるなら、受信機は真の標本抽出率のためのRTP時計パラメタに相談しなければなりません。
FREQIDX Sampling Frequency
FREQIDXサンプリング周波数
0x0 96000
0x1 88200
0x2 64000
0x3 48000
0x4 44100
0x5 32000
0x6 24000
0x7 22050
0x8 16000
0x9 12000
0xa 11025
0xb 8000
0xc reserved
0xd reserved
0xe reserved
0xf escape value
0×0 96000 0×1 88200 0×2 64000 0×3 48000 0×4 44100 0×5 32000 0×6 24000 0×7 22050 0×8 16000 0×9 12000 0xa11025の0xbの8000の0xcの予約された0xdは0xeの予約された0xfエスケープ価値を予約しました。
Figure E.4 -- FreqIdx encoding
図E.4--FreqIdxコード化
The 4-bit CHANNEL field specifies the number of audio channels for the renderer. The values 0x1 to 0x5 specify 1 to 5 audio channels; the value 0x6 specifies 5+1 surround sound, and the value 0x7 specifies 7+1 surround sound. If the rtpmap line in the session description specifies one of these formats, CHANNEL MUST be set to the corresponding value. Otherwise, CHANNEL MUST be set to 0x0.
4ビットのCHANNEL分野は音声チャンネルの数をレンダラーに指定します。 値0×1から0x5は1〜5つの音声チャンネルを指定します。 値0x6は5+1取り囲むもの音を指定します、そして、値0x7は7+1取り囲むもの音を指定します。 セッション記述では、これらの形式の1つはrtpmap線であるなら指定しています、CHANNEL MUST。換算値に設定されてください。 そうでなければ、CHANNEL MUST、0×0に設定されてください。
The CHANNEL field is followed by a list of one or more binary file data blocks. The 3-bit SACNK field (the chunk_type field in class StructuredAudioSpecificConfig, defined in [MPEGSA]) specifies the type of each data block.
1つ以上のバイナリーファイルデータ・ブロック以上のリストはCHANNEL野原のあとに続いています。 3ビットのSACNK分野([MPEGSA]で定義されたクラスStructuredAudioSpecificConfigの塊_タイプ分野)はそれぞれのデータ・ブロックのタイプを指定します。
For General MIDI, only Standard MIDI Files may appear in the list (SACNK field value 2). For DLS 2, only Standard MIDI Files and DLS 2 RIFF files (SACNK field value 4) may appear. For both of these file types, the FILE_BLK field has the format shown in Figure E.5: a 32- bit unsigned integer value (FILE_LEN) coding the number of bytes in the SMF or RIFF file, followed by FILE_LEN bytes coding the file data.
ジェネラルミディに関しては、Standard MIDIファイルだけがリスト(SACNK分野価値2)に現れるかもしれません。 DLS2に関しては、Standard MIDIファイルとDLS2RIFFファイル(SACNK分野価値4)だけが現れるかもしれません。 これらのファイルの種類の両方に関しては、FILE_BLK分野には、図E.5に示された書式があります: 32は、ファイルデータをコード化するFILE_LENバイトがあとに続いたSMFかRIFFファイルのバイト数をコード化しながら、符号のない整数値(FILE_LEN)に噛み付きました。
Lazzaro & Wawrzynek Standards Track [Page 162] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[162ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_LEN (32-bit, a byte count SMF file or RIFF file) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILE_DATA (file contents, a list of FILE_LEN bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FILE_LEN(32ビット、バイト・カウントSMFファイルまたはRIFFファイル)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FILE_DATA(ファイルコンテンツ、FILE_LENバイトのリスト)… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure E.5 -- The FILE_BLK field format
図E.5--FILE_BLKフィールド形式
Note that several files may follow CHANNEL field. The "1" constant fields in Figure E.3 code the presence of another file; the "0" constant field codes the end of the list. The final "0" bit in Figure E.3 codes the absence of special coding tools (see [MPEGAUDIO] for details). Senders not using these tools MUST append this "0" bit; receivers that do not understand these coding tools MUST ignore all data following a "1" in this position.
いくつかのファイルがCHANNEL野原に続くかもしれないことに注意してください。 「図E.3の1インチの固定フィールドは別のファイルについて存在をコード化します」。 「0インチの固定フィールドはリストの終わりをコード化します。」 最終的な「特別なコード化の不在がツーリングする図E.3コードで噛み付いた0インチ(詳細に関して[MPEGAUDIO]を見ます)。」 これらのツールを使用していないSendersはこの「0インチのビット」を追加しなければなりません。 「この位置の1インチ」に続いて、これらのコーディング・ツールを理解していない受信機はすべてのデータを無視しなければなりません。
The StructuredAudioSpecificConfig bitfield structure requires the presence of one FILE_BLK. For mpeg4-generic RTP MIDI use of DLS 2, FILE_BLKs MUST code RIFF files or SMF files. For mpeg4-generic RTP MIDI use of General MIDI, FILE_BLKs MUST code SMF files. By default, this SMF will be ignored (Appendix C.6.4.1). In this default case, a GM StructuredAudioSpecificConfig bitfield SHOULD code a FILE_BLK whose FILE_LEN is 0, and whose FILE_DATA is empty.
StructuredAudioSpecificConfig bitfield構造は1FILE_BLKを存在に要求します。 DLS2のmpeg4-ジェネリックRTP MIDI使用のために、FILE_BLKsはRIFFファイルかSMFファイルをコード化しなければなりません。 ジェネラルミディのmpeg4-ジェネリックRTP MIDI使用のために、FILE_BLKsはSMFファイルをコード化しなければなりません。 デフォルトで、このSMFは無視されるでしょう(付録C.6.4.1)。 この不履行格、GM StructuredAudioSpecificConfig bitfield SHOULDコードにおけるFILE_LENが0歳であり、FILE_DATAが空であるFILE_BLK。
To complete this appendix, we derive the StructuredAudioSpecificConfig that we use in the General MIDI session examples in this memo. Referring to Figure E.3, we note that for GM, AOTYPE = 15. Our examples use a 44,100 Hz sample rate (FREQIDX = 4) and are in mono (CHANNEL = 1). For GM, a single SMF is encoded (SACNK = 2), using the SMF shown in Figure E.6 (a 26 byte file).
この付録を完成するために、私たちはこのメモによるジェネラルミディセッションの例で使用するStructuredAudioSpecificConfigを引き出します。 図E.3について言及して、私たちはGM、AOTYPE=15によってそれに注意します。 私たちの例は、4万4100Hzの見本郵送料率(FREQIDX=4)を使用して、モノタイプ(CHANNEL=1)にはあります。 GMに関しては、独身のSMFはコード化されます(SACNK=2)、図E.6(26バイトのファイル)で見せられたSMFを使用して。
--------------------------------------------
| MIDI File = <Header Chunk> <Track Chunk> |
--------------------------------------------
-------------------------------------------- | MIDIファイル=<ヘッダー塊><道塊>。| --------------------------------------------
<Header Chunk> = <chunk type> <length> <format> <ntrks> <divsn>
4D 54 68 64 00 00 00 06 00 00 00 01 00 60
<ヘッダーChunk>=<塊タイプ><の長さの><は><ntrks><divsn>4D54 68 64 00 00 00 06 00 00 00 01 00 60をフォーマットします。
<Track Chunk> = <chunk type> <length> <delta-time> <end-event>
4D 54 72 6B 00 00 00 04 00 FF 2F 00
<塊<道のChunk>=タイプ><の長さの><は><エンド出来事>4D54 72 6B00 00 00 04 00FF2F00をデルタで調節します。
Figure E.6 -- SMF file encoded in the example
図E.6--例でコード化されたSMFファイル
Lazzaro & Wawrzynek Standards Track [Page 163] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[163ページ]。
Placing these constants in binary format into the data structure shown in Figure E.3 yields the constant shown in Figure E.7.
図E.3に示されたデータ構造へのバイナリフォーマットにこれらの定数を置くと、図E.7に示された定数はもたらされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1|0 1 0 0|0 0 0 1|0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0|1 0 0 0|0 1 1 0|0 1 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 1|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|0 1 1 1|0 0 1 0|0 1 1 0|1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|0 0 0 0|1 1 1 1|1 1 1 1|0 0 1 0|1 1 1 1|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|
+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1|0 1 0 0|0 0 0 1|0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0|0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 0|1 0 0 0|0 1 1 0|0 1 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 1|0 0 0 0|0 0 0 0|0 1 1 0|0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0|1 1 0 1|0 1 0 1|0 1 0 0|0 1 1 1|0 0 1 0|0 1 1 0|1 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0 0 0 0|1 1 1 1|1 1 1 1|0 0 1 0|1 1 1 1|0 0 0 0|0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| +-+-+
Figure E.7 -- AudioSpecificConfig used in GM examples
図E.7--GMの例で使用されるAudioSpecificConfig
Expressing this bitfield as an ASCII hexadecimal string yields:
ASCII16進ストリングとしてこのbitfieldを急送するのはもたらされます:
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
7A0A0000001A4D546864000000060000000100604D54726B0000000600FF2F000
This string is assigned to the "config" parameter in the minimal mpeg4-generic General MIDI examples in this memo (such as the example in Section 6.2). Expressing this string in Base64 [RFC2045] yields:
このストリングはこのメモ(セクション6.2の例などの)による最小量のmpeg4-ジェネリックジェネラルミディの例の「コンフィグ」パラメタに割り当てられます。 Base64[RFC2045]でこのストリングを急送するのはもたらされます:
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
This string is assigned to the "inline" parameter in the General MIDI example shown in Appendix C.6.5.
このストリングはAppendix C.6.5のジェネラルミディの例の「インライン」のパラメタに割り当てられます。
Lazzaro & Wawrzynek Standards Track [Page 164] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[164ページ]。
References
参照
Normative References
引用規格
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0
Detailed Specification", 1996.
[ミディ]ミディメーカー協会。 「完全なミディ1.0仕様詳細」、1996。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC
3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer,
D., and P. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", RFC 3640, November 2003.
derミーア、J.、Mackie、D.、Swaminathan、V.、Singer、D.、およびP.Gentric、「MPEG-4つの基本の流れの輸送のためのRTP有効搭載量形式」を[RFC3640]はバンに積みます、RFC3640、2003年11月。
[MPEGSA] International Standards Organization. "ISO/IEC 14496
MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio),
2001.
[MPEGSA]世界規格組織。 「ISO/IECの14496MPEG-4インチ、パート3(オーディオ)、下位区分5(オーディオを構造化します)、2001。」
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG-
4", Part 3 (Audio), 2001.
[MPEGAUDIO]世界規格組織。 「ISO14496MPEG何4インチも、3(オーディオ)、2001を分けてください。」
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable
Sounds Specification", v98.2, 1998.
[DLS2]ミディメーカー協会。 「MIDI Downloadable Sounds Specification」、v98.2、1998。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Lazzaro & Wawrzynek Standards Track [Page 165] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[165ページ]。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388] キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[RP015] MIDI Manufacturers Association. "Recommended Practice
015 (RP-015): Response to Reset All Controllers", 11/98.
[RP015]ミディメーカー協会。 「習慣015(RP-015)は推薦されました」 11/98の「すべてのコントローラをリセットする応答」
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December
2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC3555] CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、2003年7月。
Informative References
有益な参照
[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network
Musical Performance", 11th International Workshop on
Network and Operating Systems Support for Digital Audio
and Video (NOSSDAV 2001) June 25-26, 2001, Port
Jefferson, New York.
[NMP] Lazzaro、J.、およびJ.Wawrzynek。 「ネットワーク演奏のためのケース」、ネットワークに関する第11国際ワークショップ、およびオペレーティングシステムはデジタル・オーディオとビデオ(NOSSDAV2001)のために2001年6月25日〜26日、ポート・ジェファーソン、ニューヨークを支持します。
[GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical
Events Streaming over Internet", Proceedings of the
International Conference on WEB Delivering of Music 2001,
pages 147-154.
[GRAME] Fober、D.、Orlarey、Y.、およびS.レッツ。 「インターネットの上の本当のTime Musical Events Streaming」、Music2001、147-154ページのWEB Deliveringの上の国際コンファレンスのProceedings。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[RFC2326]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
Lazzaro & Wawrzynek Standards Track [Page 166] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[166ページ]。
[ALF] Clark, D. D. and D. L. Tennenhouse. "Architectural
considerations for a new generation of protocols",
SIGCOMM Symposium on Communications Architectures and
Protocols , (Philadelphia, Pennsylvania), pp. 200--208,
IEEE, Sept. 1990.
[ALF]クラーク、D.D.、およびD.L.Tennenhouse。 「プロトコルの新しい世代建築問題」、Communications ArchitecturesとプロトコルのSIGCOMM Symposium、(フィラデルフィア(ペンシルバニア))、ページ 200--208 1990年9月のIEEE。
[RFC4696] Lazzaro, J. and J. Wawrzynek, "An Implementation Guide
for RTP MIDI", RFC 4696, November 2006.
[RFC4696] LazzaroとJ.とJ.Wawrzynek、「RTPミディのための実現ガイド」、RFC4696、2006年11月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December
2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
解放された[RFC4289]、N.、およびJ.Klensin、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC4289、2005年12月。
[RFC4571] Lazzaro, J. "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
J. [RFC4571]Lazzaro、「縁どりのリアルタイムのトランスポート・プロトコル(RTP)とRTPコントロールは接続の指向の輸送の上で(RTCP)パケットについて議定書の中で述べる」RFC4571(2006年7月)。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[SPMIDI] MIDI Manufacturers Association. "Scalable Polyphony
MIDI, Specification and Device Profiles", Document
Version 1.0a, 2002.
[SPMIDI]ミディメーカー協会。 「スケーラブルな対位法ミディ、仕様、および装置プロフィール」と、バージョン1.0a、2002は記録します。
[LCP] Apple Computer. "Logic 7 Dedicated Control Surface
Support", Appendix B. Product manual available from
www.apple.com.
[LCP]アップル・コンピューター。 「論理7Dedicated Control Surface Support」、www.apple.comから利用可能なAppendix B.Productマニュアル。
Lazzaro & Wawrzynek Standards Track [Page 167] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[167ページ]。
Authors' Addresses
作者のアドレス
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
ジョンLazzaro(対応する作者)UCバークレーCS事業部315Soda Hallバークレーカリフォルニア94720-1776
EMail: lazzaro@cs.berkeley.edu
メール: lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley CA 94720-1776
ジョンWawrzynek UCバークレーのCs区画631ソーダホールバークレーカリフォルニア94720-1776
EMail: johnw@cs.berkeley.edu
メール: johnw@cs.berkeley.edu
Lazzaro & Wawrzynek Standards Track [Page 168] RFC 4695 RTP Payload Format for MIDI November 2006
Lazzaro&Wawrzynek規格はミディ2006年11月にRFC4695RTP有効搭載量形式を追跡します[168ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lazzaro & Wawrzynek Standards Track [Page 169]
Lazzaro&Wawrzynek標準化過程[169ページ]
一覧
スポンサーリンク
