いつものやつです。今月は割と短めですが、(最後にも書いてるけど)他にやらないといけないことがあるので時間かけてません。
aap-core 0.7.5 / aap-lv2 0.2.5 / aap-juce 0.4.5 released
先月は大幅な機能改善がまとまってきたのと、GitHub Actions設定の統一、Wikiの整備、開発版配布用にAAP APK Installer…といろいろ準備できてきたので、満を持して(?) AAPの関連リポジトリの全てでリリース作業を行いました。全部で25リポジトリ近くあるので、0.7.4リリース作業は1週間くらいかかっていたと思いますが、今回はほぼ24時間くらいで完了しています。やっていることがビルドエンジニアっぽい…
リリースノートはGitHub Discussionsを使ってまとめているのですが、ここに書いていくのはそのうち変えたほうがよさそう…
ちなみにビルドはほぼ落ち着いたと思っていたのですが、今月に入ってからlibs.versions.toml
を使ってバージョン管理するようになったりしていて、*.jucer
ファイルを変更する必要が全くなくなったのが割とインパクトあります。libs.versions.toml
はテンプレートプロジェクトから同じ内容のやつをコピーするだけで足りるので楽ちんです。
docs: AAP FAQ & Contributing
今月は新しく2つAAPのドキュメントを整備していました。
- https://github.com/atsushieno/aap-core/wiki/FAQ
- https://github.com/atsushieno/aap-core/wiki/Participating
特にFAQは割と大作になっています。設計思想の話とか立ち位置とかいろいろ言明しておくべきところがあるので…(プラグインフォーマットを新しく作るというのは割と攻撃されうる)。後者は先月書いて出すのを忘れていたというのは内緒…(!?)
AAP GUIの実験的実装
月初にAAP 0.7.5をリリースして、ちょっと実験的な機能に手を出したくなったので、今月は長らく着手できなかったGUI拡張に手を付けてみました。GUIサポートにはいくつかの前提があり、もともと一筋縄ではいかない想定ではあるのですが、実装してみないと見えてこない課題もあるので、GUIを表示するPoCを作っていました。
これも設計を割と長めにまとめてあるのですが、まだ過渡期なのでどんどん変わっていく可能性があります。現時点では2通りのシナリオが途中まで実装されています:
- Web UIをホスト側で表示してホスト側でUIイベントを受け取る: Binderでの
process()
送信時にはMIDIバッファ(等)にイベントがソート済みで格納されている - System Window Alertの特権を無理やり使ってプラグインプロセス側で表示する: イベントはネイティブで受け取って、(1)
activate()
が呼ばれている状態であればprocess()
が呼ばれたタイミングでホストからのリクエストとマージして処理する (2)activate()
が呼ばれていない(あるいはdeactivate()
が呼ばれた)状態であれば、非リアルタイムループで即時処理してもらう(あくまで実装が自主的にやることであって、プラグインフォーマットとしては「お任せ」状態)
実際にはこの他にプラグインのActivityを起動してプラグインのインスタンスIDを渡してGUIを表示させるアプローチが考えられます。Android 12L以降のFoldablesなどでActivity embeddingを利用する場合も、Activityを再利用するアプローチになるでしょう。
この実験の過程でJUCEプラグインのMain ActivityをAAPのデフォルトUIにする実験もしてみたのですが、JUCEの実装の内部で勝手にJuceActivityを起動する仕組みになっているので、JUCEの問題をそれなりに抜本的に手を加えて修正しないと実現しなそうです。
ホスト側でプラグインのandroid.view.Viewを表示するためにはSystem Window Alertのユーザー許可が必要になるのですが、これはRuntime Permissionに属さない特殊なパーミッションで、Settings経由でユーザーに許可してもらわないといけないやつです。正直これを使うアプローチはあまり推奨したくはないです。一方でこれが一番簡単に実装できそうなやつなので、水が低きに流れるだろうな…という気はしています。
AAPのGUI実装はAndroid固有のものになるので、クロスプラットフォームを意識する必要がない部分では楽ですが、他のプラグイン拡張機能とは使い方も異なるものになりますし、Androidの流儀に沿ったUIサポートを実装しなければならないという意味では、AUv3に近いプラグインフォーマットだといえます。実のところAUv3はMIDI 2.0をネイティブでサポートするプラグインフォーマットとしてもAAPと似ています。
GUIを表示したり破棄したりする仕組みは作りましたが、そこからイベントをDSPに反映させる部分を実装するためには、いろいろ設計・実装しないといけない部分が多く、まだ実現していません。むしろその部分を実装する前に、オーディオバッファ操作APIのイマイチな部分などを修正したりしていて、まだ基盤をいじる作業を抜きにGUIの実装を進めるのは無謀だなあと思っています。
new plugin ports
今月はPeakEaterをaap-juceに移植しましたが、これはプラグインとしてはシンプルで特徴的なものではありません。これは「このくらいのプラグインなら移植作業を録画してみて、うまくいったら参照できるようにしよう」と思って着手したものでした。動画はGoogle Driveに上げたものをリポジトリからリンクしてあって、実際60分程度でひと通りの移植作業が完了することは示せたので、もう少しちゃんと解説動画っぽく作れたらYouTube等にも上げられると思います。
あとSEELEというJUCEプラグインも移植しましたが、これは完全にネタとしてやったやつで実用性はほぼ無いです。
今月は他にもいくつか移植を試みたやつがありますが(たとえばsurgeとか試してる)、ちゃんとAAPとして使えるところまで持って行ってないので公開はしていません。
music tech meetup: LT meetup
3/3にやるのですが、現時点でLTが全然集まっていないので、自分がしゃべらざるを得ない状態になっています。この話は別途書いて出そうかと思います。ちなみに自分のトピックはこんな感じです。