COSCUP 2022に登壇するために台湾に来ています。
台湾はまだ観光ビザで訪問できないので、就業金卡というビジネスビザの一種で来ています。ある種の職能スペシャリストビザの一種で、いくつかの条件を満たせば申請が受理される見込みがまあまああるのですが、キャリア年数などのほか年収基準なども150万NTDくらいで、IT技術者（条件のひとつを満たす職種）ならそれなりの収入がある人も少なくないと思います…と書くつもりだったのですが、昨年自分が申請した時に比べて日本円の価値が暴落したので、割と厳しくなったと思います…
周りの外国人の知人は胡散臭い連中だらけだったのに割と漏れなく取得できていて、しかも3ヶ月くらいで取得できていたので、自分も…と思っていたら、承認が降りたのは1年前だったのにその頃にオリンピックのせいで感染爆発が起こって、手続窓口が今年の春先までずっと閉じていて、必要な手続は今頃になって進められたという…いま申請すればたぶん3ヶ月くらいでいけると思うので興味のある人は試してみましょう（滞在可能年数に応じた申請手数料がかかります）。
台湾は三＋四天（天は日数）という入国者隔離政策があって、過去に比べるとずいぶん緩められていて、たとえば自宅隔離が許されていたり隔離タクシーでなくても家族が車で迎えに来たりできるので、わたしなんかは失策だと思うわけですが、今のところBA.5もほぼ阻止できているようです。以前に行き来していたときも事前準備していると割とナーバスになったものですが今回はさらに輪をかけていろいろ気にしながら進めました。特に就業金卡は日本では情報が少ないですし（わたしがもっと書けって話になりそうですが）、日本から出国する日本人のための情報は英語圏でも見つからないですしね…
オーディオプラグイン規格勉強会 (2022.7)
先月も書いたのですが、CLAPという新しい規格…いやホントは昔からあったのですが…が正式リリースされて脚光をあびるようになったので、CLAPの勉強会を開催…する前にそもそもオーディオプラグイン規格全般を調べながらみんなでわいわい討論できる勉強会をやりたい…ということで7/6に開催しました。これについては今月4回にわたってここに連載したものがあるので、それを見てもらえればと思います。これを勉強会のために下調べとして書いていたので（そうするとスライドもまとめやすいわけです）、それでそれなりの時間を使いました（といってもほとんど6月の話です）。
What for, Where and How to Adopt MIDI 2.0 @ COSCUP 2022
7/30に台湾の巨大OSSカンファレンスCOSCUP 2022にて表題のタイトルで「MIDI 2.0の技術はどこで応用できるのか」という話をしました。
MIDI 2.0は今使われているわけでもないし、デバイスもなければOSサポートも無く、MIDI 2.0が実現するのもオーディオプラグインの既存の技術で実現できていることが中心だけど、MIDI-CIを使ってMIDI 1.0のトランスポートの上に成り立つもので、オーディオプラグインがバラバラに実現してきたものがMIDI 2.0によってふたたび標準としてDAWの内部で音楽表現を担う可能性があるものとしての未来を見出してほしい、という内容です。スライドはspeakerdeckで公開してあります。
申込み時に「まあ初歩的な話しか出来んやろ」と思って入門レベルとしていたので、特にコードもデモもなく表層的な話で終わっています。ただもしかしたら開発初心者ではなく打ち込み初心者が来ていた可能性がry（まあ「MPEとか使えばMIDI 1.0ベースの世界でもper-note pitchbendとかできるよ」みたいな話もしたので大丈夫なはず…）
本当はAndroidのオーディオプラグインにもMIDI 2.0サポートを組み込んであるよホラ見て、みたいな話をしたかったのですが、実装のバグつぶしに負われていて「無理はせんとこ…」ってなりました() こっちがうまく動いてもMIDI 2.0クライアント（ktmidi/kmmk）と協調できないと困るし…AAP本体もそうなのですがC/S系のコードになるので面倒くさいところがあります。デスクトップならまだ楽なんですが。
AAPクライアントの再構築
AAPの拡張機能を実装してから、AIDLベースのKotlinクライアント実装ではそれに対応できないのを全面的に再構築する必要があったわけで（先月の続き）、7月はそれを片付けました。
今主に進めているのは新しいポート設計の部分で、現状LV2のTTLのようにメタデータXMLに全部列挙しないといけなくなっているものを、プラグインのコード主体で設定できるようにするものです。LV2 dynamic manifestのように動的にポートを設定したいというよりは、(1)オーディオバスを柔軟に設定できたり、(2)MIDI-CI実現のためのポート動的生成を可能にしたり、(3)オーディオポートのメタデータ記述を不要にしたい（デフォルトでステレオ設定としたい）といった目的です。特に(2)でMIDI IN/OUTを自動生成できるようになると、拡張機能の実装にsysexを使えるようになるので、そこに期待しています。
これを実現するためには、KotlinクライアントのAPIもネイティブAPIもメタデータではなくインスタンスからポートを取得する必要があり、そのためにはJetpack Composeで実装していたプラグインプレビューのアプリもメタデータではなくインスタンスを中心に構築する必要があり…と、いろいろ芋づる式に書き換えることになりました。これは不安定なクライアント（ホスティング）APIなので、まだ表に見えるメリットのある変更にはなっていない感じです。プレビュー機能もまあまあイマイチなので（ホントにテスト用でしかない）、もうちょっとまともな機能と実装がほしいところではあります。ただ、さすがに優先順位が低い…それとは別に、この辺の内部実装をいろいろ書き換えたことでaap-juceなどもさまざまな問題が表出するようになって、バグフィックスばかりやっています。もうちょっと楽しい機能追加やりたいなあ…
あと最近はAndroid Studioあるいはlldbまわりが不安定でデバッガが何も進められなくなったりとか、NDKのバージョン次第でscudoがエラーを返すようになったり（しかも意味のあるメッセージは何も出さない）とか、いろいろツールチェインの問題だらけで開発体験が非常に悪くなっているので、どうにかなってほしいところです。まあどうにか「する」にはオープンソースでないと無理なわけですが、オープンな部分でもまだビルドの全体像を把握しているわけでもないので、気が向いたら掘り下げようと思います（向かなそう）。
