新刊のお知らせ(MIDI 2.0 UMPガイドブック)ほか

(8月の作業記録のつもりでまとめ始めたのですが思いのほかMIDI 2.0祭りになってしまったので新刊告知エントリとして生まれ変わりました…!)

MIDI 2.0 UMPガイドブック @ 技術書典9 / M3 2020秋

技術書典9にはサークルとして復活します! 何しろ当日スタッフとして動き回る会場がないからな…!

今回なんと新刊が2冊も出ます。1冊は(改めてエントリを書きますが)7月にはほぼ書き終えていたLV2開発者ガイドです。もう1冊は前回ちらっと言及しましたが、MIDI 2.0に関する本です…!

techbookfest.org

MIDI 2.0 UMPガイドブック」は、2020年2月に正式に公開されたMIDI 2.0仕様のうち、もっとも目を引く内容であるMIDI 2.0 UMP(ユニバーサルMIDIパケット)仕様を中心に、MIDI 2.0をサポートするデバイスやソフトウェアが提供する、あるいは実装する必要がある機能について解説する書籍です。

UMPが何なのかというと、一連のMIDI 2.0関連仕様の中で、MIDI 1.0のときに80hはノートオフ、90hはノートオン、B0はCC、F0〜F7はシステムエクスクルーシブ…といったメッセージを規定していた部分に相当する部分です。「MIDI 2.0で拡張・強化された機能」というと伝わるでしょうか。

本書は、MIDI 2.0というキーワードに関心のあるMIDIのユーザーと開発者のどちらもターゲットとしていますが、MIDI 2.0をサポートするソフトウェアは2020年8月の本書執筆時点で皆無に近いので、本書を実用できる読者はどちらかといえば開発者が多いでしょう。これまでは、MIDI 2.0について詳しく知ろうと思ったら、AMEIまたはMMAで公開されている英語の仕様書の原典にあたるしかありませんでした。本書がその状況を少し切り拓くことになればと思っています。

本書のデジタル版は2020年9月13日からオンラインで開催される技術書典9で、ペーパー版は同イベントでのオンライン販売および2020年10月25日のM3 2020秋にて販売します。サンプルページ等は技術書典9のサイトで書籍データが公開されるようになったら出てくる予定です。

なお、同イベントでは、新刊として並行して執筆した「LV2オーディオプラグイン開発者ガイド」も同時にリリースする予定です。(というか、この本自体はライブラリ開発のついでに書き始めて、LV2開発者ガイドの販促用オマケにするつもりだったのが、なぜか単独で完成してしまったやつだったり…)

本書がどのくらい有用かというと、筆者がこの執筆後に開発に着手した自作のオーディオプラグインフレームワークにLV2を統合する過程でMIDI 2.0をサポートするためのLV2拡張機能MIDI 2.0サポートのCライブラリを自作しているときに、ほとんどの場面で仕様書ではなく本書の内容だけで疑問を解決出来ているレベルです(MIDI 1.0の仕様に該当する部分は基本的に省略しています)。

lv2-midi2

MIDI 2.0 UMPまわりを調べていたのはただの趣味ではなく…いや、趣味の延長ではあるのですが…LV2拡張としてMIDI 2.0をサポートして、これを自作オーディオプラグインフレームワークMIDIメッセージング基盤として使いたいと思ったからでした。

MIDI 2.0サポートを追加するのに必要なフレームワークへの変更は(驚くべきことに)ほぼ皆無で、プラグインが任意のポートの内容種別にMIDI 2.0ストリームであることを指定するだけで足り(現状ここがホスト側ではenumになっているのですが、もしかしたらLV2みたいにURI(D)にしたほうがいいのかも)、ホストがポート情報を取得してMIDI 2.0ポートであればvoid*のバッファにUMPバッファを流すだけなのですが、実際にそれらを処理するLV2とJUCEのブリッジでは実装が必要になります。

というわけで、まずLV2サポートを作っています。LV2にはもちろん標準でMIDI 1.0のサポートがあるのですが、MIDI 2.0のUMPは(上記書籍でも解説しているのですが)MIDI 1.0とは根本的に構造が違うので、ざっくりとLV2拡張のかたちが似ているだけです。

github.com

あと多分MIDI入力ポートが複数並立しているとややこしくなるので(LV2では基本的にすべてのポートがconnect_port()で繋がっていないといけない/複数ポートで競合するようなストリームの処理が未定義動作にならざるを得ない)、UMP対応プラグインでは基本的にポートは1つ、内容種別はextension_data()でホストとの合意に基づいて決定する、というMIDI-CI的なやり方にしました。(MIDI 2.0ではMIDI 1.0プロトコルMIDI 2.0プロトコルを排他的に選択し、MIDI 1.0のメッセージはMIDI 2.0プロトコルでは送信できないようになっています。逆も同様。)

現時点では自作プラグインフレームワークのほうでMIDI 1.0サポートを切り捨てておらず、MIDI 1.0のストリームがMIDI 2.0前提のプラグインに流れ込んでくることが想定されるので、バイトストリームをUMPに変換する作業が必要になります。むしろ一般的にはプラグインがUMPをサポートしていないためUMPをMIDI 1.0のストリームに変換して送信する処理が必要になります。これは実装したのですがまだUMPを送ってくるホストは無い状態です(まあホストも自作しているというか自分のフレームワークではホストはAndroidサービスの受け口なのですぐ作れるわけですが)。

JUCEのほうはLV2が出来たら着手しようかなと思っていますが、そもそも今コーディング作業を勧めているべき段階ではないはずなので(!)、M3 2020秋が終わる10月末までは着手も未定です。上記書籍の肥やしにはもうならなくなっていますし。

cmidi2: allocation-free, header-only MIDI 2.0 UMP library

LV2でUMPサポートを実装するためには、当然UMPを操作するためのライブラリが必要になります。しかし、8月時点では何一つ発見できませんでした。Xcode 12にCoreMIDIでUMPをサポートするAPIがいくつか生えましたが、こっちとしては当然ながらどのプラットフォームでも使える必要がありますし、それは現時点でも皆無です。

lv2-midi2サポートを実装するにあたっては、LV2 AtomのようなAPIが必要になります。LV2はVST3SDKなどとは異なり軽量なheader onlyなCライブラリの集合体で、LV2 AtomAPIもすべての関数がstatic inlineで定義されています。LV2 Atomはオーディオ処理の中で解析・生成されるので、当然ながらメモリアロケーションも許されません。すべて事前に用意されたバッファで処理します。

そういうわけで、まずはLV2 Atomと同様の構成でUMPを操作するためのライブラリを作りました。それがcmidi2です。

github.com

UMPはuint32_tuint64_tuint128_t…という標準型は存在しないのでまあuint64_t * 2ですね*1…で表現できるので、自然とアロケーションフリーで扱いやすい構造です。単なるバッファ処理でしかないので自然とクロスプラットフォームです*2。基本1日で作ったやつですし(ちょくちょく手を加えているので今は500行を超えちゃいましたが)。

名前はさすがにシンプルにmidi-2.0とするわけにもいかないので雑にCを付けました…。おそらく類似のMIDI 2.0 APIを既存のktmidiにも生やすことになると思います。managed-midiには…MicrosoftLinuxデスクトップ開発者をきちんとリスペクトしてLinux向けにVS for Linuxを出すなりかつて存在したMonoDevelopなどをまた使えるようにしたら、やるかもしれません。

lv2-midi2のために作ったライブラリですが、汎用的に使えるはずなので、MIDI 2.0に興味のあるCプログラマーは取り込んでみてください。なおheader onlyなのでCライブラリであってもdlopen()・dlsym()を前提とするFFIにはほぼ向いていません。

ayumi-lv2

7月に作っていたPSG音源AY-3-8910のエミュレーターayumiをLV2で使うためのプラグインayumi-lv2ですが、まともに発音出来るようにMIDIメッセージからのAPI呼び出しを調整できたので、最大3音ですが音が出るようになっています。

本当はこれをlv2vst経由でVST2をサポートしているDAW(Tracktionなど)から使いたいのですが、手元の環境でlv2vstがクラッシュするようになっていてまだ試せていません。調べるよりJUCEプラグインとして作り直したほうが早そう…しかし今やり始めるとまずい…!

ayumi自体はもとのハードウェアのレジスタ類をエミュレートしている音源であって、MIDIノートではなく周波数を設定するかたちになっているので、MIDI 2.0におけるpitch 7.9(前回書いたやつ)も問題なく計算して渡せるでしょう。ホスト側が調整できたらこの辺から動作確認も含めてサンプルとして作り込んでみようと思っています。(しかし今やり始めるとry)

*1:calccrypto/uint128_tなどを使う手もありますがこれはheader onlyではないので…

*2:特定のendiannessにも依存しないようになっているはず…

MIDI 2.0 UMPにおけるノートオン命令について

正式なリリースについてはまだ白紙状態なのですが、いまMIDI 2.0 UMP (Universal MIDI Packet、雑にいえば新しいMIDIメッセージのフォーマット)に関する調べ物をしていたらだんだん同人誌化できそうな感じになってきたので、そのうちまとめて出そうと思っています。既に技術書典9およびM3 2020秋でのリリースを公開しているLV2開発者ガイドと併せて楽しめる読み物にできればと思っています。

とはいえWebにも調査内容をフツーに公開したいので、どんな内容の本になるかという紹介も兼ねて、昨日まとめていたノートオン・ノートオフ命令に関する説明の部分をまるっと公開します。まだドラフトなので最終版は変わるかもしれません。図も今回は仕様書のコピペです。そもそもUMPとは何なのか、MIDI 2.0とは何なのか、みたいな話が無いので読みにくいかもしれませんがそこはご容赦あれ…


ノートオン・ノートオフ命令は、MIDI 1.0のものから何点か機能追加されています。まずはメッセージ構造を見てみましょう。

f:id:atsushieno:20200824151743p:plain
MIDI 2.0ノートオンメッセージのパケット(UMP仕様書より)

note numberの次にattribute typeという見慣れないフィールドがあります。その次はvelocityですが、これはMIDI 1.0の7ビットから16ビットに拡大されています。そして残り16ビットにattribute dataというフィールドが追加されています。

ノートの属性

MIDI 2.0のノート命令で新しいのがこの属性(attribute)です。ノートオン・ノートオフの時点でそのノートにひとつプロパティ値のようなものを指定できます。属性の種類は現時点での仕様では次の3種類のみです。

属性種別 定義
0 なし 値も0が想定されています
1 製造者固有 バイスの製造者(Manufacturer)が意味を定義します
2 プロファイル固有 MIDI-CIプロファイルの策定者が意味を定義します
3 Pitch 7.9 1セント未満の微分音を設定します

製造者固有あるいはプロファイル固有の情報として使うと、いわゆるアーティキュレーションの機能を実現できます。その具体的な効果はMIDIバイスのプログラム(音色)しだいです。MIDI-CIプロファイルは現在具体的な仕様が何一つ存在しないので、現状では無視してよいでしょう。

ピッチ補正

Pitch 7.9というのは、アーティキュレーションとは全く異なる用途になります。これは1セントすなわちMIDIノートの値でいえば1.0(半音階)より小さい値を固定小数点で指定するものです。7.9というのは、整数部分を7ビット、小数部分を9ビットで表現する型であることを意味しています。

MIDI 1.0の時代でも、ピッチ補正を設定できるMIDI音源は存在しました。MMAもMTS(MIDI Tuning Standard)と呼ばれる仕様を策定しており、このシステムエクスクルーシブメッセージを使うとノート別のチューニングを変更できました。

またノート別RPNの3番にはPitch 7.25というより固定小数点精度の高いデータを設定できます。

そして、MIDI 1.0の時代からあるピッチベンドも存在します。ピッチベンドの値の効果は、RPNの0番で規定されているピッチベンド・センシティビティ(感度)の値によって、2セントから24セントまで変わります。MIDI 2.0ではピッチベンドもノート別に指定できるようになっています。

最後に、MIDI 1.0の頃から、RPNの1番と2番にはマスターチューニングというパラメーターが存在します。すべてのノートオンに適用されるピッチ補正です。

ノートのピッチを決定するのに、一体いくつの変数を考慮しなければならないのでしょうか?? MIDI 2.0仕様では、次の任意の組み合わせによって決まる、という説明を加えています。

  • MIDI 1.0と同様のデフォルトピッチ: ノートオンのノート番号
  • ノートオンに継続的に適用されるピッチ補正: MTS, ノート別RPNの3番
  • ノートオンに1度だけ適用されるピッチ補正: ノートオンのPitch 7.9
  • 以上に対して追加で加えられるピッチ補正: マスターチューニング、ノート別ピッチベンド、(チャンネルの)ピッチベンド

もし読者にサンプラーなどを実装する機会があったら、どこかに実装の抜け落ちている部分がないか確認してみましょう。

また、ユーザー(クリエイター)の視点で考えると、これらには他にも利用上の特性の違いがあることがわかります。たとえばPitch 7.9でノートとピッチを指定できるのはノートオンのタイミングのみです。そのノートに対して後からピッチ補正をかけたい場合はノート別ピッチベンド(あるいはピッチベンド)を使うしかありません。

MTSとPitch 7.9の具体的な用途・使い分け

属性種別3を選択した場合、実際に発音される音階はPtch 7.9の7ビット整数部分が示すことになります。このメッセージのnote部分にはそれでは何の意味が残るのかというと、ノートオフやノート別コントロールの対象を示すインデックスとして機能します。そうしないと、同じノート番号で別のPitch 7.9で発音したり、別のノート番号から同じPitch 7.9で消音したりといった謎の状態が生じて混乱することになるでしょう。

そもそもなぜPitch 7.9のような整数値を含むノート構造が必要になるのでしょうか? ファインチューニングしたいだけであれば、小数だけで足りるはずではないでしょうか? …その答えは微分音という音楽表現にあります。

一般的な微分音について説明する前に、もう少し簡単な用例を紹介します。それは純正律と呼ばれるチューニング標準です。

われわれが学校教育等で教わる一般的な音楽理論は12平均律と呼ばれる音階・周波数の配置に基づいています。12平均律の配置は、さまざまなコード(和音)を一定の美しさで聴くことが出来るように最適化された配置です(和音の響きの美しさは各音階がどれだけ離れているか、きれいな比率で倍数になっているか、といった要因で決まります)。

実は、かつては*1純正律と呼ばれる周波数配置に基づいて12音階が定められていました。枝葉末節になるので定義はここでは省略しますが、これは主音が固定された和音を鳴らすとより美しく響き、転調すると美しくないとされています。

作曲家によっては、この純正律をあえて好んで使うので、せっかく機械的に周波数を補正できるのであればそう出来るようにすべき、と考えるのは自然なことでしょう。これがMTSの存在する理由の一つです。もっとも、純正律をサポートするだけであれば、チューニングに整数部分は必要ありません。1セント未満の小さな単位で周波数が補正できれば十分であるはずです。

さて、世の中にはさらに変わった音楽を求めて、12平均律ではないオクターブの分割を探求する人たちがいます。そこでは1オクターブを24分割したり、31分割したり、53分割したりといった実験が行われます。これが微分音(microtonal)といわれるものです。この微分音をDAWMIDIの(互換の)データに基づいて表現しようと思うと、チューニングが小数だけでは足りないのです。1オクターブが24ノートによって成立するとしたら、12ノート目は半オクターブ分しか進んでいないのです。

微分音クリエイターは、表現できるノートの音域を犠牲にしてノートに周波数を割り当てます。この時に使われるのがMTSでした。また、周波数マッピングを任意の数値で可能にするために、Scalaと呼ばれるデータを用いることがあります*2

MIDI 1.0でもMTSで微分音作曲ができていたのであれば、Pitch 7.9は微分音作曲に有意な機能追加となるのでしょうか? その答えは、ピッチ補正は必ずしもコード理論に基づいてノートに対して固定された周波数を適用しなくても使いたい場合がありうる、ということです。MTSやノート別RPNを前提にすると、楽曲の特定箇所の特定のノートだけワンタイムで少しピッチを上下させたい、といった入力は面倒になります。ノート別ピッチを適用することも可能ですが、ピッチベンドは別の目的で使っている可能性もあります。ノートオンに付随して調整できるほうが自然に打ち込めるのです。

アーティキュレーションとノート別コントローラー・NRPNの使い分け

独自の音源ソフトウェアなどを開発している読者であれば、Pitch 7.9ではなく独自のアーティキュレーションとして、何かしらのパラメーターをサポートしたいと読者は考えるかもしれません。しかしひとつ注意してもらいたいのは、属性の値はノートオンのタイミングでしか指定できないということです。現在のMIDI 2.0 UMP仕様では、いったんノートオンを送信した後でそのアーティキュレーションを変更することはできません。

もしパラメーターがノートオンの後でも変更できるようなものにしたい場合は、ノートオンの属性ではなく、ノート別コントローラーやノート別NRPNを活用するとよいでしょう。たとえば歌唱合成ソフトウェアでブレシネス(息の強さ)やオープンネス(口の開き方)などはしばしばアーティキュレーションの類型として説明されますが、もしMIDI 2.0のパラメーターとして実装するのであれば*3、機能によってはノート別コントローラーにしておくほうが無難かもしれません。

ノート別アーティキュレーションはたかだか1つしか指定できない点も注意すべきでしょう。ノート別コントローラーであればいくつでも指定可能です。

ベロシティ0の扱い

MIDI 1.0では、ノートオフメッセージをベロシティ0のノートオンメッセージで代替することが仕様上認められていました。これはMIDI 2.0のノートオンではもはや認められていません。MIDI 2.0でベロシティ0のノートオンメッセージをMIDI 1.0に変換する場合は、ベロシティを1にすべきである、と仕様上明記されています。

逆にMIDI 1.0のノートオンメッセージでベロシティ0のものをMIDI 2.0メッセージに変換する場合については明記されていません。これはノートオフメッセージとして変換することが意図されているのかどうか、対象デバイスを限定しているかどうか等の各種状況に依存するからであろうと筆者は考えています。

MIDIメッセージをサポートするオーディオプラグイン規格によっては、このMIDI 2.0の制約を先んじて規定していたものがあります。Linuxデスクトップで使われているLV2仕様などがそうです。

*1:Wikipediaの記述では、純正律の期限は2世紀に遡るとなっています。平均律は16〜17世紀です。

*2:プログラミング言語Scalaとは全くの別物です。

*3:ここではリアルタイムで歌唱合成できる世界に住んでいると仮定します。

7月の作業記録

ひさしぶりに半ば自分用メモであるところの作業記録を書くわけですが、ここ1ヶ月強の成果を振り返ると、びっくりするくらい何もない…! どうしてこうなった…?と冷静に振り返ってみると、(6月にも書いたのですが)自分のメイン開発マシンであったところのHP Spectre x360のキーボードとタッチパッドが使えなくなる故障がひどくて、先月修理から返ってきてから今度は4回目の修理に出しています。修理から返ってくると正常動作するのに、1週間かそこらでまたすぐ反応しなくなる…の繰り返しで、これが半年弱前からずっと続いているせいで生産性ガタ落ちだったわけですね。(最初の頃はFF7Rとかいろいろゲームで時間をつぶししていたのですが、さすがに飽きました…)

MSI Prestige 15に乗り換え

そんなわけで、さすがにこれ以上泥沼の状態でHP製品を使い続けるのは無理…ということで、否応なく新しいPC環境にしました。今はノートPCだけ持ってふらふら旅に出ながら作業する状況にもならないので、多少重くてもいいだろうと思ってMSIのゲーミング…とはいえなさそうな15.6インチノートPCです。

それでWindowsパーティションは極小化して(完全に消すとメインマシン引退した後でWindowsマシンにするときに入れ直しが面倒なので残します)、Ubuntu 20.04を入れて使っているのですが、今のところトラブルとは完全に無縁で、こんなに安定しているのか…となっています。ただ海外のフォーラムでは指紋認証が使えないみたいな報告もあったので、自分が使っていなくてハマっていないだけ、という可能性はあります。

HP Spectreで使っていたときはOSのアップグレードまわりでおかしくなっていたのか、jackdが使えなくなっていたのですが、MSI環境の方では問題なく動いています。この辺はLinux kernel 5.40.xあたりでいろいろ変更が加えられている部分で、ちょいちょいリグレッションが修正されたりしていたので(わたしもバグレポートしていたのでlaunchpadから「おれもおれも」みたいなコメントをちょいちょい受け取りました)、どうしても困ったらクリーンインストールすると解決する問題かもしれません。

せっかくニューマシンしかも重量級(?)のやつに乗り換えるというので、32GB RAMにしたので、Android Studio 4.2 Canaryのインスタンスが3つくらい立ち上がっても問題なく動作しています。これはMacでは生じない問題なのですが、LinuxではAndroid Studioインスタンスを複数起動できるので(クライアント/サービスの開発ではそのほうが嬉しい)、その分メモリ消費も大きくて困っていました。

一方でタッチスクリーンでなくなったのは、明らかにAndroid UIのテスト体験体験が悪化しているので、本当に改善したくなったらAirBarでも付けてみようかな…とか考えています。あとhome/endが無い(fn必須の)キーボードのレイアウトが完全に好みではないのもしんどいですね(これはHPがベストだと思っている)。とはいえPageUp/PageDownが独立しているだけ他の数多のベンダーよりはずっと良いです。あとバッテリーが弱くなって重量も1.3倍くらいになったのですが(これはHP Spectreが良すぎたという話もある)、冒頭にも書いたとおり持ち歩く機会も減っていますしね。次に買い換える頃にはコロナも収束していてほしいところです(フラグ…?)。

COSCUP 2020のセッション

8/2にリモートでやってきました。スライドはspeakerdeckにおいてあります。

speakerdeck.com

上記のようにメイン作業環境が破滅的な状況だったので、音楽作業用のMacでも最低限の開発ができるようにコードを整理しつつ、リモートセッションが可能になるように環境を構築したりしていました。blackholeでオーディオルーティングしたり、OBS Virtual Cameraをセットアップしたり…(ちょうどこれが可能になった頃に始めたのでラッキーでした)。

配信のやり方がわかってきたので、そのうちオンライン勉強会を開催しても良いかもしれないですね。

スライドの準備とマシントラブルへの対応のせいで、開発そのものはすっかり停滞してしまいました。(Macでできるのはせいぜい既存コードのメンテナンス程度だったので…)

「LV2オーディオプラグイン開発者ガイド」限定公開と査読のおねがい

6月くらいからちょいちょい作業を始めていたのですが、M3 2020秋とたぶん技術書典9に新刊を出すことにしました(技術書典9は参加未確定なので予定)。先日80ページくらいの初稿をすべて書き終えたところです。わたしは締切がなくても執筆作業を始められる人種なんだ…(!)

内容はLinuxデスクトップで普及している(と今なら言えそうな)Lv2オーディオプラグインに関する包括的な開発本です。開発本ですが、たぶん誰もがLV2の「使い方」のレベルで躓くと思うので、そこからケアしています。最新のオーディオプラグイン開発のトレンドなども言及しつつ(たとえばリアルタイムマルチスレッディングの話題とか)、公式のLV2 Bookよりは読み物っぽく書いているところがあります。あと公式のリファレンスは書いてる人も認めているくらい読みにくいので、この本くらいの粒度の解説本が有用だと思っています。

個人的には仕様書をじっくり眺めているうちに不備を見つけてLV2仕様にコントリビュートするというところまでは読んだので、一応それなりにきちんと掘り下げたと思っています(…!?)

これは毎回悩むところなのですが、今回もリポジトリを全部公開にするかどうかしばらく考えました。LV2は情報源が少ないので(情報源の多い原稿をかいたことがあっただろうか…?)、公開しておいたほうが世のためだという気持ちはあるのですが、今回はいちおう紙版を印刷して同人印刷所に生き延びてほしいという気持ちがあるので、昨年のシーケンサーエンジン本と同様、紙版が捌けて一定期間を経るまでは公開しない従来型のモデルで頒布することにしました。サンプル章のフリー公開などである程度公共に資することにしようと思います。

ただ、一方で事前に興味のある人に(もしいたら)読んでもらって何かおかしいことなどがあったら紙に刷る前に指摘をいただいたほうが生産的なので、今は期間限定で公開してあります。もし何かヘンだなと思うようなことがあったらぜひgithub issueで教えてください。9月には非公開に戻すと思いますが、参加いただいた方には引き続きアクセスしていただけるようにします。

https://github.com/atsushieno/lv2-developers-guide/github.com

ちなみにシーケンサーエンジン本はごくたまにTwitterとかに出すたびに数冊売れるので(宣伝だらけになると自分でもうざいのでかなり絞っています)、紙版はそのうちなくなると思います…なくなるといいなあ。

xamaritans.booth.pm

OPNplug(JUCE)とayumi(-lv2)のAndroid

7月にはJUCEが6.0になってLinux VST3も使えるようになったので、これはtracktion_engineもアップグレードすればホストもいける…!ということで去年作っていたaugeneをアップグレードしてVST3でJUCE音源をまたいじるようになりました。

それで、デスクトップで使えてAndroidにも移植できて自分でもそれなりに使えそうな音源ということで、とりあえずADLplugに含まれるOPNplugをAndroidプラグイン化しました(OPNなら自作音色のストックがいくつかあるのです)。ただ音色バンクのフォーマットがよくわからないものなので、MMLで書いていたようなのを直接書けるようにならんもんか…と思っていたらOPN2BankEditorというアプリで変換できることが分かったので、ちょっとだけ開発に協力したりしていました。

それから気づいたのですが、FM音源はOPNplugで再現できたとしても、OPNplugにはSSG音源に相当するものが存在しません。OPNが含まれていたYM-2203にはAY-3-8910というSSG音源が載っていたのですが、これを再現するプラグインが見当たらないのです(少なくともLinuxで動作できるようなものは)。

エミュレーターはいくつかあったので、とりあえず簡単そうなayumiというエミュレーターをベースにayumi-lv2というLV2プラグインを作ってみたのですが、SSG音源にどんな生パラメーターを与えればいいのかまだよくわかっていないのでちゃんとした音が出るかはまだ確認していません(音は出ますが)。サンプル作っておいてほしみ…! LV2プラグインの作りはsfizzなどを参考にしつつシンプルなMIDIトランスレーターにしたので、LV2プラグインのリファレンスコードとしても悪くないと思います…音が意図通りに出ていることさえわかれば(!)

自作LV2プラグインAndroid移植は死ぬほど簡単でした(LV2ヘッダファイルの参照だけ面倒ですが、これはaap-lv2の他のプロジェクトの使い回しで十分なので)。ホストとプラグインを別々にデバッグできるのも状況次第では便利です。HPマシンで開発していたときはjackd依存のホストが全滅でAndroidでしかデバッグできませんでしたし(!?)。

sfizzのAndroid assets対応(進行中)

最近手を出して泥沼化しているのがsfizzのsfzファイルをローカルファイルではなくassetからロードできるようにする変更なのですが、割としんどいやつで今も実のところホントに続けるのかどうかわからないレベルです。sfizz単体ならまだ何とかなるかもしれないのですが、libsndfileにも手を加えてassetをロードできるようにするとなると途端に煩雑になるので…(そもそもlibsndfileはaap-lv2ではビルドしないバイナリ参照だし)。

これに拘っているといつまでも先に進めないので、たぶんwebから落としたやつをローカルファイルでロードするようになると思います。ただこれもAndroid11からはかなりしんどいので、進むも戻るも地獄みたいな感じです。まあ何とかなると思いたい…(?)

8月の予定

8月は、当初の予定ではLV2本の執筆に費やされる予定だったのですが、だいたい終わってしまったので、M3に向けて創作環境を再整備しようと思います。いいかげんMMLコンパイラMIDI仮想キーボードを作り変えないと…。そんなわけでオーディオプラグインからは離れそうな気がします。まあそう言いながら今週もほとんどsfizzのコードをいじって時間が溶けていたりしますが…! ではまた来月(?)

6月の作業記録

このシリーズのタイトル使うのひさしぶりなんですが、先月書いたaria2webも実質的に作業記録みたいなものなんで、掘り起こして復活させた、みたいな感じではありません…。

6月の、と書き出してしまいましたが、前回からの差分だけにしておきます。3週間くらい?

designing Audio Plugin Framework for Android @ COSCUP 2020

台湾の大規模コミュニティカンファレンスCOSCUPで2年ぶりにしゃべることにしました。内容は今開発しているAndroid向けオーディオプラグインフレームワークの設計アプローチについて、ということになります。7月はその準備作業に着手する予定です。

2018年もlanguage server protocolについてのセッションで、かなり.NET色を排除した内容だったのですが(それまではMonoDevelop -> Monoランタイム -> .NET Coreだった)、今回は完全に過去を切り捨ててオーディオの話をします。どっちも単独で引っ張るとまあまあ素人なのですが、複合領域だからな…!

AndroidiOSもなのですが、モバイルOSは実行可能なコードの制約が強く、プロセス分離から逃げられないので、それを踏まえたオーディオプラグイン機構が必要になります(この話題ここではしょっちゅう出してますが)。オーディオはリアルタイム処理も考慮しないといけないので無理ゲーなのでは…!?となってしまいますが、Android 8.1で「Realtime IPC Binderが実装された<折返し>か!?」みたいな状況になっていたりする…など無駄に深入りした話などを交えつつ、基本的にはどういう設計が求められるかという上澄みの話をする予定です。

プラグインUIの仕組みなども実装しておきたいのですが、時間的に厳しそう…(30分しかないし)。実装基盤もガタガタなので、おそらくその辺を強化して終わりでしょう。

ちなみに台湾のカンファレンスのスピーカーといっても、それだけで業務出張になるわけではないので、渡航資格が発生するわけではありません。そんなわけで日本からのオンラインセッションとなる予定です。準備というのはだいたいそっちの練習という感じです。やってみないとわからないですしね。基本的には会場のネットワークに繋いでビデオ通話するだけなのですが、もしかしたら日本からでも見えるようになるかもしれません。現状何もわかっていません。

aap-sfizz

今月の上旬に書きましたが、ARIAのUIをWebViewで表示できるようになって、sfizzとも組み合わせてオーディオプラグインとして使えるようになったので、今度はこれをAndroidで動かそうと思ったわけですが、LV2プラグインの移植はmda-lv2しか実績がなく、その土台を整備する作業が必要になりました。JUCEのプラグインならほぼProjucerのプロジェクトがあるわけですが、LV2プラグインはプロジェクトによる感じです。

sfizzはCMakeのプロジェクトなので、プロジェクトファイルを取り込むという意味では難易度がやや低いのですが、Android用のLV2開発ライブラリをパッケージとして参照解決できる状態にはなっていません。理想を言えば、aarを参照に追加するだけで解決したいところです。

この目的ではAndroid Studio 4.0に新規追加されたPrefabフォーマットのサポート(4月に書いたやつ)が解決することが期待されたのですが、全くうまくいく様子がなく、AGPのソースを追っかけてもそもそもprefabツールがセットアップされる様子もなく、Prefabパッケージの妥当性を検証する機構が全く無いので(こっちはLV2で使われているwafのビルド結果を手作業でバンドルするしかない)、まだまともに動作させるのは無理だという結論になりました。この辺の機能は今のAndroid NDKのプロジェクトリーダーが仕切っているっぽいのですが、どうも中途半端な機能を無理やりリリースにねじ込んでいる感が否めません…

ともあれ、Prefabは使えないので、これまで通りwafとcerberoのビルド結果をaarに取り込みつつ、参照側でもPkgConfigのパスなどをよろしく解決できるhackに頼るという方向性で、sfizzのCMakeLists.txtにパッチを当ててなんとかビルドしました。

sfizzはそれでビルドまではできたのですが、実際にsfzファイルをロードするところまではまだ実現できていません。それほど難しくはないはずなのですが、続く2つのタスクが先だと判断して先送りしています。

aap-lv2モジュールの切り離しとmda-lv2の再構成

sfizzの移植は、当初は独立リポジトリで行っていたのですが、LV2プラグイン移植の依存関係にフレームワーク本体を追加しないといけない状態はしんどいなあ…と考えていました。

また一方で、そもそもプラグインフレームワーク自体にLV2は必須のものではありません。LV2依存部分がビルドの難易度を爆上げしていた側面はあります。(これは実際にはそこまで大したことはなく、当初lv2リポジトリのサンプルプラグインまでビルドしていた関係でlibsndfileやcairoまでビルドしていたことが原因なのですが、それらを除外してもmda-lv2ではlibsndfileが必須でした。)

mda-lv2はもともとLV2プラグインをビルドする際に必須ではないですし、これだけはGPLv3なのでビルドから切り離しておきたかったこともあって、LV2まわりのビルドを根本的に見直すことにしました。最終的には、aap-lv2というリポジトリが誕生し、プラグイン本体はaap-juceを切り離した時のようにスッキリしました。

いったんLV2依存部分を切り離すと、ここにLV2プラグインの移植を放り込むことでビルドスクリプトの負担がかなり下がったので、sfizz移植はここに追加しました。mda-lv2はLV2サポートのリファレンス実装としてモジュールを再整備されています。

いずれprefabが安定的に使えるようになってaarがMaven経由で使える程度に安定化してきたら、単独の移植プロジェクトでフレームワークを参照するのも平易になるでしょう。(aap-lv2リポジトリ自体はLV2バックエンドの開発とdogfoodingのために現状のままが良いですが。)

Guitarixの移植

前述の4月のエントリーでも言及したのですが、sfizzでインストゥルメントプラグインを実現して、Guitarixで実用的なエフェクターを取り入れることができれば(といってもどれだけ実践的なのかは正直サンプル以上のことはわかりませんが)、とりあえず「波形合成のおもちゃ」以上の、まともな音源で作られた楽曲を再生できる期待値は上がります。

そういうわけでいよいよGuitarixを取り込むことにしたのですが、Guitarixもwafを使ってビルドするので、LV2モジュールをAndroidようにビルドする仕組みを再利用できるようにすることにしました。今後LV2プラグインを誰でも移植できるようにするためには、自分で道を作っておかないといけないわけです。

ビルドスクリプトそのものは再利用がそれほど難しいわけではないはずだったのですが、LV2リポジトリのビルドはautowaf、Guitarixは手書きのwafなので(wafはpythonスクリプトなので何でも書けてしまう)、再利用できる部品だけ再利用しました。同じことを移植作業では毎回気にしないといけないことでしょう…

Guitarixの最難関はハードな依存関係です。glibmm、その依存関係にあるlibsigc++、glibなどが基本にあって、さらにlibsndfile, fftw3, eigen、zita-convolver, zita-resamplerといったものをすべてCerberoでビルドできるようにしました(zita-*は必要なかったので無駄足になってしまいましたが…)。

ネイティブライブラリのビルドシステムのオーバーホールの一環として、Cerberoを置き換えることも検討したのですが(何しろこれはGStreamerのためにしかメンテされないので)、Prefab・ndkportsは前述の通り未熟すぎ、vcpkgはLinuxサポートですら建前でしかなく、パッケージのビルドスクリプトWindows対応のことしか考えていないというのがザラだったので(vcpkgがLinuxで使われるようになる日は一生来ないだろうと思いました)、引き続きCerberoを使っています。

ビルドできたGuitarixは、Androidプロジェクトに取り込むにあたってディレクトリ構成を差し替えないといけないのですが(何しろlib/lv2/GxHogehoge.lv2みたいなディレクトリからターゲットアーキテクチャ向けでもない.soファイルをロードすることはできないので)、それらを自動的に再配置するMakefileスクリプトもaap-lv2で追加されています。誰でも(特に「将来の自分」)同じ手順を追えば任意のプラグインを移植できるようにする、というのが重要です。

ともあれ、Guitarixも無事移植できました。数十種類のエフェクトが利用可能なプラグインのリストに追加されるのを見るとアガりますね。

f:id:atsushieno:20200629230048p:plain
guitarix on Android

Mac環境用ビルド

この3ヶ月くらいメイン開発機のHP Spectre x360のキーボードの故障がひどく、キーが入力できなくなってHPに修理依頼しても、帰ってきてしばらくするとまたキーが入力できなくなる…というのを繰り返していて(実のところ今も修理中)、完全に生産性が下がっていて困っています。

さすがにこのままではまずいと思って、打ち込みマスタリング用のMac環境でも何とかこの辺のリポジトリの開発が継続できるようにビルドを整備しました。GitHub ActionsでMacビルドが通るくらいまではきちんとやってあります…あったのですが、GitHub ActionsはAndroid開発環境のアップデートがまともに行われずAndroid API Level 30がいつまでも入ってこなかったので、CIは放置状態でした。モバイル開発で最前線を走るならGitHub Actionsはやめておいたほうがいいのかも…

ちなみにWindowsでもビルドできました。ただしmakeをWSL環境で走らせてからWindowsAndroid Studioで開いて開発を進める必要があります(ASはWSL2でも動くかもしれない)。GitHub Actions上でWSLのbashを呼び出す方法がわからないので、CIは通さないでしょう。

Next Steps:UI統合

Guitarixの個別のプラグインにはまだ謎のクラッシュを起こすものがあるのですが(要個別調査)、多くが何やら動作はできているっぽいので、「DAWあるいはそれに類するシーケンサーで音楽を演奏できる」状態にするために必要な作業は、インストゥルメント(sfizz)まわりの整備とシーケンサーの整備という感じになりました。

プラグインフレームワーク自体にもLV2バックエンドにもまだまだやることはいっぱいあるので、音楽が演奏できるようになっただけでは完結しないのですが、当面の目標はその辺りです。

aria2webはsfizzをKontaktみたいな商用製品っぽく見せるように構成するのとWeb UIを実現するのが目的でしたが、そのUI統合モデルはそのままこのプラグインフレームワークにも敷衍できます。というドキュメントを先日まとめていたので、この辺に着手しつつ、プレゼンテーションの準備をすることになるでしょう。

シーケンサーはtracktion_engineを使い回せれば十分だと思っています。tracktion_engineがAndroidで期待通りに完全動作するかは不明ですが、juce_emscriptenでもStepSequencerDemoが動いているのでまあ大丈夫ではなかろうか…

tracktion_engineはエディタを伴わず、デスクトップ環境で作成した楽曲データはそのままでは再生できないので、プラグイン情報などを適宜マッピングして再生することになるでしょう。楽曲はMIDIファイルからインポートできるので(デスクトップ向けには実績があります)、Android上でも再生できるような楽曲は作成可能であると踏んでいます。sfizzベースのインストゥルメントであれば、複雑な命令を伴わないので十分に可能でしょう。

aria2web: SFZ ARIA GUI extensions on Web UI (Part II)

前回の続きとなるエントリーです。今回はWeb UIをLV2 UIとしてどう統合するか、という話。

atsushieno.hatenablog.com

だいたい作る予定だった部分はほぼ完成したので、とりあえずこの開発はいったん完了とするつもりです。

github.com

復習と後半の導入

前回はSFZサウンドフォントをGUIからコントロールできるようにするARIA extensionをWeb UIで実現しました。UIだけだと何もできないので、これをsfizzというSFZのサンプラー(UIが特に無い)と組み合わせてホンモノのオーディオプラグインとして機能するものを作ります。

オーディオプラグインフレームワークの選択

sfzサンプラーはいくつか実装があるのですが、今回はOSSで一番期待値が高そうなsfizzを使うことにしました。同じ開発者がsfzformat.comというサイトの中でsfzプレイヤー(ライブラリ)の実装リストを公開しているので、この中にあるものはだいたい見ています。

わたしの開発の主目的は自分のLinuxデスクトップ環境で使えるオーディオプラグインを探すことであり、その次に自前のAndroidフレームワークで使えるサンプラーを用意することにあるので、オーディオプラグインフレームワークとしてはほぼ唯一解としてLV2を選択しています。

…というのが3月頃のわたしの選択だったのですが、sfizzの最近の開発動向を見ていると、どうやらVST3との2本立てになっているようです。VST3ではわたしがDAWに(…ではなくMMLなこともあるので、まあ「制作に」)使っているTracktion Waveformなどが未対応ですし、Android環境でも「まだ」vst3sdkがビルドできる状況ではないので、VST3はまだ選択肢にならないのですが、今後は可能性があるかもしれません。

LV2を使えるDAWは現状生粋のLinux向けDAW(Ardour, QTractor, Zrythmなど)がほぼ全てですが、以前にもちょっと言及したlv2vstを使うとVST環境でも部分的に使えます。

ちなみにsfizzでは以前はJUCEが使われていたのですが、JUCEのLinux環境サポートが貧弱だったこともあってか、JUCEは捨てられてLV2をダイレクトに実装する方向性に変わっていました(Linux系オーディオ開発者の間ではJUCE離れが進んでいたという話を3月に書きましたが、これもそのひとつです)。最近developブランチで開発が進んでいるVST3サポートもダイレクトな実装です。

sfizzにはLV2の特徴のひとつであるCVポートは必要なく、sfzファイル名を除いて全てのポートがfloat1つのパラメーターで表現できるので、技術的な理由でこれらをダイレクトに実装したということは無いはずです。

LV2 UIの独立ライブラリ設計

aria2webのUIをどうsfizzに組み合わせるのか解説する前に、いくつか説明しておくべきことがあります。まずはLV2ホストがLV2プラグインとLV2 UIプラグインを繋げる仕組みです。

LV2 UIは、コードの分離としては優れた設計になっていて、プラグインの共有ライブラリとは別に、プラグインUI用の共有ライブラリを指定するようになっています。これは暗黙的にオーディオプラグインUIの処理をオーディオ処理から分離する役に立っています。プラグインとUIは、次の2つの手段でやり取りします。

  • audio to UI: プラグインUIはプラグイン本体の出力ポートにsubscribeするようmanifest (.ttl) に記述することで、プラグイン本体からのデータ変更通知を受け取れます。
  • UI to audio: ホストがUIプラグインの初期化時に呼び出すinitialize()関数では、プラグインUIから操作などをプラグイン本体へ通知するときに呼び出すwriteFunctionという関数ポインタが渡されるので、UI実装のコードではこれを随時呼び出します。

オーディオプラグインにおいては、オーディオ処理とGUI処理には別々のスレッドが用いられます。オーディオ処理はリアルタイムで行われなければならないので、リアルタイムで処理することが想定できないイベントループをかかえるGUIは、独立して動作しなければならないためです。(LV2にはWorkerという拡張機能があり、オーディオスレッドでの処理が不適切である機能はこれを使用して実装しますが、GUIサポートはホスト側で別スレッドで処理することが最初から想定されているので、プラグイン側が気にすることはありません。)

LV2プラグイン実装のトレンドに関するフォローアップ

4月にLV2のGUIサポートのトレンドに関するメモを公開しました。LV2というかLinuxデスクトップではGUIフレームワークがいくつかあって、QtにもGtkにもバージョンがあるしX11ベースの他のツールキットもあってバベルの塔が崩壊した後の状態になっていて、それをsuilでまとめつつあるみたいな状態だ、という話でした。

このときは「suilを使えばまあ概ねどのGUIバックエンドで実装していても違いを吸収できるようになっているんじゃないか」と考えたわけですが(それで実際ある程度解決するわけですが)、何やらこれがZrythmの作者の目に止まったらしく、いろいろ教えてもらいました。

まずプラグイン開発のトレンドは概ね「X11UIを使わないとダメっぽい」という方向性に収束しつつあるようです。suilはホスト側の実装で、ホスト側のトレンドとしてsuilが使われているのは間違っていないわけですが、X11レベルで実装していれば互換性問題が生じない、というのが理由であるようです。X11でダイレクトに使えるUIフレームワークには、FLUTなどGL系のライブラリ、JUCE GUI、LV2であればpuglという独自のライブラリがあります。(そういえばGuitarixがX11でUIを書き換えているという話を書いたこともありますね。)

suilで何が解決しないかというと、まずそもそもGtk2とGtk3などを1つのアプリケーションで混在して利用することができない(らしい)という話があります。gtk2のglibのアプリケーションループとgtk3のglibのアプリケーションループが共存できない、と考えると、まあ納得感があるでしょう。Qt4とQt5も同様の状況なのかは分かりませんが(Qt4は触ったこともない)、その可能性は十分にあると思います。

上記のトレンドに関するメモでも言及しましたが、そもそもGUIフレームワークごとにホストから渡されてくるGUIウィジェットのparentが何になるのかが明確に規定されず、LV2 UIの仕様自体が詰めきれていないという問題もあります。LV2の仕様ではGtkUIやGtk3UIは「バイナリディストリビューションで使用すべきではない」と記述されているのですが、(わたしの理解としては)バイナリ配布なしに任意のプラグインUIを使用する方法は現実的にあり得ず、要するに仕様として失敗しているところです。LV2仕様は所詮個人で決めているものであり、この種の技術的な回答を提示できない問題が生じるのは仕方のないところでしょう。

LV2 External UI

aria2webのUI統合…というかLV2プラグイン統合…の最初の問題は、Gtk3UIとしてwebview.hからGtkWindowを取得してもホストから渡されるparentにattachできないことでした。以前のUIトレンドの記事も書きましたが、Zrythmから渡されるparentはGtkEventBoxで、event boxにwindowを子として追加することはあり得ないですし、webview.hには親としてGtkWindowしか渡せなかったので、Gtk3UIは早々に諦めました。

とはいえ、X11UIにしたところで親としてはwindowが渡されることに変わりはなく、webview.hとの相性はよくありません。webview.hを諦めて独自実装するのであれば、前述の「suilでも解決しない課題」のことを考えるとX11レベルでやるしかありませんが、WebkitではWebkitWPEくらいしか解決策が無く、これは組み込み環境用にビルドできるという以上のものではない(X11統合があるわけではない)ので、自前で実装するのはしんどいぞ…となりました。WebKit以外の選択肢としてはCEF (Chromium Embedded Framework) がありますが、CEFを組み込むとかなり巨大なバイナリになってしまうので、可能な限り避けたいところです。

それならば、いっそCarlaで採用されているexternal UI方式ではどうだろうか、と考えました。Carlaがどういうアプローチで採用しているのかは分かりませんが、external UIではホストからのコントロール インターフェースとしてshow/hide/runだけを規定するので、それをUIが自前で実装する、というスタイルです。現在aria2webではこれが採用されています。

前述のLV2 GUIのトレンドのメモでは、APIとしてUIとオーディオ部分を分離して処理できるような仕組みを想定していない、と理解していたのですが、実際にコードを組んでみると、この連携部分はmanifestのport subscriptionとwriteFunctionだけで実現できました。

aria2webの初期設計では、UIがinstantiate()の呼び出しによってホストから起動されたら、webview.hを使って手抜きで実装したUIを表示して、そのAPIでJSオブジェクトにC関数コールバックを割り当てて、それが呼び出されるたびにwriteFunctionを呼び出してプラグイン側に反映する、というアプローチで実装しました。これでZrythmからのUI生成が実現できました。

LV2 UIのプロセス分離

Zrythmから表示できるようになったaria2webですが、webview.hでは内部的にwebkitgtkが用いられており、これはQTractorで使えませんでした。webkitgtkがGtkアプリケーションループの存在を前提としていたためです。suilが解決すべき問題ではないかという気はしますが、とりあえず方向転換が必要になりました。そこでUIプロセスを分離することを思いつきました。

オーディオプラグイン機構全般にいえることですが、多くのホスト(DAW)ではユーザーが楽曲の打ち込みで指定したプラグインを、インプロセスでロードします(この辺りの技術的課題については1年前にメモをまとめてあります)。これはLV2ホストの場合も同様です。

ホストとプラグインがひとつのプロセスで動作するということは、ホストがsuilで別々のUIフレームワークを繋ぎ込めたとしても、プラグイン同士で共有ライブラリを動的にロードしていた場合に、その前提バージョンが異なっていると、いわゆるDLL hellのような状態になりかねないでしょう。(プラグインのローカルパスから共有ライブラリをロードできない場合などもあり、静的にリンクすることが多いとは思いますが、それが適切でない場合もあるでしょう*1。)

これは個人的な分析として、どちらかといえば、LV2はプロセス分離モデルに関する意識が低い側面があります。そのひとつがLV2サポートに不可欠なURIDのモデルです。URIDとは、LV2プラグインの様々な場面で使われている「名前空間」を表すURI文字列を、オーディオ処理の過程でも無理なく使えるint32_tに変換する仕組みです。ホストとプラグインは、URIDのmap/unmapという機構(関数ポインタを含むstructで表現される)を用いて、文字列と整数を相互変換します。もしプラグインが分離プロセス上で動作していたら、メンバーとして渡された関数ポインタをそのまま関数として呼び出すことはできません。

プラグインプラグインUIは別々のプロセスで動作できるのでしょうか? 前述したオーディオとUIの双方向のやり取り(特にwriteFunction)をそのままプロセス分離して利用することはできませんが、ホストとUIプラグインのコードそのものは同一プロセスで動作させつつ、UIプラグインのコード自体から分離プロセスをspawnして起動することは不可能ではありません。オーディオポートからの通知はそのままUIプロセスに流せばよく、UIの変更もそのままwriteFunctionの呼び出しに繋げれば良いだけの話です。

aria2webにはWeb UIを単独で表示できる(けど音は何も出さない)aria2web-hostが存在したので、プラグインUIが受け取った通知をstdinから読み取り、UIイベントをstdoutに書き出す、という単純なパイプでプロセス間通信を実現しました。spawnで実装するのが面倒だったので、gitlabで発見したtiny-process-libraryというクロスプラットフォームC++ライブラリを使っています。*2

READMEにも書いているのですが、図面にするとこんな感じです。VSCodeに統合されたdraw.ioで描いたやっつけ図面…!

https://raw.githubusercontent.com/atsushieno/aria2web/051504c/aria2web-ipc.drawio.svg?sanitize=true

何はともあれ、UIプロセスを分離したことによって、QTractorからでもUIがロードできるようになりました。ちなみにここまで進めても、オリジナルのsfizzには名前空間衝突を避けるためのURI変更とui:uiのmanifest要素追加以外では、一切手を入れていません。

オーディオ処理部分とのやり取りとウィンドウ管理

LV2のオーディオプラグインとのやり取りは、通知ポートとwriteFunctionの2つで行われる、という話を書きました。

通知ポートは、オーディオ側では「出力」ポートとなっていて、まず「イベント」はLV2UI_Descriptorで登録したport_eventに届きます。

void aria2web_lv2ui_port_event(LV2UI_Handle ui, uint32_t port_index,
     uint32_t buffer_size, uint32_t format, const void *buffer)
{
    ...
    
    if (port_index == ARIA2WEB_LV2_NOTIFY_PORT) {

また、UIプラグインでmanifestにui:portNotificationを追加すると、指定したport(ここではsymbolで指定)に届いたイベントを受け取れます。

<https://github.com/atsushieno/aria2web#ui>
  a extui:Widget ;
  ui:binary <aria2web-lv2ui.so> ;
  ui:portNotification [
        ui:plugin <https://github.com/atsushieno/aria2web> ;
        lv2:symbol "notify" ;
        ui:protocol atom:eventTransfer
  ] .

AtomとPatch

イベントはAtomというLV2独自のバイナリデータのフォーマットで渡されてきます。Atom形式のデータを構築する方法についてきちんと説明するとそれだけで数千字になってしまうので今回は省略します…(割と大変だったのでホントはちょっと書こうと思っていましたが…)。

writeFunctionは次のような形式で定義されるのですが、

typedef void(* LV2UI_Write_Function) (
    LV2UI_Controller controller, 
    uint32_t port_index, 
    uint32_t buffer_size, 
    uint32_t port_protocol, 
    const void *buffer)

引数が先のport_eventとよく似ています。port_protocolには主にfloatの値1つだけを渡す場合と、Atom Event形式のデータを渡す場合があって、一般的なパラメーターはfloatプロトコルでbufferポインタの先にfloat値が1つ入っているだけです。

sfizzでややこしいやり取りは、sfzファイル名を渡す場合にこのAtom形式にファイルパスを変換して送信する部分だけで、ここにはLV2 PatchというAtom上で成立するパッチDSLのようなものが使われています。これも詳しくは解説する余白が足りないので省略しますが、patch:getというメッセージで「sfzファイル名を送れ」とオーディオの入力ポートに送信すると、sfzファイル名を含むpatch:setというメッセージが通知ポートに届きます。MIDI 2.0のProperty Exchangeっぽい感じです。

ウィンドウとインスタンス管理

プラグインUIは次のようなタイミングでプラグイン本体から情報を受け取る必要があります。

  • ウィンドウの表示・非表示を変更したとき
  • プラグインの削除などに伴ってUIを破棄した場合

これらについては、前半で少し触れた、Carlaを開発しているKXStudioの"External UI"のインターフェースに沿って、show / hideといったコールバックが呼び出されるので、それに従ってウィンドウ表示を調整します。

ウィンドウの表示制御は、aria2webの場合はあくまで「ホストから行う」ことにしており、ユーザーが閉じることは想定していません。ZrythmではGtk3UIなどのウィンドウを自分で閉じることも出来てしまうのですが、これはホスト側からウィンドウの状態を把握できているから出来ることでもあります。external UIではホスト側がこれを把握することは出来ず、またプラグインUIからイベントを受け取ることもありません。想定外の状態を管理することになってしまうので、少なくともexternal UIを使う時はウィンドウを閉じるボタンは消しておいたほうが良いでしょう。

プラグインUIがshow / hideイベントを受け取ったら、子プロセスにパイプのstdioで命令を伝達しています。

プラグイン側からのSFZファイルの変更通知とUIへの反映

プラグインUIの表示で厄介な部分のひとつに、オーディオ部分にSFZファイルの変更があった場合にそれをUIに反映させるまでの流れをどう作るかという課題があります。

基本的には変更が生じたらport_eventで通知ポートから受け取ったファイル名をもとに子プロセスのウィンドウにstdioのパイプで通知を伝達します。現状SFZファイル名の更新くらいしか通知しないので、SFZ (filename)\nと書くだけです。問題は、DAWが楽曲をロードした場合など、プラグインの初期化タイミング(トラックがロードされた時点で初期化)とGUIの初期化タイミング(UI表示が指示された時点で初期化)の、どのような組み合わせについても対応できる必要があるということです。

aria2webの現在の実装では、UIがinstantiateされ子プロセスでのJSのロードが完了した時点で、親プロセス(プラグインUI側)に初期化完了の通知を送ります。プラグインUIはこれをstdioのパイプで受け取ると、sfizz本体にpatch:getを送って、SFZファイル名を通知ポートに送ってもらいます。これが届いたら、それを子プロセスに送って表示を更新します。

このややこしい手順を踏まないと、「子プロセスがまだWeb UIの処理に必要なJSをロードできていない時点で表示更新のためのJS式の評価が呼び出されてしまってエラーになる」といった事態が生じてしまいます。UIプラグインと表示プロセスの間でプロトコルが確立していると、そういった事故を防ぐことができます。

未解決の課題と応用

だいたい以上のような実装を終えた時点で、オーディオプラグインとしての機能はだいたい完成したことになるのですが、課題もいくつか残っています。一番直感的に困るのは、ARIA GUI上にknobやsliderやswitchが存在していてこれでサウンドを調整できるはずなのに、これらはsfizzのパラメーターとしてプラグインのstateに保存されない、ということです。

sfzではこれらはMIDIイベントとして受け取る前提になっていて、stateではなく楽曲のMIDIデータのような部分に保存されていることが前提になっています。そのため、これらをsfizzの今の実装とは別に保存しないと、Kontaktなどを使っているような気分でプラグインのツマミを調整しても記録が残らず、データが失われたような使い勝手になってしまいます。割と重要な課題…

あとはWebKitGtkの問題のせいで、shiftキーを押した状態でwheelイベントを処理しようとすると、なぜかxy軸がひっくり返る(縦wheelなのに横扱いになる)みたいなバグがあったり…

UIの問題とは別に、ひとつ目的にしていたSFZのギター音源をsfizzで鳴らすという試みなのですが、sfizzでサポートされていないSFZ 2.0のopcodesがふんだんに使われているということもあって、まだ音が鳴らないというのが現状です。ただkey switchも適切に入力できているかわかっていないし、サックス音源などは鳴っているので、sfizz本体の開発をもう少し待ってからでも良いだろうと思っています。

他にもいくつかissueとして課題になっているのですが、「プラグインUIを音声処理プロセスから分離しつつホストと協調的に制御してオーディオプラグインらしく振る舞う」という実験にはどうやら成功したと言えるので、これをAndroidフレームワークにも適用していこうと思っています。

*1:たとえば依存ライブラリにsecurity fixがあった場合に必ずアップデートを自前でリリースできるか、などの考慮事項があります

*2:ちなみに今回使っているサードパーティライブラリ、webviewもhttpserver.hもクロスプラットフォームです(自分のコードではGtkWindowにキャストしている部分などはありますが)。

aria2web: SFZ ARIA GUI extensions on Web UI (Part I)

目次

4月頃に、自作オーディオプラグインフレームワークのUI構想についていろいろ検討していて、SFZサウンドフォントのARIAまわりを取り込んでsfizzというSFZサンプラープラグイン)に統合したいという話を書きました

これをaria2webというプロジェクトとして開発して公開しています。まだ実用品ではないのですが、いろいろ知見があったので今のうちに書き連ねておこうと思います。

github.com

aria2webは、ひとことでまとめると、ARIA GUIをHTML(+SVG+JS)化して、WebViewが使える任意の環境でオーディオプラグインGUIとして汎用的に使えるようにしよう、というものです。

動機: なぜSFZを使うのか

オーディオプラグインフレームワークを作る目的は、音楽制作・再生のためのエコシステムを構築することです。古典的なDTMでは「楽器」に相当するのはMIDI音源でしたが、MIDI (1.0)の表現力では自由に思ったとおりの音楽を表現できないことが多いので、現在ではオーディオプラグインを使うのが一般的です。

オーディオプラグインには(ちょうざっくり分けると)楽器とエフェクターがあって、自分のフレームワークでは、とりあえずproof-of-conceptレベルではVSTのサンプルとして使われてきたmdaがLV2に移植されたmda-lv2が、すでに動いています(何しろLV2が実質無修正で動くので)。また、JUCEのプラグインにちょっとモジュールを追加するだけで対応プラグインがビルドできるので、それで取り込めるプラグインもいくつかあります。(UIをホスト側で出すのは現状では無理だけど模索中です。)

楽器のほうもfluidsynthをオーディオプラグイン化したjuicysfpluginsfizzを使えばいけるはずです。juicysfpluginはJUCEソリューションなのですが、内部的にはgtkにも依存していてちょっと使えないし(ここ後で触れる予定)、SF2/SF3のFluidsynthより表現力の高いSFZをサポートしたほうがより本格的な楽器プラグインを実現できる(何しろFluidsynthはMIDI 1.0のレベルなので)と考えてSFZとsfizzのほうを主なターゲットにしています。

SF2/SF3もSFZも同じ「サウンドフォント」ではないのか、何が違うのか、と思われそうですが、SFZにはキースイッチ*1のサポートなどで、SF2/SF3より柔軟な条件式で対応するサンプルを選択できるようになっており、本格的に楽器を表現できるフォーマットとして現在も進化しています。(独自拡張から標準化に進む世界であるようです。)

オーディオプラグインの世界では「サンプラー」というジャンルがあって、サウンドフォントの再生エンジンはこのカテゴリーに属することになります。サンプラーとして有名な音源はKontaktとかVSLとかです。Cubaseに付いてくるHALionとか、わたしが使っているWaveform付属のCollectiveなんかもそうですね。SFZにもこれらの商用音源に匹敵する機能を実現できるポテンシャルがあります。

自分のオーディオプラグインフレームワークKontakt並の音源を実現できるとしたら、だいぶ「エンドユーザーが使いたくなるもの」なのではないかという気がしてくるのではないでしょうか。

ARIA GUIとは何か

SFZはSF2/SF3より詳細な条件式でサンプルを選択できるという話を書きましたが、条件式の記述に用いられるのはopcodeと呼ばれる命令識別子であり、要するにごく単純なプログラムを書いているようなものです(プログラムの著作物とまでは言えないレベル)。SFZのopcodeは特に技術標準とまで言える仕組みではなく、これを各サンプラーのベンダーが独自拡張して使っていることがあります。

ARIAというのは*2、Plogue社のsforzandoというサンプラー製品で使われている独自拡張ですが、これにはSFZのopcode拡張の他に、GUIを定義するXMLマークアップボキャブラリーも含まれています。SFZの仕様にはGUIの定義が含まれていないので、SFZのサンプラー音源をいじるときは数値と格闘するか、標準的なコントロールを操作するしかないのですが、どのパラメーターが重要なのかはユーザーには分かりません。GUIがあればこの問題が緩和されます。

ARIA GUIの内容はごく単純です。

<GUI w="775" h="335">
 
  <StaticImage x="0" y="0" w="775" h="330" image="Main/Control.png" transparent="1" />

  <Knob param="20" x="53" y="168" image="Main/Window1.png" frames="101"   />

  <OnOffButton param="23"  x="660" y="282" w="52" h="21" image="Main/Button.png" />

x, y, w (width), h (height), image 程度のもので、GladeやXAMLなどに比べたら内容も多くが自明です。これで、例えばこんな画面ができます。(Unreal InstrumentsのMETAL-GTX)

f:id:atsushieno:20200601154625p:plain
UI METAL GTXのGUI

この画面では、ツマミの部分と数値入力っぽい部分がKnob要素で表現されています。Knobparamframesimageには説明が必要でしょう。まず簡単なframesのほうを説明しますが、これは数値の範囲に対応します。frames="101"というのは、数値が0〜100の101段階であることを意味します。paramは、サウンドフォントのどのパラメーターを操作するものなのかを、MIDIのコントロールチェンジのように数値で指定します。.sfzファイル側で規定しているはずです。

ツマミの部分は画像を自由に指定できます。それがimage属性の内容なのですが、リンク先を見てみてください。巨大な内容なので埋め込みはしません。

https://aria2web.firebaseapp.com/ui-metal-gtx/gen/GUI/Main/Main_Knob.png

あれ? 見えなくない…?ってなりますが、実はものすごい縦長の画像が、ブラウザウィンドウの幅に合わせて縮尺を調整した結果です。上方のごく一部だけを切り取るとこんな感じになっています。

f:id:atsushieno:20200601154706p:plain
ツマミ画像(抜粋)

ツマミですね…! ひとつひとつをよく見ると、ダイヤルが少しずつ上に移動しているのがわかります。縦長なのは、これが101個ぶんだけ縦に連結しているからです(!)。画面上には「今の値に対応する画像」を表示するだけです。とんでもないやっつけ仕様ですが、確かにこのフォーマットであれば、サンプラーのコードでは何も面倒を見る必要がないので、プラグインを作る側は自由なデザインでツマミを実装することができる、というわけです。

そして数値入力っぽく見えるのも実はダミーで、これはKnobコントロールです。マウスホイールで数値を変更できます。キーボード入力はできません。もちろん数字はツマミと同じ超縦長画像に描かれています。なんか…とんでもねー世界に来ちまったぞ…

webaudio-controlsを活用してHTML UI化する

GUI拡張と聞くとなんかものすごい技術努力によって実現しているかのように思えてしまいますが、ARIAはごく単純な仕組みとデータ形式でUIを表現していました。この程度であれば、HTML+JavaScript+CSS+SVGで表現できるでしょう。sforzandoはLinux版を提供していないので(もちろんAndroid版もありません)、ARIAGUIをロードできるようにするには自前で実装するしかありません。

aria2webのREADMEでも言及しているのですが、実はもう出来ていて、ここで試すことができます。

https://aria2web.firebaseapp.com/

今回これを作るにあたって活用したのは、この方面ですでに存在していたwebaudio-controlsという完成度の高いUIコントロールです。Web Componentsに基づいて作られていて、Javascriptから操作するのも簡単です。元コードの開発メンバーがだいたい日本のWeb Music Developers JPあたりにいそうです。

github.com

実のところ、ARIAがそこまでGUIの詳細な表示内容をデータ上に持っているとは考えていなかったので、ツマミやスライダーはこのwebaudio-controlsを使えば「それっぽいもの」が作れると思っていましたが、結果的には「ほぼ元通りのUIっぽいもの」を再現できるところまで出来ています。

ARIAXMLをHTMLに変換する処理は本当に簡単なもので、現状では100行も無いXSLTスタイルシートで実現しています。あの妙な画像も変換しなくていいの?と思うでしょうが、webaudio-controlsに含まれるwebaudio-knobに、完全に同じ機能が含まれています

これはどうやってARIA用にこういう画像を作るのかを調べていて割といろいろびっくりしたんですが、そもそもwebaudio-controlsを開発しているg200kgさんがKnobManというこのKnobコントロール画像を作成するツールの開発者で*3、これを使えばgimpとかでがんばって手作業でこういう画像を加工する必要はないわけです(最近はWebKnobManがメインらしい)。そもそもKnob Galleryに膨大な数のフリーKnob素材があるので、自分でゼロから作る必要はあんまり無さそうです。

もうちょっと調べてみると、KnobManの使い方はNative Instrumentsのフォーラムでも議論されていて、要するにこの画像フォーマットはもともとKontakt(たぶん)で決められていて、KnobManはそれを簡単に作るために作られたツールであって、ARIA GUIKontakt用音源のデータと同じ画像を再利用できるようにしたものっぽい、ということが把握できました。完全に謎のエコシステムが出来ている…!

ともあれ、当初予想していた以上にwebaudio-controlsを使ってUIを実現するというアイディアは的を射ていたことがわかりました。

ちなみにaria2webで使っているwebaudio-controlsのコードには少し手を加えてあります。具体的には、knobのサイズが不明な場合でも元画像のとおりによろしくやってくれるように変更しています*4XSLTで任意のARIAから変換してwebaudio-knobを生成している自分としては、画像のサイズがわからないので指定できないわけですが(これがXSLTでなければ画像をロードしてサイズを取得するだけなので瞬殺…)、webaudio-knobではサイズ指定がない場合はデフォルト値(120pxかなんか)で描画してしまうので、当初は常に変なサイズで描画されてしまう問題で悩みました。

なぜWeb AudioでもないのにWeb UIなのか

ここから先は現在も開発中なのですが、aria2webはそもそもオーディオプラグインのUIとしてARIAを流用するのが目的なので、活用するにあたってはこれをLV2やVSTのようなプラグインに統合することになります。最近ではどのプラットフォームにもWebViewがあるのでそれを使えば十分可能だろう、というのがわたしの理解でした。でした…とは!? この詳細は「Part IIに続く」(!)

…なのですが、もう少しこの設計について書きます。

先日も書いたのですが、LV2オーディオプラグインGUIの世界はバベルの塔が崩壊した状態で、各種のGUIフレームワークに分かれていて全部をサポートするのが難しい状態です。前回はsuilを紹介しましたが、suilでも解決できない課題があります(Part IIで書く)。

WebテクノロジーでUIを構築するというのは、この問題を解決するひとつの手段として考えたものです…というのは半分ウソで、そもそもWeb UIを使おうと思ったのはAndroidiOSのような特殊な世界でプラグインUIをどう構築するかという課題への解決策として思いついたものでした。つまりWeb UIならホスト側アプリでもロードできる、というわけです(詳しくはここで)。

いずれにしろ、ローカル環境を問わずにUIをホストする、一部で「ガワネイティブ」と呼ばれる技術が、オーディオプラグインUI開発の裾野を広げたり、あるいは一般的なアプリケーションのUI開発手法に近づけるために、有用だと思っています。個人的にはオーディオプラグインUIの開発手法は10年遅れている、juce_gui_basicsに技術投資する時代ではない、くらいの認識でいます。もっとも、ここは実のところ要件次第のところがあって、オーディオ処理ほどではないが演奏者が違和感を感じない程度に可能な限りレスポンシブに動くUIにはネイティブコードが最適でしょう。ただこれは設計次第なのと過渡的な問題だと理解しています。

ちなみに、この観点で紹介しておくべきものとして、JUCEのGUIをReactで開発できるBlueprintがあります。BlueprintはWebViewを使うのではなく、JUCE用のrendererを提供するreconcilerの実装になっている、すなわちもうひとつのReact Nativeのように振る舞っている、というところが特徴です。つまり、Reactのやり方で構築したUIが、JUCEのネイティブコンポーネントとして動作することになります。

これはこれでスマートなやり方なのですが、あくまでReact資産があったり、React開発でゼロから構築することを前提としないと難しいです。今回はwebaudio-controlsを使っていて、これは内部的にWeb ComponentsやSVGをDOMも含めて活用して実装されているため、React化するという選択肢はありませんでした。Blueprintはreconcilerを自前で実装していて、YogaやDuktapeを組み合わせて実装していてissuesを眺めてみてもそれなりに未実装の部分がいろいろあることがわかるので、あくまで出来る範囲のことをやる方針プロジェクトと理解しています。自分にはむしろCordovaやIonicのやり方が必要となったわけです。

今回は試験的にVue.jsを使っていますが、無くても良かったというレベルなので、今後依存関係として邪魔だな…となったらたぶん消します。(試験的なプロジェクトなので、ライブラリを開発している時みたいに「余計な依存関係はなるべく減らして…」とかは考えてはいません。)

ローカルプラグインからの利用については、Global空間に適当なWebViewからのフック用のJSオブジェクトを用意しておいて、webaudio-controlsからの操作通知はそこに送るように作ってあります。現在開発が進んでいるローカルのプラグインではこれでイベントを受け取っています。

ちなみに(言うまでもないかもしれませんが)Web上のデモはGUIのみです。音は出ません(デスクトップでも「まだ」音は出ませんが)。というのは、SFZサウンドフォントは大規模なものだと1GBにもなるような巨大なデータであるため、Web上環境には現状馴染まないためです。ダウンロードしてWeb Storage APIで格納するようなソリューションは実現可能かもしれませんが(あとはWeb Audio Pluginsと組み合わせたりとか)、個人的には現状あまり関心が無いです。

後半へ続く

本当は1回で全部まとめるつもりだったのですが、HTML化の部分だけでかなり長くなってしまったので、オーディオプラグインに組み込む部分はPart IIとして書きます。そもそもまだ出来ていないしな…!

*1:特定のキーのノートオンによって楽器のモードを切り替えることができる。ギターの奏法などで便利

*2:W3Cアクセシビリティ関連仕様であるWAI ARIAとは無関係です。

*3:webaudio-knob自体はもともとはagektmrさんが作ったもの

*4:変更が雑なのでgithubにPRを作れていない状態…

LV2のGUIサポートのトレンドに関する覚書

追記: zrythm作者からいただいたコメントがプラグイン開発者側の最新のトレンドについて詳しく言及しているのでそちらも参照されたい。

目次

オーディオプラグインGUI実装の一般論

一般的に、オーディオプラグインのUIはオーディオ処理の本質ではなく、DSPからは独立して構築できる部品だけど、どのプラグインフレームワークGUIが存在することは想定されている。DSPはリアルタイム処理のサイクルで実行可能であることが要求されるけど、一般論としてGUIをリアルタイムに処理することはできない*1

一般的に、オーディオプラグインはパラメーターやポートで入力を受け取ってDSPの処理に反映する。GUIの操作結果をパラメーターに反映できるようにすれば、オーディオプラグインの機能としては十分だ(パラメーターに反映できない部分はstateとして保存する)。また、一般的にGUIの処理はロジックと分離していることが期待されるが、GUIコードがパラメーターやポートを経由してのみオーディオプラグインの動作を制御する仕組みになっていれば、これは自然と実現できていることになる。すごい。XAMLだけでUIを書いていれば自然にMVVMになります!みたいないかがわしさがチョットある。いずれにせよ、GUI部分はリアルタイムをあまり気にせずに*2、一般的なGUIプログラミングによって実現することになる。*3

一方で、一般的なGUIプログラミングと同じということは、プラットフォームの壁が問題になるということでもある。VSTにはVSTGUIというGUIツールキットがあり(もちろんWindows APIを直接使うこともできる)、AUの場合は最初からApple OSでしか動かないのでCocoa (Touch)が使えることが前提にあると考えられるが、LV2については標準的なGUIツールキットは存在しない。LV2はクロスプラットフォームが前提だし、LinuxだけでもgtkとQtだけでも勢力が二分しているし、他にもX11ベースのツールキットがいくつか存在する(JUCEやWDLもそうだし、FLTKやその他GL系のソリューションもある)。これらを全てフレームワーク側が列挙し対応を表明するのは非現実的だし、それは標準的な技術(de facto standardも含む)で行うべきことではない。

LV2 UI feature

LV2では、コア仕様以外は全て拡張機能としてホストから提供したりプラグインで実装したりする仕組みになっている。LV2 UIについても拡張として仕様がまとめられている。

LV2拡張の仕組みを解説するためには本来RDFやらTurtle Syntaxやらも解説しないといけないのでしんどいのだけど、ここでは要点だけかいつまんで説明する。

LV2の拡張機能は全てマニフェストで判別できる。あるLV2プラグインがUI機能を提供しているかどうかは、http://lv2plug.in/ns/extensions/ui#ui のカテゴリの拡張の有無で判別できる。筆者が開発しているUIありプラグインを例として挙げると:

<https://github.com/atsushieno/aria2web>
  a doap:Project, lv2:Plugin, lv2:InstrumentPlugin ;
  ...
  ui:ui <https://github.com/atsushieno/aria2web#ui> .

<https://github.com/atsushieno/aria2web#ui>
  a ui:Gtk3UI ;
  ui:binary <aria2web-lv2ui.so> .

という感じだ。

doap:, lv2:, ui:プレフィックスで本来は名前空間宣言も載せるべきなのだけど、少しLV2プラグインを開発してみればこれらはほぼ自明なのでここでは省略する。これはlv2:Pluginである(かつdoap:Projectlv2:InstrumentPluginでもある)https://github.com/atsushieno/aria2webというオブジェクトに、ui:uiプロパティとしてhttps://github.com/atsushieno/aria2web#uiというオブジェクトを設定している。後者のオブジェクトはui:Gtk3UIで、aria2web-lv2ui.soというui:binaryに実装が含まれている。

LV2 UI拡張の中では、このGtk3UI以外にも以下のようなプロパティが定義されている:

  • WindowsUI
  • CocoaUI
  • X11UI
  • GtkUI
  • Qt4UI
  • Qt5UI

ひとつのプラグインで複数のGUIフレームワークをサポートする場合は、このui:uiプロパティのオブジェクトを複数定義することになる。

LinuxデスクトップでLV2をサポートするDAWプラグインをホストする場合は、プラグインごとに適切なUIをロードして実装するのが適切なやり方ということになる。Qt5アプリであるQTractorであればQt5UIを、Gtk3アプリであるzrythmであればGtk3UIをロードして使えばよい。

UI拡張API

LV2UI拡張のロード手順はLV2プラグインそのもののロード手順と似ている。共有ライブラリの中にはlv2ui_descriptor()というエントリーポイント関数が定義される。

const LV2_SYMBOL_EXPORT LV2UI_Descriptor *   lv2ui_descriptor (uint32_t index)

LV2UI_Descriptorには、ホストから呼び出され、ホストがUIを制御するために必要な関数などが含まれている。

trydef struct {
  const char *  URI;
  LV2UI_Handle(*    instantiate )(
      const struct LV2UI_Descriptor   *descriptor, 
      const char *plugin_uri, 
      const char *bundle_path,   
      LV2UI_Write_Function write_function, 
      LV2UI_Controller controller, 
      LV2UI_Widget *widget, 
      const LV2_Feature *const *features);
  void(*    cleanup )(LV2UI_Handle ui);
  void(*    port_event )(
      LV2UI_Handle ui, 
      uint32_t port_index,   
      uint32_t buffer_size, 
      uint32_t format, 
      const void *buffer);
  const void *(*    extension_data )(const char *uri);
} LV2UI_Descriptor;

ここでinstantiateで渡されるwrite_functionは、プラグインUIコードがユーザーからの入力をプラグインのポートに出力する時に使う。

LV2UI拡張には、他にもhttp://lv2plug.in/ns/extensions/ui#parentという拡張がある。上記のextension_data()にこのURIを渡すと、ホスト側でプラグインのUIコンポーネントの親コンポーネントが返ってくる(拡張なので、あくまでホストがサポートしている場合に限る)。ホストとプラグインのUI拡張は、これらを使えば最低限の制御が可能だ。この基本的なインターフェースには、GUIフレームワークに固有の部分が何ら存在しないというのがポイントだ。

GUIフレームワークのミスマッチ

オーディオプラグインユビキタスに提供するのは困難な仕事だ。Windowsだけ、Macだけという開発者が多い中、Linux版も頑張って提供する開発者は多くはない。オーディオ処理はクロスプラットフォームで記述できることが多いが、GUIはそうもいかない。なのでJUCEが幅広く使われることにもなるし、VSTGUIなどでクロスプラットフォームで実装することも出来るわけだが、それでは足りずGUIフレームワーク固有の機能を使って実装したい場合も多いかもしれない。

しかし…実のところ、そんな立派な目的でGtkやQtを使っているわけではないことも多いだろう。LV2はLinuxで使われるだけだし、自分の使っているArdourやQTractorで使えれば十分…という開発者は、自分の環境で使えるUIだけ提供することになるだろう。

実際、筆者が開発しているWebViewベースのプラグインUIはwebkitgtk3を簡単に使えるライブラリを使っている都合上、Gtk3UIしか提供できない。Qt5UIを提供するにはQtの使い方を勉強して、Qt5WebViewなどの使い方を調べないといけないし、とてもできるとは思えない*4X11UIを提供するにはもうCEFでも使って再実装するしかない。

もちろん、これはプラグインだけでなくホスト側についても言えることだ。QTractorはQt5UIだけをサポートするしArdourはGtkをホストするのみだろう。つまり実際にはこんな感じになる:

これで最終的に何が起こるかというと、DAWフレームワークでサポートされていないプラグインUIは表示されないことになる。ただでさえ狭いLV2プラグインの世界がさらに分断されているのが現状だ。また、プラグインのエコシステムがGUIフレームワークから切り離せなくなると、GUIフレームワークを乗り換えたり、新しいものを使っていく(たとえばFlutter on Desktopとか)といったチャレンジが難しくなる。

LV2はUIが無くてもポートの定義だけでもそれなりにパラメーター入力が可能なので、困らないことはそれなりにある。たとえば次の画面はsfizzをzrythmでロードした時に表示されるダミーUIだけど、ちゃんとファイル名まで渡せるようになっている。

f:id:atsushieno:20200510103512p:plain
sfizz on zrythm

QTracktorでも似たようなしっかりしたUIが出るし、VSTAUでもある程度は可能だろう。内部的にはプロパティグリッドを作っているようなものだ。しかしWindowsMacに比べて恵まれていない状況にあることは間違いない。

suil

プラグインUIの分断状態は好ましくないが、幸い解決困難な問題ではない。というのは、プラグインプラグインUIのインターフェースはLV2 UI拡張の規定する範囲に限られている。それであれば、他のGUIフレームワークに基づいてLV2 UIの機能を「ラップ」しつつ、ホスト側には対応するフレームワークに基づく情報を渡すような仕組みがあれば、どんなホストであっても任意のフレームワークGUIを呼び出すことが可能になる。プラグインのラッパーとおなじような発想だ。

これを実現しているのがsuilというライブラリだ。

gitlab.com

suilは自身がX11/Qt5/Gtk/Gtk3のLV2UI_Descriptorの内容をロードしUIホストのように振る舞い、X11やQt5やGtk3のプラグインホストが必要とする情報をホストに渡すことができる。suilがサポートするUIをホストする部分が整っていれば、ホスト側は比較的簡単にnon-nativeなプラグインGUIもサポートできるようになるというわけだ。

suilはLV2の開発者(標準仕様のように扱われているが、これを規定しているのは1人の開発者だ)が自ら開発していて、lilvなどと同様、半ば公式SDKの一部のような存在となっている。

ソースの構成を見れば、これがどういう泥臭い仕事をしているかがわかる:

f:id:atsushieno:20200510103540p:plain
wrappers in suil

前節では次のように書いたのだけど

QTractorはQt5UIだけをサポートするしArdourはGtkをホストするのみだろう。

これは実はウソである。数日前にリリースされた最新版のQTractorは、このsuilを組み込むことで、GtkUIとX11UIもサポートするようになったので(リリースノート参照)、いずれパッケージされて各種distroで使えるようになるだろう。それまではウソではない。

Gtk3サポートの課題とexternal UI

suilは銀の弾丸ではなく、ホストと繋ぎこむ部分はまだまだGUI種別ごとに面倒を見てやらなければならない。suilのAPIを使えばある程度問題が緩和できるということにすぎない。また、suilが直ちに全てのGUIフレームワークをサポートできるようにするわけではない。たとえば、最新版のQTractorでもGtk3はサポートされていない。コードならこんな感じでGtk3だけ見当たらない状態だ。

LV2 UIのドキュメントでは、X11UIについてはX11Windowをparentとしてホストから渡すことが想定されている書き方になっているが、Gtk3についてはGtkWindowを渡すとは書かれていない。実際、zrythmがGtk3UIに渡すのはGtkEventBoxになっていて、整合性が無い。zrythmがGtkEventBoxを渡しているのにQTractorがGtkWindowを渡すようになってしまうと、これはややこしい非互換問題になる。想定される挙動が不明なので、QTractorではまだサポートされていないのだろう。

このあたりでやや反則的に特別扱いされているのがCarlaなどを公開しているkxstudioで、zrythmも最新のQTractorも、kxstudioの名前空間を含むUI拡張が定義されていると "external UI" モードになって、独自のアプリケーションループを回す存在として処理されるようだ。

筆者のWebViewベースのプラグインUIも、使っているライブラリがGtkWindowを返すためにzrythmでGtk3UIとしてまともに動作しないので、このexternal UIモードで動作させたいのだけど(それで動くのかどうかはわからない)、LV2 UI標準に含まれていないので困っている状態だ。とはいえ、もともとLV2には存在していてむしろdeprecatedになったものらしい。zrythmが内部的に定義しているexternal UIの型などを見る限り、show/hide/runくらいしか定義されておらず、これではロジックとUIの分離が実現できていなかった、といった当たりの事情で廃止されたのだろう。

いずれにせよ、この辺りはどうやら未整備で、今後状況が変わってくるポイントかもしれない。

まとめ

LV2はGUIフレームワークに依存せずにプラグイン本体を制御するために必要な情報をRDFマニフェスト(ttl)に記載しているので、GUIプラグインの役割を自然に分離できているし、suilのようなラッパーを作って複数のUIフレームワークをサポートすることも可能にしている。もっとも理想と現実の間にまだギャップがあって、Gtk3サポートみたいな部分がこぼれ落ちることがある。この辺は2020年に現在進行形で起こっている出来事であり、近いうちに解決されていく可能性も十分にある。

*1:マルチスレッドで動作するGUIがすでに非現実的で、さらにそのうちのひとつがリアルタイムで排他処理を伴わずに一貫した状態をDSPに提供できなければならない

*2:プラグインのデータを変更する時にatomicな更新を心がける必要があるかもしれない程度だ。これはプラグインによる

*3:2020/5/10追記: 実のところこれはやや過度に一般化しているフシがあって、ホストからのウィンドウ表示への対応など一般的でない考慮事項がちょいちょいあるのだけど、今回はそこは主な話題ではないので割愛したい。

*4:難しくて理解できないという話ではなくて、他にやるべきことがいくらでもある