1月の作業記録 (2021)

恒例の自分用作業記録です。これが自分用でなくなる日は来るのだろうか。

making aap-juce hackable again

aap-juceはandroid-audio-plugin-frameworkからJUCEプラグインの移植が無駄に大きくなりそうだったので切り離して作られたリポジトリですが、これも昨年末の時点でGitHub Actionsでビルドを全部通すのに3時間かかる有様でした。これ以上は増やせないし、それでも移植できていたプラグインはほんの5本くらいで、各種の機能のproof of conceptとなっていないといけないのに、これ以上は増やせないというのでは困るわけです。また全サンプルが同じリポジトリにあると、本体の変更を即時全てのサンプルに反映する必要があり、これが開発の妨げになっていました。

そういうわけで、この際、新しいプラグインを移植する作業をテンプレ化できるようにするというタスクの消化も兼ねてリポジトリを分割しました。

ある程度は新規プラグイン移植タスクをテンプレ化できていたので、リポジトリの分割はまあまあ早く実現できたのですが、GitHub ActionsでAndroid Studio Canaryが前提とするAndroid Gradle PluginとCMakeの相性が悪い問題などがまあまあハマりどころでした。ちなみに今でもGitHub Actionsの問題が原因でOSXビルドが出来ない状態です。

リポジトリを分割したら収拾がつかなくなるという状態はなるべく避けたかったので、aap-juce-worldというリポジトリを1つ作って、最終的にはそこでリリースバージョンのようなものをまとめることにしました。これが従来のaap-juceリポジトリに近いものになっています。ビルドが5時間くらい、ダウンロードできるapk群も700MBを超えるレベルなので、スケールしなさそうではありますが、そもそもOSSで公開されているJUCEプラグインもそんなに数多くは無いし、あるものを全て取り込むわけでもないので、まあしばらくはもつんじゃなかろうか…

あと、ビルド時間を短縮する手段として検討しているのが、JUCEのライブラリを共通化してCMakeでビルドするアプローチですが、そもそもCMakeサポートが実現できていなかったので、まずCMakeサポートを実装してみました…というところからスピンアウトしたのが前回のエントリーです。

とはいえ、そもそもCMakeを使っているJUCEプラグインがほとんど無いのが現状です。前回のエントリーを書いた時点でwitte/Eqを移植していましたが、1つだけだと移植作業のテンプレ化には結びつかず、汎用性が担保できなかったので、もうひとつChowPhaserを発掘して移植しました。

移植してみた感想としては、いったんやり方が固まってしまえばCMakeのほうがずっとシンプルです。Projucer版では、.jucerファイルも（少なくとも現状では）手作業で作り換えないといけないですし、Androidプロジェクト自体がProjucerで保存するたびに消えてしまうので、修正を加えていても安心感がありません。jucerベースで作られているプロジェクトもCMakeで書き換えて移植したほうが早いかもしれません。

最終的に1月には１２件の新規リポジトリが生えました（めんどくさいのでgithubからコピペしてきた）。1つだけJUCEとは無関係のFirefoxアドオンで、もう1つだけaap-juceと無関係の前回書いたJUCE+Android+CMakeの実験用リポジトリです。

10件のaap-juce関連リポジトリのうち、odin2とFrequalizerはProjucerベースのプロジェクトの新規移植、witte/EqとChowPhaserはCMakeプロジェクトの移植（当然新規）です。

とはいえいずれも完動品というわけではなくて、むしろJUCEのAndroidまわりのissueがいろいろあって特にinput channelがまともに取れないのは割と厳しみある感じです。このレベルの問題に今さらぶち当たったのは、これまで移植してきたプラグインが全てInstrumentでEffectではなかったというのが理由なのですが、なぜEffectが増えなかったかというとまさにaap-juceに移植を増やせなかったせいだったので、順当に問題が出現している感じです。JUCEチームは明らかにAndroidには力を入れてないので、自力で直さないといけないことになりそう…。LV2のエフェクトは当然ふつうに使えるので、むしろLV2化して作ったほうが実現可能性は高いのかもしれません。JUCEの今後の出方次第ですね。

一方でodin2くらい大規模なプロジェクトが、さまざまなUI関連コードを殺しながらであっても一応ビルドが通ってデフォルト音色だけでもホストから音が出ている状態なので、ちゃんと本格的なやつも動かせそうなふいんきになってきました。まあ実際にはあの画面をそのままAndroidに持っていっても実用に耐えないので、モバイル向けにUIを作り変える必要はあるでしょう。

来月の方向性

ともあれ、LV2とJUCEの両方が最新のリポジトリ整理で継続的に開発可能な状態になったので、長らく手を付けられなかったUI統合に手を伸ばす機運が高まってきました。ちょうどChrome 87でAtomicsがAndroidでもサポートされるようになっていて、juce-demosに置いてあるプロジェクトがAndroidでも（オプションを有効にすれば）動作することが確認できたので、JUCE側もUIを再利用出来る可能性が十分にあります。今月はjuce_emscriptenの更新も取り込もうとしていたのですが、いまいち上手く行ったかどうかわかっておらず、完全でもないので（DemoRunnerで音は出せているという程度）、JUCEでやるならそこからです。まあJUCEより先にsfizzのARIA統合として作ったaria2webをLV2 UI取り込みの例として使ってみたい気もしています。

本当はUI統合より前に楽曲再生機構としてのaugene（tracktion_engineのフロントエンドプレイヤー）を動作させたいところなのですが（編集UIが出せても再生が出来ないのでは意味がない）、ローカル環境ではともかくGitHub ActionsでAndroid NDKのclang++が謎のクラッシュを起こしてビルドがコケる状態なので、手を付けられるところから手を付けたいと思います。いずれにしても、ここしばらく主な作業対象がCMakeとMakefileとビルドスクリプトばかりで、その前も原稿とか書いていたので、全然プログラムを書いている気がしなくて良くないので、来月こそはコードを書きたいですね。