ブログを引っ越したのでいろいろ下書きのままStackEditの肥やしになっていた文章の中から「はてなブログに出すのはないな…」と放置していた草稿の類を整理して出しておこうと思う。
今回は「設立趣意書」という題だけど、オーディオプラグイン研究所のものにするか、Audio Plugins For Android用にサイトをちゃんと作ってその組織のものにするか迷って、結局、肝心の「主語」を付けていなかったものだ。
2022年に書いたものだからある程度時代性があるのだけど（たとえばVST3は今やMITライセンスに変わっているし、自分は今やSMF2 Container Formatの先を想定している）、行動原理の大筋は今でもだいたい同じなので、そのまま出すことにする。
音楽制作は、特定のプラットフォームから離れて、特にプロプラエタリなプラットフォームから離れて平等に実現可能であるべきだし、制作された楽曲は、誰に対しても参照・応用・発展に開かれた生成的なかたちで流通する可能性があるべきだ。現状はそうはなっていないので、現状を変えるべきだ。
対象となる未解決課題
プラットフォーム間で平等なオーディオプラグインエコシステムの実現
ここではDAWやオーディオプラグインを利用した音楽制作に焦点を当てる。
Linuxプラットフォームでは利用可能な製品がWindowsやMacと比べて少ない。これはOSSの世界ですらそうであった。今やVST3はGPLv3で公開されており、LV2も複数の商用製品でサポートされて普及期を迎えつつあり、クロスプラットフォーム・マルチプラグインのJUCEなどがLinux用プラグインのビルドと利用の機会を拡大している。それでも、まだ商用製品はWindowsとMacのみで販売されているケースが非常に多い。ChromeOSが普及しつつあるが、Linuxデスクトップとしては開発環境としてしか存在せず、オーディオ・MIDIデバイスのサポートが弱く、Linuxネイティブプラットフォーム用音楽制作環境としての選択肢としては適切ではない。
Android（あるいは、より幅広く「Android互換の」）プラットフォームで利用可能な音楽ソフトもiOSと比べて少ない。Androidはかつてはオーディオ遅延の問題が厳しかったが、2020年代のAndroid上位機種ではもはや問題ではないし、普及機でそこまでリアルタイム性に期待を持つ理由はない。iOSでも分離プロセスで動いているAudioUnit v3に過剰な期待を持つことは通常はない。むしろ基本的にJVM言語とC/C++を相互運用することになるAndroidプラットフォームで開発したくないというエクスキューズの側面が強いだろう。そして何より、Androidで利用できるオーディオプラグイン規格が存在しない。AUv2からプロセス分離環境でも利用可能な機能を取り出して実現したAUv3のようなものが、Androidにも必要だ。
Webプラットフォームでは、デスクトップのようなプラグイン製品のエコシステムがほぼ存在しない。特定のWebサイトにアドオンを提供している製作者はいるかもしれないが、音楽制作で使えるためには、オーディオプラグインの膨大なデータをWeb越しにシームレスに利用できなければならず、現状では課題が多い。Webサイトがシャットダウンしたら楽曲の全てが失われてしまうのも困る。一方でWebほどプラットフォーム間の差別を解消した環境はなく、利用できる特性は利用できるようにしたい。
生成的かつ現実的な楽曲データの流通
2022年現在、生成的な音楽データはほぼ流通していない。レンダリングされて既に生成的でないMP3, FLAC, AACなどが流通している。DAWが保存するデータ形式は全てプロプラエタリで、楽曲データとして利用される共通フォーマットは、結局SMFにまで遡ることになるが、SMFでは表現できるデータの表現幅も小さく（0-127がほとんど）、表現の拡張性も低い。世界にはもう少し実用的な楽曲データのフォーマットが必要である。かつてHTMLを用いた生成的なWebの世界が、ブラウザによる差異の少ない、かつ特定のブラウザに独占されないコンテンツの集合体を構築していったように、音楽データも生成的なかたちで普及することに意義がある。
この方面では、2020年にMIDI 2.0仕様が確定し、32ビットのデータ幅をもつ命令を中心とするUMPが利用可能になったが、SMFに相当する仕様は現在でもMMAからリリースされていない。複数のオーディオプラグイン規格を包括的に対象とできる識別子体系なども無く、MIDI 2.0 Profile Configurationなどがこの状況を打破できる様子も具体的な道筋もまだ無い。
開発目標
Androidプラットフォーム向けオーディオプラグイン機構の実現
未解決課題の項で言及したとおり、Androidにはオーディオプラグイン機構が存在しない。これはモバイルプラットフォームなので困難ということがあるが、リアルタイム性の実現などにプラットフォーム上の限界はあるものの、ある程度は実現可能であるはずなので、まずは形になるものを構築し、それからプラットフォーム基盤（AOSP）の改善の機会を狙う方向性で開発を進める。
ここで重要なのは、数多くのサポート製品を作り出すことにある。DAWを増やすのは難しい課題だが、利用可能なオーディオプラグインをMIDIデバイスとしてリリースするなど、プラグインを増やす方策はある程度具体的に考えられる。
一方で、特定のプラグインベンダー、特定の開発ツールに接近しすぎるのはオープンな規格のあり方として望ましくない。対象プラットフォームもAndroid「AOSP互換」プラットフォームとし、Google Android固有のものとすることを避ける（ただ、技術基盤となるAndroid Binderまで利用できないようなプラットフォームまでカバーする必要はない）。
MIDI 2.0の実装とデータ形式への採用
生成的な（再利用性のある）楽曲データが普及しない理由は、つまるところ標準に準拠したデータが流通しないことにある。この意味では、MIDI 2.0をプラグイン仕様の中に組み込む、ツールのエクスポートデータ形式として採用するなど、いくつかのアプローチによって、プロプラエタリなフォーマットでは為しえなかったデータの流通（アップロード、ダウンロード、共有など）に繋げていくことが有効と考えられる。標準に基づいて実装されたものは、相対的に移植性も高い。