MIDIは世界中の電子楽器で共通して使われているプロトコルであり、MIDIに対応している電子楽器であれば、ユーザーインタフェースと音を完全に分離して制御できます。本稿で解説してきたように、アプリケーションからMIDIを制御することも可能ですし、MIDI通信の間にアプリケーションをかませることで演奏データの変換なども容易に実現できます。

しかし、MIDIは80年代に制定された古いプロトコルのため拡張性が乏しく、1度の通信で送受信できる情報量が制約され、拡張性に乏しいという問題があります。その結果、可変長のシステムエクスクルーシブメッセージに頼り切った拡張や、メーカー独自の音色マップでMIDIデバイスが作られ、GMという標準は作られているものの、事実上の標準は主要メーカーの機器に依存しています。

こうしたMIDIプロトコルやMIDIデバイスの問題は、アプリケーション開発にも大きな影響を与えます。システムエクスクルーシブメッセージやメーカーごとの音色マップの存在が、下位のプロトコルであるMIDIの抽象化を妨げています。アプリケーション開発者やクリエイターは、結局MIDIプロトコルの知識が一定の範囲で要求されます。本来であれば、こうしたプロトコルの存在は抽象化し、利用者からは隠蔽されるべきです。

ここ数年、グラフィックスを中心としたプレゼンテーション開発技術は、ハードウェア、ソフトウェアの両面で目覚ましい発展を遂げています。開発者は、デバイスを意識して開発する必要はありませんし、複雑な図形やアニメーションを開発する場合でも、難しいアルゴリズムを理解する必要はありません。低水準の処理はすべてフレームワークによって抽象化され、アプリケーション開発者は少ないコードで目的の処理を実現できます。多くの環境で、こうしたフレームワークが提供されています。

これに対して、サウンドプログラミングの世界は大きな発展が見られず、今もデバイスやプロトコルを意識したコードを書かなければなりません。これはMIDIに限らず、オーディオ形式でも同じことです。Microsoftの最新のアプリケーション実行環境である.NET Frameworkですら、サウンドに関しては簡単な再生機能しか提供していません。次世代技術を議論する場においても、ゲーム産業を除いて、サウンドに関連する積極的な発言を耳にしたことはありません。本稿で解説させていただいたように、比較的新しいフレームワークであるJava Sound APIですら、データの生成にはMIDI プロトコルの知識が必要であり、十分な抽象化は実現できていません。

現代のアプリケーション開発の場では、サウンドは非常に軽視されています。しかし、サウンドがユーザーエクスペリエンスに大きな貢献をしているのは明らかです。次世代のアプリケーション開発モデルに適応したサウンドプログラミング環境のためには、低水準の手続きを隠蔽し、目的を記述するだけで開発できる新しいフレームワークが求められます。

参考文献 社団法人音楽電子事業協会