あたし5月って苦手なのよね…無駄に爽やかだから…あと天気が変わりすぎて肌荒れしちゃうし。
戯言はさておき、5月に読み書きしていたコードの話を雑に書きます。
JUCE/VST3
VST3まわりをいじって音が出せるようになっていたJUCEですが、とりあえず試しにtracktion_engineで使われているやつでパッチビルドを使ってみたらちゃんとPlaybackDemoで再生するところまでいけたので、これだけでも使いたい人はいるかもしれんと思って結局PRにして投げるだけ投げました（ROLIはPRを受け取らないと表明しているはずですが）。
VSTまわりを少し調べてわかったのですが、AudioPluginHostでmda-~なプラグインのUIが表示されるのは、VSTGUIをサポートしていない場合にJUCEがVST3プラグインのパラメーター情報などをもとに最低限?のUIを表示しているようです。おそらく同じことが「VST3をサポートしている」Bitwig Studioについても言えるのではないでしょうか。VST3で作成されたプラグインとしてLinux上でGUI表示までサポートしているものを知らないので（何しろVST3をサポートしているホストを日常的に使っていないので!）、VST3に深入りすることがあればもう少し調べてみるか…みたいなステータスです。個人的にはGUIに行くより前に調べることがいろいろあるので…
LV2, lilv, lilv-sharp
VST3方面が（主にupstreamが）あまり芳しくないので、5月は少し方向性を変えてLV2を調べたりしていました。LV2というのはLADSPA v2のことです。要はLinuxネイティブで動かせるプラグインに手を出しておこうと思ったわけです。実のところLV2はLinux方面でもそんなに使われていないので、こっちに手を出す意味がどれくらいあるかは怪しいところですが、今知っておけば日本の第一人者に近い立ち位置になれるなーというお気持ちで調べたりしています。
個人的には、Chrome OSのLinuxがALSAをサポートし始めた2019年から、米国の教育機関ではマーケットシェア60%にまで至るこのOSで動作するオーディオプラグインをサポートする流れは確実に出来ていくだろうと思っているので、この辺に手を出すなら早いほうがいいと思っています。
そんなわけでLV2ですが、（おそらく日本で知ってる人はほとんどいないと思うので）ゼロから説明しないと分かってもらえないところだとは思うのですが、これを真面目に説明しようと思うと中で使われているRDFやらTurtleやらいろいろめんどくさいところから始めなければならず（この辺が参入障壁を無駄に高くしている要因だと思う）、このエントリでそこまでする気には到底なれないので、いずれ暇を見て何か書くと思います。
とりあえず、いま興味があるのはオーディオプラグインのホスティング方面なので、LV2のホスティング実装であるところのlilvで遊んでいます。lilvは純粋なCライブラリなので（LV2のエコシステム自体が割とそうなっている）、C#バインディングを作ったりしていました。P/Invoke部分は例によってnclangを使ってほぼ自動生成です（ちょいちょいコマンドラインオプションでごまかしている部分がある）。
nclang/generated-natives
lilv-sharpを作っているときにnclangをいじっていて気付いたのですが、MSにもClangSharpというclangのバインディングがあって（これ自体は知っていたのですが）、nclangと同様にPInvoke自動生成ツールが付いているんですね。ClangSharpはそれ自体がlibclangのバインディングをコレで生成していて、dogfoodingとしてはなかなか良いと思うのですが、nclangでもそういうブランチを作って移行してみようと思った結果「これはあんま意味ないな…」となって放置しています。libclang自体はAPIに後方互換性があるので現状ほとんど困らないですし。むしろClangSharpは自動生成APIを用意しているだけで、生成されたAPIが.NETらしく便利に使えるものになっているとは言い難いので、ClangSharpは使わずにnclangを使い続けようと思いました。
.NET開発はほぼ継続不能状態
ただ、最近はそもそも.NET開発をほとんど中止している状態です。というのはmsbuildのLinuxパッケージングが全然まともにメンテされていなくて使い物にならないからです。実際にはdotnet/source-build（dotnet関連プロジェクトのビルドに使われているビルドツール）の細かい問題と、msbuildのスクリプトが参照できないアセンブリを見に行って失敗する問題と、msbuildのビルドにバンドルされているRoslynがちょっとしたプロジェクトのビルドでも簡単にクラッシュしてビルド自体が続行できないようなレベルになっている問題など、いろいろ累積的で、.NET Coreチームがまともに仕事していないことに起因しているのですが、とりあえず諸方面で状態を問い合わせるだけでうんざりしたので、ビルドが正常化するまで放置することにしました。MSBuildが開発のエコシステムに食い込んでいなければMSBuildを捨てればいいだけの話なのですが、Riderとか使っているとビルド時にはMSBuildを呼び出すんですよね…
https://github.com/atsushieno/managed-midi/issues/42
あと開発を単純に放置できる話であればよいのですが、MIDI関連ツールはわたしが日常的に使っているものなので、こんなリスクをかかえたまま開発を継続することはできないので、他の作業が落ち着いたらC++にでも移植することになると思います。managed-midiの一部はKotlinに移植済なのですが、unsignedがまだ標準でサポートされていないKotlinで開発を継続するのはイマイチだなと思って躊躇しているところです。CLionのKotlin/Native・MPPサポートも特にライブラリ開発に関しては現状ほぼ無いので。
幸いなことに、modern C++はそれなりに面白そうなので、C#とあまり変わらないノリで開発できるんじゃないかという気もしています。C#でもP/Invokeとの絡みでリソース管理を細かく気にするようなコードばかり書いていたので。むしろC#のほうがいろいろpinnedにしないといけない分かえってめんどくさかったりして。lilvのPoCコードを書いているときも、lilv-sharpではこの関連で無駄にいろいろハマりました。lldb + monobt.pyでデバッグしてもいろいろ実行時情報不足だったりするし…。この辺C/C++でPoC書いたら1日で済んだので、最初からこっちでやろうと思うようになりました。
反省と展望
そんなわけで今後はC/C++方面に進んでいくんじゃないかなと思っています。知らんけど。
6月こそはもう少し音楽打ち込み作業に時間を確保したい…（フラグ）
