S.F. Page

Programming,Music,etc...

Web MIDI API のEditor's Draft (2014/2/13) を読むことにする

SC-88Proとレイ・ハラカミさん、nsx-39

そこそこきちんとST/GT方式のシーケンサーを作ろうと思い、Web MIDIを触り始めた。作ろうとしているのはもちろんポケミクをターゲットにしている。でもできれば汎用性も持たせたい。去年買ったSC-88 Proも使わないまんまなのでできればそれも使えるようにしたいなと。SC-88 ProはSTED2のテスト用が目的だけれども、レイ・ハラカミさんが愛用している機器であるとか、DTMのデファクトであるという点で持っておきたかったのもある。古い機器(1996年)だけれどもね。

レイ・ハラカミさんの曲は好きだなぁ。特に矢野顕子さんとのコラボしたやつが。音作りはすべてSC-88 Proで行っているという方であった。2011年にお亡くなりになってしまったが。

まあこの曲はあれだな。矢野顕子さんのピアノが入っているから純粋にはSC-88 Proのみというわけではないような気もするな。下の曲はそうだろうけれども。しかし私のへたくそカバーの後で聴くとクォリティの差が際立って鳥肌というか寒気がするほどだ。。

いい音なんだけどくぐもった感じがするのがこの時代のDTM音源のクォリティだと思う。メモリ・リソースが少ないからなんらかのデータ圧縮処理が施されているので。ハードウェア・リソースと機能(表現力)の妥協が「味」となっているのが面白い。たとえばTR-909なんかもそうだ。6Bitサンプリングでなければあのハイハットの音は出なかったと思う。高いレベルで妥協すると思わぬ副産物が生まれる例かもしれない。ローランドの昔の機器は皆そうだった。あんまり追っかけてないけども現在もそうなのだろうか。

NSX-39とSC88-Proを比較すると、以下のようになる。

SC-88 ProポケミクNSX-39
発売年19962014
価格99,800.-5,380.-
音色1117/ドラムセット42128/ドラムセット1
音色エディットパラメータビブラート/フィルター(LPF)カットオフ周波数・レゾナンス/エンベロープ Attack・Decay・Releaseビブラート/フィルター(LPF)カットオフ周波数・レゾナンス/エンベロープ Attack・Decay・Release
ユーザー音色256/ドラムセット2なし
CH/同時発音32/6415/64
歌声なしあり(1)
エフェクトインサーション64/リバーブ8/コーラス8/ディレイ/10/2EQリバーブ29/コーラス24/インサーション181/マスターEQ(5バンド)
インターフェースシリアル/MIDI/音声入出力/ヘッドフォンUSB/ヘッドフォン

当然差はある。しかし価格差を考えるとポケミクはちょっとしたDTMを行うのに十分なスペックを有しているのではないだろうか。18年前だったら数万円くらいしたかもね。でも今のDAWで作りだされるアマチュアレベルの音楽には到底及ばないけれどもね。18年前と今とは違うのだ。10万出せばすごいことができる。才能があればの話だけども。

Web MIDI API

それはさておき、WebMIDI APIは2014/2/13のEditor's Draftが最新らしい。Editor's Draftというのは「仕様策定者 (Editor) 間で同意が取れている状態のドラフトで、公式に他者にレビューを求めるドラフト。Working Draft を出すには時間がかかる場合、このドラフトが最新の仕様として各ブラウザベンダに参照されるという位置づけ」(Syoichi's Tumblr)だそうである。おそらくこれがレビューされて修正され、Working Draftとなるのだろう。ではWorking Draftというのはなんぞやというとこれは「草案」というレベルで、これもまたレビューにより修正される可能性があるものである。W3Cの決められる規格は正式には「勧告(Recommendation)」で確定される。さらに草案から勧告までに至るまでには「http://www.kanzaki.com/w3c/process.html」に依れば、下記のステップがある。

草案(Working Draft)

標準情報はまず草案(Working Draft: WD)をワーキンググループ(WG)が起草し、ディレクタの承認を受けて公開される。標準情報(TR)はWGの議長が指名したエディタ(1名もしくは複数)によって作成される。

ドラフトは、3か月以内に更新していくというルールが定められている。

TRが次の段階に進むには、一般に次の条件を満たす必要がある。

  • 次の段階に進む要求提出の、WGとしての意思決定を記録する
  • 前段階からの文書の変更点を分かりやすく明記する
  • さらに要件、依存関係に変更があればそれも示す
  • 広く意見を募った証を示す
  • 前のステップ以降に寄せられた全ての案件への対応を公式に示す
  • 公式な反対意見があれば示す
最終草案(Last Call Working Draft)

草案がWGの規定および関連要求仕様を満たし、ほかのWGの仕様との主要な依存関係をクリアし、レビューで報告された疑問点への対応を明確にすると最終草案(Last Call Working Draft: LC)となる。

LCは3週間以上の期間を設けて他のWGやW3Cメンバーからのレビューを受け、要件を満たすと勧告候補(CR)に進む。

ディレクタの承認により、直接勧告案(PR)に進むこともある。いずれの段階にも進まない場合は草案に差し戻される。

勧告候補(Candidate Recommendation)

LCが要件を満たすとディレクタは諮問委員会(Advisory Committee)に実装を試みる依頼(Call for Implementations)をアナウンスし文書は勧告候補(Candidate Recommendation: CR)に進む。

この期間に実装できないと仕様から削除する可能性がある箇所は、features at riskと指定される。

実装試行期間が終了すると、features at riskのうち問題が確認された箇所は仕様から削除される。大きな変更が行われる場合あるいはディレクタが重要な問題があると認めた場合、文書はWDに差し戻される。CRが下記の要件も満たせばCRは勧告案(PR)となる。

  • 次段階移行の一般要件を満たしている
  • 仕様の各機能について実装が(望ましくは2つ以上)存在する、もしくはディレクタが実装不十分でもPRに進めるべきと判断する
  • CR以前の段階で示された他の条件を満たしている
勧告案(Proposed Recommendation)

CRが要件を満たすとディレクタは諮問委員会に評価依頼(Call for Review)をアナウンスし、文書は勧告案(Proposed Recommendation: PR)となる。

ディレクタは勧告案を諮問委員会にレビューを求める。レビュー期間は最低4週間おかれる。問題なければ勧告となるが実装に関する問題があればCRに、場合によってはWDに、差し戻される。

W3C勧告(Recommendation)

仕様が諮問委員会、W3Cチーム、ワーキンググループおよびW3C外部を含めて十分な支持を得られたとディレクタが判断すると、標準情報はW3C勧告(Recommendation: REC)となる。

W3C勧告は内容確定した文書であり、他の技術文書から正式な引用規格として参照することができる。

というわけで勧告となるまでにはまだまだ長い道のりがあり、規格も大なり小なり変更される可能性がある。WebMIDI APIはTRはまだ2013/11のままであり、3か月ルールからすると2月に更新されるはずだがまだ更新されていないようである。おそらくは2/13のEditor's Draftが次のTRとなるのであろう。規格の勧告となるまでのステップを見ると実装されるのは勧告候補のレベルに達したときのようだが、実際は各ブラウザベンダが先行してTRもしくはEditor's Draftレベルで実装してしまうようである。ChromeでいうとデフォルトでOffになっている機能がたいていそうなのだろうね。ちなみにWeb Audio APIもまだTRのレベルで、勧告となるにはまだ紆余曲折があるのだと思う。Web Audio APIは私も少し前にゲームのBGM/SE用にいろいろいじっていたけれども、気が付くと規格が変わり動かなくなっている可能性はある。

というわけでまだまだ固まるまで長い道のりのWebMIDI APIであるがTR版と、最新版のEditor's Draftを読んで押さえておこうと思う。Chromeで実装されているWeb MIDIのバージョンはおそらく2013/11のTR版ではないかと思われる。