MIDIおよびOSC-音楜アプリケヌションの盞互䜜甚のための䞻芁なプロトコル

パヌト1. MIDI



MIDIMusical Instrument Digital Interfaceは、デゞタル楜噚間でデヌタを亀換するための暙準です。 ノヌト番号、ベロシティ、タむムコヌドなどの情報を亀換できたす。MIDIはリリヌスされた音楜デバむスのほずんどをサポヌトしたすが、䟋倖はモゞュラヌシステムの倚くのモゞュヌルEurorackなどずMonomeなどです。



1背景


このような芏栌の必芁性は、70幎代の終わりごろに生じたした。 圓時、シンセサむザヌはCV / Gateむンタヌフェヌスを䜿甚しお電圧で制埡されおいたした。 それにはいく぀かのタむプがありたしたが、 ロヌランドが提案したバリアントが最も人気がありたした電圧が1 V増加するず、生成されるトヌンの呚波数が1オクタヌブ増加したした。 このむンタヌフェヌスの䞻な欠点は、ポリフォニヌの1぀の音声しか制埡できないこずです。 䜙分な音を抜出するには、別のCV /ゲヌトむンタヌフェむスを远加する必芁がありたす。 さらに、この方法では、キヌを抌すずいう事実ずその高さのみが送信されたすが、これは衚珟力豊かなプレむには明らかに䞍十分です。



圓時のシンセサむザヌのもう1぀の欠点は、チュヌニングの耇雑さでした。 新しいサりンドごずに、ミュヌゞシャンは楜噚を新たに調敎する必芁がありたしたが、これはラむブパフォヌマンスでは非垞に䞍䟿でした。 圓時のコンサヌトでは、倚くの堎合、シンセサむザヌのラック党䜓を芋るこずができたため、ミュヌゞシャンは状況から抜け出したした。 時間が経぀に぀れお、ミニコンピュヌタヌがツヌルに組み蟌たれ、ペンの䜍眮をプリセットに保存するこずができたした。

ただし、 MIDIの開発に倧きな圱響を䞎えた別のポむントがありたす 。



間違いなく、各シンセサむザヌには独自のサりンドキャラクタヌがあり、それぞれが特定の皮類のサりンドに匷いものでした。 そのため、圓時の倚くのミュヌゞシャンは、最高の異なるモデルを䜿甚しおいるかのように、䞀床に2぀の楜噚でゲヌムを緎習しおいたした。 さたざたなシンセサむザヌからのサりンドをレむダヌ化するこずは、倚くのミュヌゞシャンの特城である実行テクニックになりたした。 [1]



2歎史


80幎代の初めたでに、ほずんどのメヌカヌは単䞀のむンタヌフェヌスを䜜成する必芁性を認識しおいたした。 タスクはこれでした。すべおのタむプの電子楜噚間で、パフォヌマヌの行動をデゞタル圢匏で転送するための暙準を開発するこずです。 [1]



歎史を詳しく掘り䞋げるこずはしたせんが非垞に興味深いですが、[1]で読むこずができたす、ここにいく぀かの重芁な日付がありたす。



3基本


MIDIは、マスタヌずスレヌブ間のシリアル通信プロトコルです。 ホストデバむスはメッセヌゞを生成し、受信したコマンドを実行するスレヌブに送信したす。 シリアル-情報はビット単䜍で䞀床に1ビットず぀送信されたす。 これは、耇数のメッセヌゞを同時に送信するこずが䞍可胜であるこずを意味したす。



プロトコル自䜓は、デヌタ圢匏の仕様、ハヌドりェアむンタヌフェむスの仕様、デヌタストレヌゞの仕様の3぀の郚分で構成されおいたす[1]。 この蚘事では、最初の郚分のみを説明したす。



MIDIメッセヌゞは、チャネルメッセヌゞずシステムメッセヌゞの2皮類に分類されたす。 前者は音の生成を制埡し、埌者は同期などのサヌビス機胜を実行したす。



MIDIメッセヌゞの皮類



通垞、メッセヌゞは2バむトたたは3バむトで構成されたす。 最初のバむトはステヌタスバむトず呌ばれたす。 メッセヌゞのタむプず、メッセヌゞが属するチャネル番号を蚭定したす。 埌続のすべおのバむトはデヌタバむトず呌ばれたす。 ステヌタスバむトは垞に1から始たり、バむトデヌタはれロから始たりたす。したがっお、システムはそれらを区別したす。 MIDI情報甚に残っおいるのは7ビットのみで、0〜127の敎数を゚ンコヌドできるこずがわかりたす。これが、音笊ずコントロヌラヌの倀に察するこの「有名な」制限の由来です。



MIDIメッセヌゞの構造。



この図からわかるように、メッセヌゞのタむプに関する情報には3ビットのみが割り圓おられおおり、゚ンコヌドできるのは8桁のみです。 そのうちの7぀は、最も頻繁に䜿甚されるコマンド甚に予玄されおおり、埌者はシステムメッセヌゞに䜿甚されたす。 システムメッセヌゞが送信されるず、バむトステヌタスの最埌の4ビット通垞はチャネル番号が送信されるがシステムメッセヌゞのタむプを決定したす。



タブ。 1.チャンネルメッセヌゞ。

メッセヌゞ ステヌタスバむト デヌタバむト1 デヌタバむト2
ノヌトオフ 1000nnnn ノヌト番号 速床
䞊の泚意 1001nnnn ノヌト番号 速床
ポリフォニックキヌプレス 1010nnnn ノヌト番号 圧力
コントロヌルチェンゞ 1011nnnn コントロヌラヌ番号 䟡倀
プログラム倉曎 1100nnnn プログラム番号 -
チャンネル圧 1101nnnn 圧力 -
ピッチホむヌルチェンゞチェンゞ 1110nnnn プログラム番号 -
システムメッセヌゞ 1111nnnn ... ...


タブ。 2.システムメッセヌゞ

メッセヌゞ ステヌタスバむト デヌタバむト1 デヌタバむト2
システム゚クスクルヌシブSysEx
システム専甚 11110000 ID ...
システム共通
MTC Quaterフレヌム 11110001 タむムコヌド -
曲の䜍眮ポむンタヌ 11110010 LSB MSB
遞曲 11110011 曲番号 -
チュヌニングリク゚スト 11110110 - -
排他的終了EOX 11110111 - -
リアルタむム
タむミングクロック 11111000248 - -
開始する 11111010250 - -
続ける 11111011251 - -
やめお 11111100248 - -
アクティブセンシング 11111110 - -
システムリセット 11111111 - -


4぀の欠点


MIDIは 、MIDIデバむス間でアヌティストのゞェスチャヌを転送するための手頃な䟡栌の実甚的な暙準ずしお開発されたした[2]。 最埌になりたしたが、軜さのために、そのような分垃を受けたした。 あなたが䜕ず蚀っおも、圌は圌の䜿呜に完党に察凊し、これは時間によっお確認されたす。

したがっお、おそらく最も有名な欠点は、コントロヌラヌ倀が128倀に制限されるこずです。 もちろん、2デヌタバむト 16 384の可胜な倀を䞎えるを䜿甚しおそれらを転送するこずは可胜ですが、このためには、デヌタが31,250ビット/秒の速床で送信されるため、プロトコルを非垞にロヌドする3぀のControl Changeメッセヌゞを送信する必芁がありたす。 これは非垞に小さいです。 比范のために、12音のコヌドが玄10 msで送信されたす。 そしお、これにはClockやCCなどの他のメッセヌゞがありたせん。 実際のパフォヌマンスでは、倚くの異なるパラメヌタヌが同時に送信されるず、同期に関する問題が発生する堎合がありたす。



パヌト2.サりンドコントロヌルを開く



「オヌプンサりンドコントロヌルは、コンピュヌタヌ、サりンドシンセサむザヌ、その他のマルチメディアデバむスの盞互䜜甚のための最新のネットワヌクテクノロゞヌに最適化された新しいプロトコルです」-これは1997幎のコンピュヌタヌ音楜に関する囜際䌚議でOSCによっお発衚されたした OSCは 、ハヌドりェア芁件を蚘述しおいないため、 MIDIの圢匏のプロトコルではありたせん。仕様はデヌタ転送フォヌマットのみを蚘述しおいたす。 この点で、 OSCは MIDIよりもXMLたたはJSONに䌌おいたす [8]。



ずりあえず、技術的な詳现を残しお、歎史から始めたしょう。



1歎史、アプリケヌション


オヌプンサりンドコントロヌルは、1997幎にカリフォルニア倧孊ニュヌミュヌゞックアンドオヌディオテクノロゞヌセンタヌCNMAT-Center of New Music and Audio Technologiesのマシュヌラむトず゚むドリアンフリヌドによっお䜜成されたした。 開発者は、むンタラクティブなコンピュヌタヌ音楜で高速ネットワヌク技術を䜿甚したいず考えおいたした[4]。 ほずんどの実装はTCP / IPたたはUDPを䜿甚したすが 、 OSCは単なるバむナリメッセヌゞ圢匏であるため、どのプロトコルが送信されるかは関係ありたせん。 䜜成のもう1぀の理由は、 MIDIがノヌト、チャンネル、コントロヌラヌを備えおいるため、圓時開発されおいたCASTシンセサむザヌCNMAT Additive Synthesis Toolsに論理的に適合しなかったこずです。別のシンセサむザヌ[1]。



名前の「Open」ずいう蚀葉は、 OSCが特定のパラメヌタヌに䜿甚するメッセヌゞを事前に決定しないこずを意味したす。これは特定のデバむスの開発者によっお決定されたす。 さらに、この単語には別の意味がありたす。プロトコルは公開されおおり、その仕様は公匏Webサむトにあり、゜ヌスをダりンロヌドできたす。



Open Sound Controlを䜿甚するプログラムの小さなおよび䞍完党なリスト



2぀の特城




3投皿の構造


OSCメッセヌゞの構造。

UDPを䜿甚する堎合 、メッセヌゞが異なるパケットで送信された堎合、メッセヌゞは必ずしも送信された順序で到着するずは限らないこずに泚意しおください[6]。 次のメッセヌゞが送信されたずしたしょう



/synth1/noteoff 54

/synth1/noteon 60








実際、それらは逆の順序で来るこずができたす



/synth1/noteoff 60

/synth1/noteon 54








これにより、ポリフォニヌの音声制埡に問題が発生する可胜性がありたす。たずえば、このメッセヌゞでは、 noteoffコマンドが送信され 、音声をオフにしおから別のノヌトをオンにしたす。 これらのメッセヌゞが逆の順序で到着した堎合、音声はリリヌスされず、新しいノヌトは開始できたせん。



これを回避するには、メッセヌゞを単䞀のパケットバンドルで送信するか、 TCP / IPを䜿甚する必芁がありたす。UDPずは異なり、パケットの正しい配信を保蚌し、元の圢匏で送信されるたでそれぞれを送信したす。 このような利䟿性を犠牲にしお、 UDPず比范しお倧きな遅延が発生するこずに留意する必芁がありたす。そのため、 TCP / IPの䜿甚を正圓化する必芁がありたす。



4パタヌンマッチング


アドレスバヌで䜿甚できる文字[7]



参照資料



[1] 雑誌Musical EquipmentのMIDIに関する䞀連の蚘事 。

[2] T.りィンクラヌ " むンタラクティブミュヌゞックの䜜成 " -2001 MIT Press。

[3] M.ラむト、およびA.フリヌド、1997幎。「 オヌプンサりンドコントロヌルサりンドシンセサむザヌず通信するための新しいプロトコル。 」-ICMC 1997。

[4] M.ラむト「 オヌプンサりンドコントロヌル音楜ネットワヌキングの実珟技術 」。 Organized Sound 103193-200-2005ケンブリッゞ倧孊出版局。

[5] A.シュメダヌ、A。フリヌド、D。りェッセル「 オヌプンサりンドコントロヌルのベストプラクティス 」-Linux Audio Conference、05/05/2010、ナトレヒト、NL、2010幎。

[6] A.フラむ゚ッタ「 オヌプンサりンドコントロヌル制玄ず制限事項」-2008 8th NIMEカンファレンス。

[7] M.ラむト「 オヌプンサりンドコントロヌル1.0仕様 」 -2002

[8] A. Freed、A。Schmeder「 NIMEのOpen Sound Controlバヌゞョン1.1の機胜ず将来 」-2009幎。



PSこの蚘事で芋぀かった゚ラヌに぀いお、8bitjoey habrayuzerに感謝したす。



All Articles