3月の活動記録(2021) - ものがたり

3月の開発記録です。長くなってしまったので分割して、こっちは「その他」編です。

VST3とSFZ探訪

2月にリリースされたWaveform 11.5がLinuxでVST3をサポートするようになりました。これによって、昨年10月で書いていた、プラグインをtracktion_engineとWaveform11.5の間で共有できなかった問題が、VST3によって解決したことになります。そういうわけで、3月はVST3プラグインをいろいろ試していました。これはまとまった時間ができたら何かしらアウトプットを出したいと思います。（まだ無い状態）

ただ、Waveform 11.5 (on Linux) はまだまだオーディオエンジンが不安定で、トラックが10本を超えた辺りから（多分あまりプラグインを問わず）頻繁にクラッシュするようになるので、打ち込み作業での実用性はまだまだ覚束ないところです。

3月にはもう一つ嬉しいニュースがあって、Linux版のReaperがなんとLV2プラグインを使えるようになりました。LV2はクロスプラットフォームで利用できるように設計されているので、これはいずれMacやWindowsでも使えるようになるかもしれません。

2月にはVitalが公開されたこともあり、シンセプラグインはそれなりに選択肢が出てきたのではないかと思っています。サンプラーのほうもバラエティを広げておきたいところです。エンジンはsfizzが最有力候補だと思っていますが、こちらもVST3版の開発が進んでいて、Waveformからも直接ロードできるようになっています。半年くらい前からLV2 UIの開発が進んでいたのですが、これはvstguiで作られており（vstguiはGPLv3ではないので気軽に使えるのです）、VST3版でも自然に同じものが組み込まれています。

sfizzはv1.0まではSFZ v1を主なターゲットとしていますが、SFZ v2やARIA独自拡張命令なども一部実装されていて、最近のバージョンではkeyswitchなどもサポートされるようになりました。その結果、たとえばUI METAL GTXのようなkeyswitch前提の音源もロードしてある程度期待通りのサウンドが生成できるようになっています。実用性がどんどん上がっているので今後も楽しみなところです。

aap-lv2-dragonfly-reverb

Dragonfly-Reverbはgithubで公開されているリポジトリの中では人気の高いリバーブエフェクトで、LV2とVSTがサポートされています。dragonfly-reverbのもうひとつ大きな特徴としては、このプラグインはDPFで実装されています。DPFはLV2をサポートしているので（そのために存在するようなものなので）、これをAAPに移植できればDPFもサポートできたということになります。DPFによるVSTサポートにはVST2SDKではなくVeSTigeが使われているので、2021年でも誰でもビルドできます。

VSTをいろいろ探す作業の一環として、利用可能なプラグインで楽曲のテンプレートを作っていたのですが、Dragonfly-Reverbはリバーブの中ではかなり有力な選択肢なので、Waveformで打ち込んだものをAAPでAndroid上で演奏しようと思った時に使えるようにしておきたいところです。

DPFはビルドシステムらしきものがMakefile前提で作られており、sfizzやfluidsynthのようにCMake前提でビルドすることはできません。そのため、mda-lv2やguitarixのようにandroid-native-audio-buildersリポジトリでAndroid用にビルドするやり方で対応しました。ビルド自体はスムーズに実現できたのですが、プラグインの挙動自体がまだ期待通りではないので、いずれtweakが必要になるでしょう。

https://github.com/atsushieno/aap-lv2-dragonfly-reverb

AAP: Compose UI and audio preview in plugin apps

2月までの実装では、AAPのプラグインアプリに付属のMainActivityが立ち上がるとプラグインのリストと、それらを選択するとポートリストを表示する機能が伝統的なUIで実装されていました。3月はJetpack Composeのfirst betaがリリースされたこともあって、ComposeをAAPに適用するには悪くないタイミングです。というわけで、まずこのUIをJetpack Composeで実現するところから始めました。Composeはこの時点でmainブランチに取り込まれていなかったのですが、本格的にComposeにコミットしていく流れになったと思います。

もともとのUIも単なるプラグインとそのパラメーターのリストなので大したことはないので、ついでにホストアプリケーションのサンプルで実装していたオーディオ出力のプレビュー機能を、プラグイン側にも実装することにしました。もともとUIの大部分が再利用の産物だったので、ホスト側のオーディオ処理をモジュールとして独立させて共有してしまいました。

プラグインアプリ内で利用できる機能として実装したことで、デバッグ作業も少し楽になりました。（インプロセスでオーディオ処理できているわけではないので、あくまでデバッグが楽になった程度です。）