Web拍手：
「第514回:DTMに新たな進化。複数Webブラウザで演奏/同期
〜Chromeで弾いて低遅延で連携する「WebMidiLink」とは? 〜」
http://av.watch.impress.co.jp/docs/series/dal/20120709_545742.html
http://d.hatena.ne.jp/aike/20120628
ここ↑の説明がわかりやすいですね．
http://www.g200kg.com/en/docs/webmidilink/spec.html
ただ，今一歩，よくわからない部分がある．
この話って，現状では，遅延がどうとかということはほとんど関係ないような気が... ．
いまやっていることは，雑な表現をしたら単なる「ローカル通信」のような気が... ．
時間情報がまったくないプロトコルのようにみえるのだけど，送受するメッセージをかなり絞り込んだので，実用的な伝達速度になる，という話なのだろうか？
これから，インターネット越しにいろいろ実験していきますー，という話なのだろうか？
（追記：今一度読みなおしてわかりました．藤本さんの記事のタイトルづけの問題（私の取り違い）で，WebMidiLink には低遅延を実現するための仕掛けは特にはなさそうです．ローカル通信なので，そもそも気にしなくても大丈夫，というところが肝のようです．ただ，この特徴は，たとえば，ハブをひとつかました程度のような短い LAN 内であれば十分に実用的な低遅延通信だと思います．）
よくわからないまま私の理解を（自分の思考の整理のために）書いていくと，
o たぶん，新しいところは，HTML5 の post.Message() に MIDI メッセージを載せた，というところ
o たぶん，新しいところは，受けた MIDI メッセージを HTML5 の Audio DATA API（Web Audio API）を使って音にした，というところ
o たぶん，仮定しているアプリは，ブラウザでアクセスしていればすでにローカルメモリ上にあるのでローカル通信となり，遅延もヨタりも考える必要がないくらい簡単に無視できるくらいに小さくなる，というところ
という話なのかなぁと思う．
たぶん，意義があるのは，「オレオレプロトコルでオレオレ実装」していなくて，「HTML5 で標準化されつつある（規定されつつある）仕様を使って，実装した」というところだろうと思う．
そうでないと，HTTP に MIDIメッセージを載せてアプリ間で演奏情報をやり取りするのって，かなり昔からやられていたような？（これ単体だと研究報告にさえならない．実装方法にチラリと書くだけ．）
SIGMUS 界隈がヘンタイ的だったということなのかな．
ローカルアプリ間通信を手軽にやろうとしたら，HTTP になる，という．
ローカル通信だと問題ないけれど，インターネットに載せると遅れたり（Delay），ヨタッたり（Jitter），順序入れ替わりが置きたり，消えてなくなったりするので，NTP の時刻情報っぽいものを付加したり，シーケンス番号を付加したりとかしましたねぇ．
それとも，WebMidiLink が工夫している「低遅延（低ヨタり）にするための何か」を私は読み損なっているのかなぁ？
そういえば，OSC（OpenSoundControl）も，なんだか巨大な重たいプロトコルになってしまって興味が薄れてしまった．
MIDI over HTTP も，最近は追いかけてないなぁ．
WebMidiLink のような軽くてわかりやすいプロトコルが，標準仕様に載って流れていくのはおもしろそうですね．
なんといっても，ランニングステータスによる省略を禁止するのは，非常にわかりやすいし，実装（デバッグ）しやすい．
私も何か作ってみようかなー．
何かネタを考えないとー．
個人的には，遅延（Delay）はそこそこ小さければ実用になるけれど，ヨタり（Jitter）はかんべんしてほしい．
