"幻想音楽祭" 出展のお知らせ (+ MMLによる音楽制作の実践)

gensouongaku.info

3/2に川崎市産業振興会館で行われる同人音楽の即売会「幻想音楽祭」に個人サークルとして出展します。オリジナル楽曲のアルバムCD・音楽データDLカード等を販売する予定です*1。サークル配置番号はA-4 "ginga" です。*2

ここを見ている人は大半が開発者だと思うので、ここで告知してもかなり「かぶらない」と思うのですが、個人的には半分くらいは作っているソフトウェアの展示とか、音楽の作り方をどうするかみたいな話に興味のある方に来てもらえればと思っています。イベント自体も初めてのようですし、ぜひ遊びに来てください。

TL;DR

目次

音楽作ってる? は? なぜに?

ここを読まれている人の大半はこんな反応になるかと思いますが（そうでもない?）*3、音楽ソフトウェアの技術同人誌とかではなく、同人音楽CDです。大昔にMIDI音源をいじっていたことを除くと完全に未知の分野なのですが、手探りで辛うじてやっています。

見せて

はい…（抵抗感） youtubeとsoundcloudにうｐしてあります。

youtu.be

soundcloud.com

人知れずひっそり出すか、ずっと悩んでいたのですが、自作ツールのポートフォリオとするためには隠してやっても仕方ないよな…となって、表に出すことにしました。今後は何か作るとしても別名でやるかもしれん…

発端

昨年にもちらっとここで書いたのですが、11月にAudio Developers Conference 2018に参加して、参加者の何人かと雑談していた時にふと「おまいらも自分で音楽を作ったりするの?」と聞いてみたら、返答の大半がYESだったんですね。自分で音楽制作しているわけでもないのに音楽ソフトの開発やら仕事やらにシフトしてみたい、って言うことには、自分でも何か落ち着かないコンプレックスのような気持ちがあったわけです。

それで、一度くらいちゃんと音楽ソフトを使って制作とかやってみて、どういうものが必要で求められていたりするのか勉強してみようと思ったのでした。個人的にはM3とかボーマスとか、何度か行ったことがあるので、とりあえず一度何か同人音楽イベントに参加してみようと思って、それで11月末頃に今回のイベントが申込受付中であるのを発見しました。

「ファンタジー音楽」というのは何となくわかる気がするし*4、第１回だし、右も左もわからない雑魚サークルでも参加できそうな気もするし、参加できたらラッキー…くらいのノリで出来心で応募したら、あっさり通ってしまい、それならやるっきゃない…!と肚を括ったのが12月のことです。

制作環境の決定

参加が決まった時点での方向性はほぼゼロで、出せるコンテンツとしては20世紀の頃に作ったSMFとして作った楽曲がわずかにあるばかり…という状態でした。DAWなどを使ってみたほうがいいとは思っていましたが、経験ゼロのところからちゃんとイベントまでにCDを作るところまでもっていけるのか…!?という感じで、正直ゼロからDAWでやっていたら完成しなかったと思います(!?)

とりあえず、20世紀以来ほとんどやっていなかった「音楽を打ち込む」感覚を取り戻さないといけない…というところからやり直しました。とりあえず当時慣れ親しんでいた楽器であるRoland SC-8820を毎日持ち歩いて自作のソフトウェアMIDIキーボードxmmkで音を鳴らしてみたり、Tracktion Waveform9（面倒なので以降単にTracktionと書きます）を起動して標準添付のCollectiveで音色を探して4小節くらい和音を鳴らして終わり、みたいな感じで、たいへんに雑魚ったところからスタートしました。

ちなみにTracktionだったりCollectiveだったりするのは、わたしの普段使いのPCがLinuxなのでKontaktなどが一切使えなかったためです（Kompleteを9の頃に買っていて、「もっとWindowsがUbuntuみたいに快適に動いてくれたらなあ…」などと言い続けながら、今回Macで使うまで何年も眠らせていたのでした…）。

最初の頃は、Tracktionの操作に慣れる目的で、過去に打ち込んでいたMIDIファイルを、まずはコピー曲などからインポートして、VSTに置き換える練習から始めました。Tracktion、それなりの頻度で落ちるので、Bitwig Studio*5などに変えようかなあ…などとも考えたのですが、この一見風変わりだけどロジカルに出来ているUIがやっぱり好みだったので、今でも使っています。

この時点でわたしが「わかる」と言える音色はSC-8820までのGM/GS音源の音色くらいだったので、Collectiveで音色を選んでそのパラメーターを調整するか、Collectiveにない音（かなりあります…）については、juicysfpluginとサウンドフォントFluidR3_GM.sf2でGMにフォールバックする感じでした*6。ただ、これは早々に行き詰まりそうだったので、SC-8820のフル音色を徹底的に活用してMMLでMIDI楽曲としてまず完成させつつ、その後にWindowsなりMacなりでKontaktなどの音源版を作って移植しよう、とざっくり方針を決めました。

この頃は一方で、ADC2018で持ち帰ったソフトウェア（JUCEやらTracktionやら）の知見を学ぶために*7いろいろコードをいじっていたのですが、それらが「動作する」「Linux以外の」環境が比較用に無いと作業が行き詰まるというところまで来ていたので、仕方なく*8Mac mini環境を構築したのでした。たまたま自宅に10インチくらいの液晶モニターがあったため、以降このMac miniはまるごとモバイル環境になり、電源のある環境でちょいちょい使われています(!)。

Linux環境でMMLで作曲、その後MacのTracktionに移植してマスタリング、という方針がざっくり決まりました。これが年明けくらいの話です。

MML打ち込み環境のブラッシュアップ

ここで改めて言及するのも何ですが、MMLというのは20世紀に使われていたDTMにおける音楽データ制作のツールであって、2019年にしかもLinux環境で使うというのは半ば正気の沙汰ではありません。とはいえ、これを実現するための土台は用意してありました。具体的には、今までこれらを開発していました:

少し前にここ2ヶ月ばかりのコーディング活動について書いたのですが、これは完全にこの音楽制作のためにやっていたことでした（単独のブログエントリとして見ると謎すぎましたね）。音楽制作と言いつつ、それなりの時間がプログラムの改良に当てられています。

2018年末にはVGM作曲家の古代祐三さんが使っているMMLコンパイラツールであるmucom88が公開されましたが、あれも主に自作環境の公開という雰囲気なので、わたしがここで公開しているのと（完成度とポピュラリティは違えど）似たようなノリだと思っています。

制作の勉強

この辺までの作業はツール開発者の視点で楽しく出来ることだったのですが、作曲ばかりは本当に自分のメンタルや創造性とのたたかい…になる側面が強くて、今でも進捗は圧倒的に悪いです。とはいえ、本当はそれなりにフレージングなどのテクニックがあれば進められることなので、勉強次第でどうにか出来るはず（それが足りない）という側面のほうが大きいことでしょう。まあ人間いちどに出来ることには限りがある…!

いくつか参考にした本などを挙げます。

nextpublishing.jp

まず手元にあった「ボカロでDTM入門」（Vocaloidは今回全く使っていませんが）。このエントリを書くために探して改訂版が出ていることに気付きましたが、うちにあったのは初版でした。アルバム（と呼ぶしかなさそうなのでそう呼びます）のテーマ作りみたいなことを考える時に参考になる部分がありました。

今回の制作にあたって、イラストレーターにカバーイラストをお願いするときにコンセプトをでっち上げる必要があったり、曲想が全く浮かばない日々が大半だったので（実のところ今でもそうで日々血涙を流しています）、何とかしないと…みたいな感じだったりで、解決の道筋になりそうなものを探し求めていた（いる）のです。ワタクシどう考えても情緒の豊かな人種でもクリエイティブな人種でもないので…

管弦楽法

管弦楽法

11月頃に、Tracktionでクラシックの管弦楽曲を打ち込もうとしていたことがありました。音楽制作については、職業DTMerの人にいろいろ教えてもらうことがあるのですが、この時に移調譜の読み方などを教わりながら「ピストンの『管弦楽法』を読むといい」と言われ、これを入手して読んでいました。

作業の過程で必要な部分だけつまみ食いで読んでいるのですが、その後KontaktでSession Stringsなどを使って音色を調整する時に、奏法などの未知のキーワードをこの本で調べたりしています。また、GM音源を使っているときにはもやっとしか知らなかった管弦楽器の編成についても、このあたりを知ることで一歩踏み込んで打ち込めるようになったと思います。

www.gcmstyle.com

VSTプラグインをひたすら紹介してくれる同人誌です。コミケや同人音楽イベントでも入手できると思います。CollectiveどころかKompleteを使っていても「あの音色が足りない…」みたいな場面がちょいちょい出てくるので、これを参考にしていろいろな音源を知ることが出来ました。

制作作業

…さて、ファンタジー系音楽、たぶんゲームとかそっち系映画のサントラ的な音楽が出来上がればいいんだろうと考えました。馴染みはあるジャンルなのですが、過去にそういう作品を作ったことは無かったようです（そもそも完成した楽曲と言えるようなものを作ったことが無かった…）。このジャンルならこういうのが好きなので100年後くらいには作れるようになりたいですね…

kai-you.net

今回は過去に打ち込んでいたものを何曲か使い回しているのですが、ファンタジー系というので、何かひとつ大仰なやつをゼロから作ってみたい…!と思って、ある時ちょっと20秒くらい浮かんだフレーズから作り始めました（1曲目）。最終的にはそこまでの大編成にはなっていないはずですが、オーケストラのスタンダードな音色でそれっぽい楽曲が打ち込めた気がします。まあほんの3分くらいなのですが…!　もっとも、MIDIファイル上ではトランペットやトロンボーンが（知見が無くて）音域を逸脱したところまで演奏しているのを、Tracktion上ではSession Hornsにフォローさせている…みたいなところはちょいちょいあります。*10

昔打ち込んでいた自作曲を引っ張ってきたものは、当時プログレに傾倒していた（今でもか…?）こともあって、今回の収録作品には妙な変拍子が多いです（極端なのだと23/8とかあります…）。一方で楽曲の作り込みの甘いところが多いので（テクニック不足の問題…!）、まあ多分こういうちぐはぐなのはありがちですよね…

あとは…不気味な雰囲気の曲も作ってみたのですが（デモ2曲目）、これは全音音階とかを見よう見まねで使ってみました。音楽理論どころかコードも身についていないのはちょっとコンプレックスがあるので、そのうちどうにかしたいですね。

作業は全てgithubのプライベートリポジトリ上で記録されています。gitでこまめにcommit/pushしているので、何ならブランチも作ったりしているので、思いついたアレンジを気軽に試すことが出来ますし、特にMMLは意味のあるdiffが取れるので完全に便利です。Tracktionのほうは、前回のエントリでも書きましたが、tracktioneditファイルはXMLなのでこれも差分が見えます（あのエントリの内容もこの制作作業の一環として行われたわけです）。もっとも、一番知りたいのはオーディオプラグインのパラメーター設定などであって、これはオーディオプラグイン依存のバイナリなので、ろくに比較できませんしdiffで内容を追う時にたいへん邪魔です。

デジタルデータのダウンロードカードによる配布をメインにする予定なのですが、ここには技術同人誌を作成していたときと同じノウハウが使われることになるでしょう。

MMLおよびTracktionデータの公開（予定）

今回のアルバムのソースとなる打ち込みデータは公開する予定です。運良く(?)わたしが使っているSC-8820をお持ちの方は、MIDI版の楽曲をそのままフルで再現できることになります。MMLだけ公開としてコンパイラを使ってほしい…と言ってもいいのですが、多分SMFも公開すると思います。MMLはコンパイラのサンプルとなるので、楽曲はMITライセンスで公開されることになるでしょう。

公開する理由はシンプルで、MMLコンパイラの実用例であることを示し、それによってコンパイラの価値を高めるためです。あと、MMLを公開することには、ソースから知見を吸い取って再利用してほしい、かつてJASRACが「MIDI潰し」を行う以前にあった「古き良きMIDI文化」、ジットレインが「生成的インターネット」と呼んだものを、少しでも取り戻せるように…という思いもあります。

同様に、Tracktionで打ち込んだデータも公開するつもりなのですが、こちらはオーディオプラグインを多用しているので、同じプラグインを全部持っている人にしか再現できないものになるでしょう。このプロプラエタリに染まったデータをどのようなライセンスで公開するかは未定です。Tracktion自体は7まで無料で公開されています。

いずれの版も、「自作MMLコンパイラでここまで出来る」ことを示す、ポートフォリオ的な意味合いがあるので、単独でも聴く価値のある…というと大袈裟なので「破綻していない」くらいの…楽曲を作るというのは重要な目的のひとつです。（という文を書いている現時点で全楽曲が完成しているわけではないので、実のところ今も焦っているわけですが…）

next steps

この自作MMLコンパイラは、少なくとも対象をMIDIとして、21世紀にふさわしい利便性*11をクロスプラットフォームで実現するという目的を実現しつつあると思っています。一方で、音楽制作のメインストリームであるオーディオプラグインなどを活用した楽曲制作の置き換えまでには至っていません。この辺りは完全に別の世界として棲み分けがあるというのが現状でしょう。

DAW全盛期と言うのが相応しそうな現代ですが、ソフトウェアが古臭くなっていく一方で、Web MIDI APIやWeb Audio APIの登場、それらを踏まえたWeb Audio Modulesのような新しい技術*12の登場を考えると、DAWのように「個人ではとても作れない」巨大なソフトウェアを因数分解して、部品ごとに再利用し、打ち込みスタイルも多様化していく時代が来ても良いのではないかと思っています。MMLはその手法のひとつに過ぎず、またMMLの適用先としてDAWと同等の音楽を制作できるオーディオプラグインだらけの世界があっても良いと思っています。

制作過程のところでも言及しましたが、テキスト表現はgitなどVCSとの相性が抜群に良いです。思いついたアレンジをコメントアウトして残しておくのも簡単ですし、加工もそれなりに柔軟にできると思います（まだまだDAWのほうが得意な場面もたくさんありますが）。

そしてオーディオプラグインを利用した音楽制作のシーンは、もっとオープンに行われてほしいし、短期的にはわたしが日々使っているLinuxデスクトップ環境や新しいChromeOSのような環境でもシームレスに行えるようになってほしいと思っています。VST3はLinuxでもビルドできますし、JUCEならLADSPAもいけるし、オーディオプラグインのベンダーにもどんどん参入してもらいたいですね。

この音楽制作が終わったら余裕ができるので、こういう方向性で新しい仕事を探そうかなと思っています。*13

*1:サークル案内にあるように「作り方」みたいな本を出すつもりだったのですが、これはナシかもしれないです…少なくとも電子版になるでしょう(__ あとCDはジャケット印刷が間に合わないかもしれない…

*2:近いジャンルで名前がかぶったのですが、はてなに来る前のアカウント名であってgingaレーベルではないです

*3:最近rebuildfmでこっそり話していたんですよね…

*4:サークルの募集要項を見ると分かるのですが、定義は主観的でもやっとしています

*5:Linux環境で動作するDAWの選択肢は「ある」けどそれなりに限られるのです

*6:サウンドフォントについては、以前からfluidsynthにパッチを送っている程度にはいじっていて使い方がわかるのです。偏った知識…!

*7:特にLinux版JUCEで全くサポートされていないVST3を動かせるように

*8:わたしはPC所有者が自由にソフトウェアを動かすことの出来ないOSを作る会社がきらいなんですよね…

*9:とは言うものの、Mac環境のサポートはまだ新しい方向性で開発が始まったばかりです

*10:逆に知見が無くてもこの辺を使うと何とかなるのか…!という感じでした

*11:まだテキスト音楽サクラに及ばないところがちょいちょいあるのですが

*12:WAMs自体はC++などを前提とした従来のスタイルに見えるので、新しいと言ってしまうと実は個人的には抵抗感がありますが…

*13:とはいえ、私の知る限りそんな仕事は皆無ですし、まだ週休七日でもやれることはたくさんあるので、今のままでも良いのですが。

Tracktion/Waveformに変拍子の含まれるMIDIファイルをインポートして加工する

わたしが最近ひいき目に(?)しているDAWとして、Tracktion社のWaveformを使っているのですが、今日はこのTracktionまわりのhackを紹介します。*1

他所で作ったMIDIファイルをTracktionに取り込む時*2、たまにTracktionの挙動が不審で、予期しない謎の音楽が生成されることがあります。最近わたしが経験したものでは、METAイベントのテンポと拍子設定が入り乱れる音楽を取り込むと、テンポがめちゃくちゃになる（しかも説明が困難なかたちで）というものでした。

f:id:atsushieno:20190212155715p:plain
bogus imports of tempo and time signature

MIDIなんて使ってるやつそんなおらんやろ?と思われそうな気もしますが、Tracktionをはじめ大抵のDAWのMIDIトラックやらインストゥルメンタルトラックやら呼ばれるものは、そして各種オーディオプラグインは、内部的にMIDIメッセージのやり取りで成り立っているので、この辺の問題のインパクトはそれなりにあります。この問題の場合は、テンポと拍子の扱いが「根本的に何かおかしい」可能性があります。

それはそれでせっかくgithubで公開されているのでissueとして登録したのですが、Tracktionを使った作業自体は継続したいわけです。なのでTracktionにはバグレポートしつつ、Tracktionが正常に動作するようなSMFを作って取り込もうと考えました。

バグの原因の探し方

バグの原因については先のgithub issueでちょくちょく追求した結果をコメントしているのですが、まずこの問題はtracktion_engineにも含まれるロジック部分にあるだろうと考えました。DAW上ではエディットを開いている画面でMIDIファイルの取り込みを指示する場面を追いかけます*3。

f:id:atsushieno:20190212151120p:plain
Import an audio or MIDI file

（ちなみにこのスクショはWaveform9で撮ったものなのですが、Waveform10ではこの周辺のUIが微妙に変わっているので、そのつもりで読み進めてください。）

"Import an audio or MIDI file" という項目なのですが、これはOSS化されていないGUIのリソースなのでソースコードには含まれていません。しかし取り込みを続行するとダイアログが出現します。

f:id:atsushieno:20190212151834p:plain
tracktion dialog

このダイアログのメッセージなら出てくるのではないか?と探します。

/sources/tracktion_engine$ grep -nR "Do you want to import tempo and time signature"
modules/tracktion_engine/selection/tracktion_Clipboard.cpp:227:                                                                            TRANS("Do you want to import tempo and time signature changes from the MIDI clip?"),
Binary file examples/projects/StepSequencerDemo/Builds/LinuxMakefile/build/StepSequencerDemo matches

なるほど確かにあります。この辺からこの関数を呼び出しているコードなどを漁っていると、pasteMIDIFileIntoEditという「現在位置にMIDIファイルの内容をペーストする」関数に行き着いて、MidiList::readSeparateTracksFromFile()という関数が実際の解析を行っている部分らしいことがわかります。これが先のgithub issueの最初のコメントでリンクしたコードになっています。C++のコードをある程度読めれば何とかなります*4。こんな感じで問題の箇所をざっくり掘り当てます。

ちなみに、バグの原因を特定できても、DAW全体をビルドできるわけではないので、修正を作ってpull requestを作るところまではなかなか至らないかもしれません。多分tracktion側も外部からのpull requestを受け付けていないと思います（JUCEもそんな感じです）。

MIDIファイルでは、テンポの設定と拍子の設定はMETAイベントとして記述されます。METAイベントは他にもいろいろあるのですが、テンポと拍子は演奏時間にダイレクトに影響する情報なので、MIDI演奏処理系ではこれらを取り出して処理することになりますし*5、Tracktionでもまずこれらのみを抽出して処理しています。

この中で「同じタイミングで存在しているイベントは（処理しても無駄なので）後のイベントだけを処理する」というロジックが含まれているのですが、ここで拍子とテンポを同時に変更していると一方が無視されるように見えたので、とりあえず「これおかしくね?」と指摘して後はTracktionの中の人に任せることにしました。

問題を切り分けるためにいろいろな条件でSMFを生成する

さてバグの追及がひと段落したので、次は問題が生じないようなSMFの条件を探し出す作業です（Tracktionを使った作業自体は進めないと困るわけで）。MMLで生成したSMFを取り込んでいたので、MML中で「テンポと拍子を同時に変更している箇所」を全部洗い出して書き換える…のは面倒なので、MML中でテンポ指定命令を上書きして「1ステップ後にずらす」ようにしました。自作MMLコンパイラはこういうハックが簡単に出来て良い…

#macro t n:number { r%1 TEMPO $n r%-1 }

さてこれで直るかな?と思って再度インポートしてみましたが、やっぱり直らないんですね。原因が違ったか…というわけで、もう少し大胆に「拍子変更を全部消す」内容にして試してみたら、さすがに今度は正しくインポートされました。

ということは、もしかして、そもそも拍子設定が含まれている曲のテンポは全般的におかしいことになるんじゃないか…と思って先のtracktionのコードを見直したら、（github issueでも追記しましたが）やっぱりおかしい、テンポ値の意味が拍子の変更で変わるところがある…というのを発見したのでした。

tracktionのデータを直接書き換えて問題のあるMIDIインポートを回避する

4/4拍子でないものを4/4で打ち込み続けるというのは割と苦痛です。普通の音楽では拍子の変更など滅多に発生しないのですが、今回の曲はこれが割と頻繁にありました（わたしがそういうジャンルに傾倒しているせいですが…）。

B    MARKER "Section B"
    [ r1  BEAT7,8r2..BEAT4,4 ]3  r1  BEAT3,4r2.BEAT4,4
    [ r1  BEAT7,8r2..BEAT4,4  r1  BEAT3,4r2.BEAT4,4 ]2
C   MARKER "Section C"
    t120
    [ BEAT3,4r2.r2.  BEAT4,4r1BEAT7,8r2..]2
    BEAT3,4r2.r2.  BEAT4,4r1BEAT7,8r2..
    BEAT3,4r2.r2.  t_120,80,0,1..,8 BEAT4,4r1BEAT7,8r2..
D   MARKER "Section D"
    t125 [ BEAT3,4r2. BEAT9,8r1r8  BEAT3,4r2. BEAT7,8r2..]2

今回のバグはtracktion_engine部分にありますが、わたしが必要としているのはWaveformという完成されたDAW製品で、しかも次のリリースまで待っていられるほど時間が無いので、今あるリソースだけで何とか作業できるようにしなければなりません。どうすれば良いでしょう…?

実は、*.tracktionプロジェクトファイルはフォーマット不明のバイナリ形式なのですが、その中のEditをあらわす*.tracktioneditファイルはXML形式なので、これにテキストエディタなどで手を加えることで、データを加工することができます。内容はもちろん独自形式なので、ある程度解読する作業が必要になりますが、所詮XMLなので特別に難しいことはあまりないです。特にトラックデータなどSMFとあまり変わらない内容です。

（ちなみにVocaloid V3の.vsqxなんかも似たような感じで解析できます。V3はもともとSMFの派生フォーマットだったV2の.vsqと同じような情報を含んでいるはずです。V5もJSONになっただけだろうと思っています。踏み込んでいませんが。）

*.tracktioneditにどんな情報が含まれているのかを調べる目的も兼ねて、.NETで*6このtracktioneditファイルの内容を読み書きできるライブラリを作りました。

github.com

ただ、まだTracktionが正常にロードできるファイルをゼロから作り出して書き出す方法がわかっていないので、既存のデータを読んで加工する程度の使い方しかできません。今これを掘り下げる時間が無いので現状有姿です。

別にコレに特化したライブラリを作らなくても、一般的なDOMやXPath/XSLTなどを使えるツールでいくらでも加工できる…と言いたいところなのですが、ここにはひとつ罠があって、*.tracktioneditはXML Namespace仕様 (Namespaces in XML)に準拠していません。なので、たとえば.NETのXmlReader.Create()を使って読み込もうとすると失敗します。（上記のntractiveでは.NET 1.1時代のXmlTextReaderを使っています。） 根本的にはJUCEの問題です。

さて、今回問題になっているテンポと拍子の設定は、TEMPOSEQUENCEという要素に含まれています。4/4から9/8に変更しながらテンポを緩やかに変更するSMFを取り込むと、こんな感じになります。bpm属性の値がおよそ半分になっていることがわかります。startBeat属性は、演奏データの先頭からのデルタタイムをquarter note単位で表したものになります。

    <TEMPO startBeat="28.0" bpm="115.00002875000720337084" curve="1.0"/>
    <TEMPO startBeat="72.0" bpm="57.50001437500360168542" curve="1.0"/>
    <TEMPO startBeat="76.0" bpm="115.00002875000720337084" curve="1.0"/>
    <TEMPO startBeat="80.0" bpm="57.50001437500360168542" curve="1.0"/>

拍子の変更を取り除くとこうなります。bpmの値が正常な範囲で動いています。

    <TEMPO startBeat="28.0" bpm="115.00002875000720337084" curve="1.0"/>
    <TEMPO startBeat="127.0" bpm="120.0" curve="1.0"/>
    <TEMPO startBeat="174.0" bpm="117.14288503402025298783" curve="1.0"/>
    <TEMPO startBeat="174.0" bpm="114.2857142857142775938" curve="1.0"/>

拍子設定はXML中でどう表現されるかというと、TEMPOSEQUENCE要素の中に、TEMPO要素の後にTIMESIG要素がずらっと並ぶかたちになります。

    <TIMESIG numerator="4" denominator="4" startBeat="0.00000000000000000000"/>
    <TIMESIG numerator="4" denominator="8" startBeat="4.00000000000000000000"/>

ということは、拍子設定なしでMIDIファイルを正常に取り込んだ*.tracktioneditファイルに、手作業で後からTIMESIG要素を追加してやれば、当初期待していた通りの結果が生成できる、というわけです。ただ、拍子設定を取り込んで壊れているeditに含まれるTIMESIG要素のstartBeatの値はデタラメになるので、自分で計算し直さないといけません。面倒ですね…SMFを解析するライブラリを使って、TIME SIGNATUREメタイベントを全部デルタタイム付きで取得して、このXML要素のリストを生成するプログラムを書くと良いでしょう。

最後は面倒になってきたので考え方だけでまとめとしますが、ともあれ、これでTracktionの取り込みがおかしいとしても打ち込み作業で致命傷を受けずに済むと思います。tracktioneditファイルはXMLなので手作業で補正できるということを覚えておくと、他の問題があった場合にもたぶん役に立つと思います。

*1:会社名がTracktionで現行のDAW製品名がWaveformなのだけど、しばらく前まではTracktionという製品で、GPLで公開されているエンジンもtracktion_engineなので、以降もTracktionと書きます。

*2:ここで何度か書いているから気付いた人もいると思いますが、私の場合は自作のMMLコンパイラで打ち込んだものを取り込んでいます

*3:ちなみにプロジェクト選択画面（メインウィンドウのProjectsタブ）でインポートするとMIDIトラックデータは何も取り込まれないという謎挙動になるので、こっちは使いません

*4:全体的にJUCEモジュールなので実際のソースコードに辿り着くまでにヘッダファイルの海を泳がなければならない場面がちょいちょいありますが…

*5:先日書いたMIDIプレイヤーのマーカージャンプの話が良い例です

*6:すぐ後で言及しますが、JUCEのXMLまわりの実装が古臭いので使いたくないという気持ちもあり、XMLをいじるだけなら.NETで自前でやったほうがマシだと判断しました

MIDIプレイヤーにおけるマーカージャンプの実装

これは個人的にまとめている開発メモから「公開したほうが役に立ちそうだな」という感じのエントリを取り出してきたものなので、書いた当時は微妙に現状とは違うのだけど、とりあえず補足は後で追加する。

DAWで便利な機能のひとつにマーカーがあるのだけど（もっともあまり自分が活用できているとは言い難い）、mugene/xmdspではあまり真面目に向き合ってこなかった。しかし曲が長くなってくると、とりあえず早送りで飛ばしてから再生というのも非効率なので、そもそもマーカーでジャンプできれば楽ではないかと気が付いた。

これは主にxmdspの機能となるはずなのだけど、実際にはxmdsp, mugene, managed-midiの全てに手を入れることになった。

まず、MMLからマーカーを吐き出せるようにする必要がある。これはすでにMARKERという命令で実現していたのだけど、mugeneはメタテキストの処理にバグがあって、3バイトのメタテキストを他のMIDIメッセージと同様に扱うというしょうもない問題があった（1文字のメタテキストをもつSMFを生成したことがなかったので気付かなかった）。これを修正したらマーカーが出るようになった。

次は、SMF中のどこにマーカーがあるのか、SMFから取得できるような仕組みが必要になる。これはmanaged-midiのMidiMusicクラスに機能を追加して対応した。

さて、曲中のマーカーを拾うことはできたが、その位置は全て先頭からのtickでしかわからない。ユーザーが直感的にマーカーを選んでジャンプするには、これが秒単位になっている必要がある。このため、指定されたtickからテンポの変更などを考慮して時間位置を取得する実装が必要になった。これは今までトータル演奏時間を取得するために存在していた処理を再利用して実装した。

これだけやって、ようやくxmdspのUI上にマーカー一覧を表示することができた。

https://twitter.com/atsushieno/status/1087763243467104257

ここまでは序の口だ。この指定された位置にジャンプする機能をMidiPlayerに追加しなければならない。これは割と大仕事だ。というのも…

(1) MIDIにおけるseek処理は、単に処理するMIDIイベントのポインタを置き換えれば済むという問題ではない。MIDIトラック中のメッセージには、コントロールチェンジやプログラムチェンジが存在しており、これらを単純に無視して指定された位置からノートオンを続行すると、意図しない音色やコントロールの設定で音が出ることになる。これでは不十分だ。MIDIの場合は、基本的に先頭からseek先までに含まれるノート以外の命令も処理しなければならない。

理想をいえば、この間でも「後で上書きされる命令」は飛ばすべきなのだが、とりあえずは愚直に全部処理することにした。ひとつには、MIDI出力ポートとして抽象的に指定されているものの中には、受信したメッセージを分析したり蓄積したりフィルターしたりするものがあるかもしれず、それらは「間引き」されたメッセージリストを想定していないかもしれないのである。

間にどのような処理が挟まっているかわからないということを考えると、ひとことでseek処理と言っても、実はその実装アプローチはさまざまなのだ。そう考えると、ここには汎用的なシーク処理のインターフェースが必要になるのだけど、どのようなインターフェースなら既存のMidiPlayerのAPIにどう組み込めるのか、検討が必要になるので、とりあえずまだ公開インターフェースを用意できる段階ではないという結論に至った。

(2) 状態遷移を大きく乱す機能なので注意が必要になる…ということで、PauseやStopなどの命令をあーでもないこーでもない、と組み合わせながら取り組んだのだけど、最終的には余計なメソッドを呼び出さずにシンプルにMIDIメッセージ処理のポインタを移動するのみになった。現時点で既に実装に問題があって、seek呼び出し後に「現在の演奏時間」の値が壊れているのだけど、ここは少し腰を据えて取り組まないと解決しなさそうだ。とりあえずseek機能は今切羽詰まっている打ち込み作業の改善のためにほしいので、これは後回しとなった。

…というわけで、seekの実装はそれなりに大変だったのである。MidiPlayerJSなど、seek/jumpを実装しているライブラリでは、この辺はあんまし考慮されていないということもわかった。多分ardourやtracktion_engineの実装はもう少しまともなのだろうけど、さすがにソースを追っかけている時間がない。興味が出たら後で見る。

…というのが当時の現状で、seekの後の演奏時間はその後ちゃんと直った。

マーカージャンプで曲中の任意の場所にすぐ移動できるようになってから、#conditional で条件コンパイルする機会は激減した。これの何が良いかというと、#conditionalでブロックをスキップしても、CCやPITCHやらは処理されないので、条件コンパイルすると曲がおかしくなってかえって原因究明に時間を取られる（のでMMLは慎重に書いていた）という本末転倒な状況から脱却できる。#conditionalのセマンティクスを変更するというアイディアもあるのだが、煩雑になりそうなのとマーカージャンプで十分に作業効率が上がったのとで、だいぶ優先度が低い。

ここ2ヶ月ばかりのコーディング活動

近況報告ネタ(?)

毎日仕事もせずにのんべんだらりと暮らしています。ではなくて。前回の音楽技術アドベントカレンダーの後、特に表に出せるアウトプットがあったわけではないのですが、ここ1.5ヶ月くらいの間（履歴上は2ヶ月追ってるけど12月は旅行とACに吸い込まれがち）、自作のMIDI関連ツールを割とがしがし更新していました。おかげで（と自分で書くのも何ですが）MMLの打ち込みはかなり快適になりました。

これ全部まとめたら結構な新機能紹介リストになるな…?と思ったので、git上の履歴からリストアップしてみました:

  • managed-midi
    • GeneralMidiクラスに楽器カテゴリと楽器名のリストを追加
    • MidiModuleDatabase
      • ポート名からのマッチング処理を追加
      • ドラムマップのサポートを追加（データをdomino楽器定義リストから追加インポート）
    • Xamarin.MacなしでもCoreMIDIを使えるようなIMidiAccess実装を追加(ongoing)
      • 動作確認に使っているSC-8820がMojaveで使えないので先に進めない
    • MidiPlayerの大改修
      • ロードしたSMFをいったんformat 0に変換してから処理するようにした
      • 任意の位置にジャンプして再生する機能を追加（マーカージャンプ用）
      • チャンネルマスク機能の追加（ミュート再生、ソロ再生）
  • xmmk
    • プログラムチェンジが全く機能していなかったのを修正（そう、このレベルからの改善）
    • ピアノモードとクロマトーンモードを実行時に切り替えられるようにした（以前は#if ... #endifだった）
    • トランスポーズ機能を追加（カーソル左右でキーを変更）
    • keydown/keyupでちゃんと鳴らしている音が分かるようにボタンUIに反映（これまでしていなかった）
    • デバイスセレクタをメニューからComboBoxへ
    • MMLパッドの追加。演奏した内容がMMLとして記録されるようになった。
      • 同時押しはc0e0gのように和音表記になり、アルペジオはc&e&gのようになる（ざっくりmugene互換）
    • クロマトーンモードでオクターブがカーソル上下でいい感じに上げ下げできるよう修正（ピアノと同じ挙動だとイマイチだった）
    • PCキー配列でJP106を選択したら記号キーまで演奏できる範囲にした（開発当初はそうなっていたけどUSキーボードでgdgdだったので消していた）
      • Xwtでキーボード種別を検出できないので自動化はしていない…
    • プログラム・チェンジとバンク・セレクトのメニューで音色番号を表示するようにした（していなかった）
    • MiidiModuleDatabaseの楽器マップを自分で選択できるようにした（GS互換サウンドフォントでtimidityなどを使っていても自動判別できないため）
    • チャンネルを選択できるようにして、ch.10の場合はドラムの音色セットを表示するようにした（リズムパッド的に使えるようになった）
    • MML「入力」テキストボックスを追加。任意のmugene MMLを実行できるようになった。演奏を試しながらCCやSysexでサウンドを調整できる。
  • xmdsp
    • drag/dropでSMFをロードできるようにした
    • チャンネルパラメーターでピッチベンド値を表示するようにした
    • 演奏中のファイルの更新を検出したら自動的に最初から再生するオプションを追加した（デフォルト有効）
      • 打ち込み中に有効だと便利きわまりない機能
    • 倍速再生のスピードを2x, 4x, 8xから選択可能に（以前はボタン上でmousedown時のみ2倍→メニューで選択）
    • 最後に演奏したSMFの情報と最後に選択したMIDIデバイスの情報を保存するようにした
    • MIDIデバイスリストを毎回メニュー表示時に生成するようになったので、デバイスリストの変更があったときに再起動する必要がなくなった（もともとXwtの問題でそうできなかった）
    • 演奏時間表示まわりが不正確だったのをいろいろ直した
    • マーカージャンプ機能の追加。META情報を取得してその位置までジャンプできるようになった
      • managed-midiにジャンプ機能が追加されたのはこの目的
    • 複数SMF同時再生のためのコードを追加（まだメニューには登場していない. mugeneの機能追加待ち / 複数デバイスへのマッピング機能が必要）
    • チャンネルマスク（ミュート／ソロ）の実装（これもmanaged-midiの機能追加と一対）
    • Xwt.Gtk3のTextLayoutがメモリを永久に食い続ける問題を回避
    • GUI（Canvas）のOnDraw()処理の部分的な最適化
  • mugene
    • VSCode拡張にmugene:compileコマンドを追加。VSCodeからいつでもコンパイルできるようになった
      • 再生はxmdspの「ファイル変更検出時に自動的に再生」が有用
    • MMLチートシートのドキュメントを追加（VSCode拡張で表示しても良いのだけど未対応）
    • VSCode拡張でMMLコンパイルエラーをエラーパネルに表示できるようになった
    • 最初のコンパイルエラーでコンパイルを終了しないようにしたので、複数エラーが出るようになった
    • #conditional track ディレクティブで複数トラック範囲が指定可能に（1,3-5,11-13など）
    • METAイベントの引数が1文字だけだった場合にクラッシュしていたのを修正（常にテンポ変更命令として処理されていた）
    • トラック番号に小数値を指定可能になった（和音を1トラックにしていたのを分解したいけどトラック番号は連続的にしたい、みたいな時に有用）
    • LEGATO命令のCC番号がおかしかったのを修正（めったに使わない命令で気付かなかった）
  • notium
    • mugeneと同様の機能を、MMLを習得しなくてもAPIだけで使えるようにするために独立して作ってみたもの
    • まだ全然使っていない（公開する予定も無かったけど、xmmkにMML入力padを追加する時に、当初これを使おうとしていて、submoduleにするなら公開しなきゃ…となって公開になった）

これで全部のコーディング活動というわけではないのですが、いま成果として実現しているのはこれくらいでしょうか。個人的にはxmmkがこんなかたちで発展することになるとは思っていなかったので、割と面白いなーという気持ちで眺めています。どれも未完成感が強いのですが、打ち込み作業者としての自分に必要な機能を肉付けできたのは良かったかなと思っています。

どのモジュールも、構想としてはいろいろ「これやったら面白いんじゃないか」「これが必要になるんじゃないか」というアイディアレベルではToDoがたくさんあったのですが、実際にMML打ち込み作業に必要なものを実装していくと、全然違うことばかりやっていたという、自分で振り返ってみると面白いことになっていました。

今はMIDI音源（ハードウェアとかfluidsynthとか）とSMFがターゲットになっているのですが、21世紀にもなってそればかりというわけにもいかないので、もう少しモダンなターゲットも狙おうかなーと思っています。実のところ、果たしてそんなに遊んでいられるのかな?とも思わなくもなく、特にここ半年くらいは雑多な活動で時間を浪費してしまった気がしているところですが…これからはもう少し自分のやりたいことに集中しないとですね（そっちか）。

最近の音楽活動(?)

父さんな、音楽で食っていこうと思うんだ。

「MMLコンパイラmugeneによる音楽制作ガイド」の無償公開

技術書典4で20部だけ販売したMMLコンパイラのガイドブックですが、そろそろ無償公開しても良いだろうと考えて、ソースをCC-BY-SA 4.0でgithub上にうｐしました。

github.com

原稿を公開しているだけなので、読みたい方は各自ビルドしてください。Re:VIEWなのでソースで読めなくもないと思います。あとビルドしたPDFは引き続きboothで買えるようになっています（1000円だったのですが500円に値下げしました）。

xamaritans.booth.pm

もちろんCC-BY-SA 4.0なので独自にビルドして公開してもらってもかまいません。

音楽ツール・ライブラリ・技術 Advent Calendar 2018

最終日なのでお知らせではなく報告という感じですが、12/1から音楽ツール・ライブラリ・技術 Advent Calendar 2018というものを立てて書いていました。

adventar.org

この方面でここ1、2年くらい自習してきた話題をちょいちょいまとめた感じです。1人で書く覚悟で始めたのですが、幸い何日か他の方に埋めていただけました。（参加してくださった皆さんありがとうございます…!）　25日間続くように、内容があまり偏らないようにと思って「音楽ツール・ライブラリ・技術」という表題にして、話題もある程度分散させたつもりですが、どうでしょうね…ライブラリから技術仕様、オープンなサウンドライブラリなどまで含めたので…。あと当初全く意図していなかったのですが、最終的にこの話題のほとんどがOSSと呼べる範囲の内容になりました。

本当は、無難に完結させるために、毎日2,3段落くらいでまとめるつもりだったのですが、そこまで短いと逆にまとめるのが無理…という感じになって、結局毎回そこそこの分量の内容を用意することになってしまいました。前半はまだ書きやすい話題を選びながらのびのびと書けたのですが、旅行中に書いていたこともあるので、いろいろと調べられなかったこともあります（主に「ギガが足りない」的な意味で）。後半はネタ切れでだいぶ苦しくなって、実のところ未だに埋まっていない日があるのですが、今年中に終わらせられるといいな…という感じです(!)

来年もこの方面の技術をいろいろ追いかけていければと思います。本職にするかもしれないし。

Xamarin.Androidで躍動感のある生態系を構築するにはどうしたらいいのか

https://qiita.com/advent-calendar/2018/xamarin の24日目エントリーです。

近況

たぶんアドベントカレンダーに近況報告なんて書いているのはわたしだけではないかと思いますが()、Xamarinを卒業してから真性無職エンジョイ勢です。10月くらいまでは無職だけど技術書典5の裏方やったりXamarin本の最新刊を1人で書いたりしていて割と忙しかったんだぜ…あ、紙の書籍版はComic ZIN秋葉原店にあると思います（技術書典会場で在庫をそのまま預けられるのでとてもありがたい）。boothは倉庫代が値上がりしてしまったので（それまでが安すぎた）だいぶ前に泣く泣く引き払っていて、今は電子版しかありません。

11月の半ばからはしばらく日本を離れて欧州旅行…なのかな…していました。本当は北欧とかに足を伸ばしたかったのですが、寒そうだったので未踏だった仏・伊のあたりを無難にフラフラしていました。建前としては、11/20-21にロンドンで開催されていたAudio Developers Conference (ADC) 2018に参加するための訪欧でした。ADC自体はJUCEを開発しているROLI社のイベントというのが実態に近いのですが、GoogleもAppleもMicrosoftも来てオーディオ関連のセッションを行う程度にはポピュラーやイベントです。日本からもクリプトンがスポンサーをやっていたりしましたね。

しかし音楽ツールやフレームワークの開発だけ調べていても心もとないので、しばらくは音楽制作とかを勉強してみたいと思っています。ADCに来ていた人たちも大半が自分で何かしら創作していたようだったので、地に足のついたことをしたいなあというお気持ちです。

Xamarinを卒業してからもしばらくはmonoには協力するつもりでいるのですが、そんなわけで他にやることが割とあったのでコードをcontributeしたりは特にしていません。最近だとdotnet/wpfが出たので、いよいよ昔やっていたSystem.Xamlの実装を置き換えられそうかなあとか期待していますが、先にpull requestが作られていたのでこれも他の人に任せておこう…というお気持ちです。まあ先の同人誌で世界で他に誰も書いていないであろうMono Compiler APIまで含めたJITの解説とか書いて出しているし、十分お釣りが来るレベルでしょ…(何)

本題について

そういうわけで今日はXamarin.Androidチーム在籍時代に作って放置していたツールをいくつか紹介しつつ、Xamarin.Androidで「躍動感のある生態系」を構築するにはどうしたらいいか、という大味な話を書きます。仕事になるなら最後までもっていってもよかったんですが、そこまで優先度上げられませんでした。すまんやで、という気持ちも多少は無くはないのですが、まあ自分が悪いわけでもないしな…ということで現状有姿です。こういうのを恥も外聞もなく出せるタイプのキャラクターでよかった…(!?)

xamarin-android-apitools

最初の数段落はどうでもいい話なのですが、前フリとして書いておきます。

api-merge

Xamarin.Androidでは、Android APIバインディングの実体であるところのMono.Android.dllについて、複数のAndroid API Levelのandroid.jarのAPI情報を吸い出してから、無理やり結合して、古いAndroidバージョンのAPIに対応するMono.Android.dllとの互換性を維持するMono.Android.dllを生成しています。

Android APIの実体であるandroid.jarは、意図的な古いメンバーの削除などでは快適変更が加えられたりはしていますが、それを除けば基本的にはJavaレベルでのABI（APIのバイナリ互換性）が保たれています。

これを単純にMono.Android.dllとしてバインドすればABIが維持されるかというと、そういうことにはなりません。これはJavaと.NETの違いによるもの（たとえば派生クラスのメソッドの引数型がcovariant/contravariantになる）と、Xamarin.Androidのバインディング生成ツール（generator）の仕様によるもの（たとえばsetterしかなくてSetXxx()メソッドだったものが、getterも加わってXxxプロパティになる）があります。いずれにしろ、これをそのままにしておくと、Xamarin.Androidでは新しいAPIバージョンを追加するたびにAPIに破壊的変更が生じるということになり、Xamarin.AndroidのプロジェクトではTarget API Levelを変更する度にアプリケーションがビルドしなくなったりすることになります。これはJava/Kotlinを使っていると生じない問題です。

そういうわけで、Mono.Android.dllをビルドするときは、前述の「APIを無理やり結合」するステップが組み込まれており、通常のバインディング ライブラリのビルドとは異なる複雑な手順になっています。Mono.Android.dllのビルドが単純なバインディング ライブラリ プロジェクトになっていない主な理由もこれです。この結合ステップはapi-mergeと呼ばれるツールで実現しています。api-mergeは、全てのMono.Android.dllのビルドの過程で呼び出されるもので、API Level 28にもなると、マージ処理にもそれなりの時間がかかります…が、それは今回の主題ではないのでおいといて。

このapi-mergeによってAPI互換性が保たれ、Target API Levelを変更してもコードはそのままビルドできる、というわけです。これはxamarin-androidのunit testingにも組み込まれており、xamarin-androidをmake run-api-compatibility-tests を実行してチェックできます（新しいAPIがstable APIとして登録されている場合のみです）。

api-merge everywhere...?

このapi-mergeの仕組みですが、Mono.Android.dllの他にも、複数のバージョンのライブラリの間で互換性を維持したほうがいいんじゃないかなあと思われるようなライブラリはあったわけですね。たとえばsupport-v4。どんどんバージョンが上がるので、nugetでパッケージのバージョンを上げたらビルドできなくなる、ということがあっても不思議ではないです。

そういうわけで、これらのライブラリについてもapi-mergeを利用できるように、api-mergeをバインディング ライブラリ プロジェクトの一部として組み込もうという動きが一時期あったのですが、「そこまでやっても得られるメリット無くない?」という感じの流れになって、計画は中断となりました。本家がAPIの破壊的変更を絶対に行わないポリシーで更新しているわけでもないし、基本的にnugetパッケージのバージョンを上げなければ良いだけですし、そもそもXamarinのAndroid Componentsが本家の更新に全然オンタイムで追いつけていないので「1つ前のバージョンでDeprecatedになってた」みたいなAPIがあってもすっ飛ばしていたら意味ないですよね…

xamarin-android-apitools...?

いずれにせよ、こういう背景から、複数バージョンのライブラリ間でAPI互換性をチェックできる仕組みがほしい、ということでわたしが手にかけていたのがこのxamarin-android-apitoolsです（長い前フリだった…!）　ただ、↑のような流れもあって、無理にAPIの比較をすることもないかな…それよりむしろJavaのAPIにあってバインディング側に無いものを探したり出来たほうがよいかな…みたいな気持ちで途中まで作って放置してあります。

実際には、バインディングの生成過程のどこかでAPIが欠落している可能性もあるので、API定義のXMLもチェックできるようにしたいと思って、それらもロードできるようにしてあります。

そんなわけでこのxamarin-android-apitoolsでは、複数のAPIデータソースからAPI定義をロードしてツリー表示するだけのツールとなりました(!?)。ロードできるデータは次のとおりです。

実のところ、現状ではAPI生成のどの段階で型やメンバーが欠落したかを調べるためのツールとしてのみ便利です（API比較機能が完成していればさらに便利なのですが）。表示もXwtで作ったショボいやつなので、あんまり便利ではありません。

xamarin-android-binding-automator

Androidエコシステムはsupport/jetpackを含む膨大なサードパーティ ライブラリによって成り立っており、これをいかに適切なかたちでXamarin.Android用にバインドできるかというのは製品の大きな課題です。

わたしにはかつて密かな野望(?)がありました。binding generatorをゼロから作り直して、Mono.Android.dllをゼロから生成し直して、サポートライブラリ（現在ではjetpackというべきでしょう）のバインディングを全部刷新して、GoogleのAndroidリリースに即日とは言わないまでもすぐに対応できるようにしたい、というものです。

これは技術的な制約よりは政治的な制約と技術的負債（MicrosoftのVisual StudioチームがAndroidのリリースサイクルを根本的に考慮しない、古臭いAPI Level 10のバインディングをいつまでも維持しないといけない、APIに破壊的変更は1ミリも加えられない、バインディングのあるべき姿をまともに検討する前にAPIをフリーズした、等）があって今後も一生実現しないのではないかと思いますが、今後類似の開発フレームワークがXamarin.Androidの失敗を繰り返さないために、総括しつつ、何をすればあるべき姿に近づけられたのかを模索しておくことは意義があるでしょう。

何でgeneratorやMono.Android.dllを書き換えたいの?

generatorを書き換えたいという野望は、実のところわたしに限らず多くのメンバーが口にして、一部のメンバーは開発にまで着手して、結局誰も実現できていないものです。ユーザーとしてのわれわれのフラストレーションをいくつか列挙して、それぞれについて検討してみましょう。

(1) jar/aarを渡したらそれだけでバインドできる範囲だけでDLLを生成してほしい。バインドできないメンバーは削る

実のところこれが大方のデフォルトの挙動であり、何もmetadata fixupを記述せずにビルドするとエラーになるものの大半は「これを無視するようにしたら結局ビルドが通らなくなる」類のものです（たとえばnon-abstractクラスでabstractメソッドのオーバーライドを自動的にバインドできないので無視するわけにはいかない）。

実のところ、現状でも「インターフェースのメンバーに問題があるだけでインターフェース全体が生成されない」と「指定された型がメソッドの引数や戻り値に使われていて生成できない」の連鎖的な組み合わせで、膨大な型やメンバーがバインドされないことはよくあります。デフォルトでバインドされない結果生じる問題を解決するのも、かなりの困難を伴います。

(2) 名前の衝突などは衝突しないように生成してほしい

FOOフィールドとgetFoo()メソッドがあるときに、どちらもFooプロパティになるので、このままでは生成できないのですが、一方が消えます。わたしはこれは両方生成した上でmetadata fixupを追加するよう促したほうがいいんじゃないかと思いますが、今さらこのgeneratorの挙動は変えられないだろうなあ…この挙動に依存してビルドが通っているバインディング、多分それなりにあると思うので。

これをFoo, Foo1みたいに生成するようにすると、ビルドエラーはなくなりますが、それはバインディングのユーザーが本当に求めるべきものとはとても思えないので（ちなみにこれをやっちゃったのがxsd.exeというかSystem.Xml.SerializationやSystem.Web.Services.Descriptionですね）、「ビルドエラーが出ないようにしてほしい」という漠然とした要求に対して、盲目的にこういうアプローチを採用しなかったのは正解だったと思います。

(3) 我々は愚直なバインディングを求めている。StreamやXmlReaderはいらない

これはXamarin社内に古くからあった問題ですが、「われわれはJavaよりもうまくやれる資産がある」という耳ざわりだけは良いスタンスが強く、generatorはjava.io.InputStreamなどをわざわざSystem.IO.Streamにマッピングするような設計になっています。もっと設計的にビミョいのはXmlReaderで（というか当時の設計方針に沿ってわたしが実現したのですが…）、SAX APIXmlPullParserからXmlReaderを返すようになっています。

この辺は実のところ「じゃあどこまでJava APIでやるとビミョくないの?」という反対側からの視点があり、たとえばjava.util.ListをそのままJava.Util.Listとして返すのは適切なのか、現状のようにSystem.Collections.IListにしたほうが適切ではないか、みたいな話はあります。System.Stringで表されているjava.lang.StringをJava.Lang.Stringのインスタンスで返すようにしたら、アプリケーション開発は多分かなり面倒なことになるでしょう（implicit conversionが可能かどうかによる、かもしれませんし、Xamarin.Androidアセンブリ固有の変換処理に依存するとなると共有ライブラリのビルドが面倒になったかもしれません）。

しかしStreamやXmlReaderは明らかに「やり過ぎ」であり、これらはそのままJava APIで返しておいて、必要な場合のみこれらを相互変換できるラッパーを被せられるようにすればよかったのです（実際、内部的にはうっすらとしたラッパーが使われています）。Streamは特にinputとoutputの境界が曖昧になって美しくありません。XmlReaderにはさらに問題があり、これさえなければMono.Android.dllがSystem.Xml.dllに依存することは無かったのです。余計なアセンブリが挟まって貴重なスペースを無駄にしています。

少し弁解というかフォローを入れるとしたら、Mono.Android.dllもgeneratorも元々は全Java APIをカバーするようなことは意図しておらず、特に.NETのSystem.* APIが代替として機能する範囲はむしろ「優れているほう（われわれのAPI）を使う」「いらないものはバインドしない」という設計思想になっていたのです。

しかし、この考え方はgeneratorやバインディングプロジェクトを一般化させる上で、ただの邪魔者にしかなりませんでした。「いらないもの」としてバインドされなかったJava APIに依存するAndroidライブラリの機能は、generatorにとっては「存在しないAPIを使おうとするライブラリ」でしかなく、単にバインドされないという結果に終わるのです。特Java.Util.CollectionなどコアなAPIのバインディング不在は、さまざまなバインディングのビルドに大きな悪影響を及ぼしました。

後方互換性という技術的負債

generatorやその生成物であるところのMono.Android.dllにいろいろ問題があることは分かりました。問題が分かっているなら改善すれば良いのではないでしょうか?

問題はそんなに単純ではありません。Mono.Android.dllはXamarin.Androidのフレームワーク アセンブリであり、このAPIに全てのXamarin.Androidの生態系とXamarin.Formsの生態系が影響を受けます。

Xamarin.Androidは十分にバインディング生成機構が成熟していない時点で、十分な検討が行われない中でMono.Android.dllのAPIが断行されてしまい、結果的に中途半端に問題をかかえたAPIが残りました。しかし固定されたことに変わりはなく、これを破壊することはできないのです。

これは従来の.NET Frameworkが死に体になった状態と似ています。.NET Frameworkと異なるのは、Xamarin.Androidには.NET Coreに相当する「新しい部分」が無いという点です。

しかし古いものはいつか使用に耐えなくなります。それであれば、現在の生態系を切り捨ててでも、新しいバインディングの生態系を構築すべきではないでしょうか。これを目指したのが（ようやく本題に入った）このxamarin-android-binding-automatorを中心とする構想でした。

AndroidSupportComponentsの問題

Xamarin.Androidの現在の生態系を支えている重要な要素のひとつがAndroidSupportComponentsです。現在のXamarin.Androidがかかえている「Android本家の開発スタイルにXamarin.Androidが全く追従できていない」という大きな問題の根源がここにあります。Xamarinは「正式版がまだ出ていないから」などと悠長なことを言わずに、もう少し真剣にJetpackサポートなどを「新パッケージ = 即日対応」くらいのレベルで追及すべきなのですが、互換性問題などから完全に後手後手に回っている状態であると評価せざるを得ないでしょう。

（サポートライブラリのバインディングは、かつてはXamarin.Androidチーム側で提供していたのですが、Xamarinコンポーネントストアの発足に伴ってコンポーネント開発部隊が新設され、やがてサポートライブラリもそこに移管されてしまったので、総合的なXamarin.Androidエコシステムの設計を行える組織体系ではなくなってしまったということは、一因としてあります。）

AndroidSupportComponentsは現状、MacとWindowsでしかまともに動作しないCakeによってビルドされる仕組みになっていて、2016年頃にわたしが手を加えようとした時には既に手遅れでした（それでCakeにプルリクを送って修正しようとしていた時期もあるのですが、そもそもCakeをビルドするdotnetがまともにLinuxに対応しない問題があり、dotnetチームはまともにやる気が無く問題が修正されない…という状況で、わたしはほぼ匙を投げました）。

xamarin-android-binding-automator.exe

AndroidSupportComponentsはいずれにしろ後手後手なので、こうなったら自前でバインディングのビルド生成機構を作ってしまえ…というわけで作っていたのがこのリポジトリです。現状ひとつだけ存在するツールxamarin-android-binding-automator.exeは、指定されたMavenのパッケージIDから、依存関係を丸洗いして、それぞれのjar/aarをダウンロードして、それぞれについて依存関係（*.csproj中のProjectReference）を追加しつつバインディングを生成するようになっています。MavenではパッケージIDからPOMと呼ばれるパッケージ記述ファイルをリポジトリから取得できるので、それを活用しています（解析はやっつけですが）。

もともとバインディング プロジェクトの構成要素は大きくなく、jar/aarとmetadata fixup、追加C#コードがあればほぼ足りるのですが、現状metadata fixupや追加コードは考慮されていません。バインディングプロジェクトではさらにソースコードのjarからパラメーター名を、javadocのjarからドキュメンテーションを取得できるので、それらは追加されます。

究極的にはMono.Android.dll（android.jar）も生態系の一部となるようにカスタマイズできるようにしたいのですが、Mono.Android.dllのビルドにはapi-mergeなど特殊な課題もあり、まずはsupport libraryから…という感じです（でした）。Mono.Android.dllは、かつてはバインディング ランタイムとしての役割も持っていたのですが、現在ではこれはJava.Interop.dllに移管されており（後方互換のためにMono.Android.dllにもランタイム相当の部分が残されています）、Mono.Android.dllを切り捨てつつ、あるいは完全に残したままで、新しいバインディングアセンブリ（たとえばXamarin.Android.dll）を構築することは、不可能ではありません（libmonodroidの側に"Mono.Android.dll"をハードコーディングしている部分があれば、それは切替可能なかたちに書き換えないといけませんが）。

切替可能な生態系の構築

Androidサポートライブラリ（旧）のバインディングを中心とする、現状閉塞感の強いエコシステムを書き換えるには、より迅速にバインディングを提供する仕組みがあるべきです。バインドされるライブラリには、他のライブラリへの依存関係があり、これらはMavenのパッケージの依存関係として記述・処理されます。Xamarin.Androidのバインディングには、現状、Mavenパッケージの相互依存関係を記述する要素はありません。

また、Mavenパッケージの依存関係は、こちらの期待を外れて非互換なかたちで差し替わる可能性があります。Javaにおける型解決には「どのjarに含まれていたか」のような情報は存在しないので彼らは自由に組み合わせを変えることがありますが（Java9のモジュールまわりでこの辺の事情は変わる可能性はありますが）、.NETにおける型情報にはアセンブリ名も含まれるので、それほど自由ではありません。非互換変更が生じたら「生態系ごと切り替える」つもりで臨むしか無いでしょう。

そのためには、ABI互換性維持といったぬるいことを言っていないで、新しい生態系で全てを瞬時に新しく構築できることが重要であろうと思います。そして生態系の切り替えは世界線の切り替えにも近い…というとピンとくる方もいるかと思いますが、そうです、gitのブランチ切り替えがこれに親和的なのではないかと思います。誰でも自由に生態系を改善しつつ、必要なものはソースからビルドできる。これが理想の生態系システムではないかと思います。

総括

…と、風呂敷だけは広げたのですが、この構想自体はXamarin.Androidチームにいるとほぼ実現不可能なんですよね。政治的な問題もあるし（チームの切り分けとか）。Microsoftがわたしの作業環境であるLinuxでもきちんと.NET/Xamarin開発環境をサポートしていくような会社であれば、これを継続していたかもしれませんが、現実は残念な感じだったので、この辺の構想をまとめたあたりで「まあもういいでしょ」という感じになりました。（まあそもそもを言えばバインディングまわりが自分の担当というわけでもなかったのですが。）

jetpackに関しては、バインディングAPIだけでも大変なのに、roomやdata-bindingなどGradleのビルドシステムを統合しないと実現できないようなコード自動生成にどう対応するかという問題もあり、この辺の課題に対してXamarin.Androidでは答えを出せていません。この辺も「今すぐにでも」取り組むべき課題なのですが、XamarinチームはXamarin.Formsのbindingとかあるからいいでしょ…くらいにしか思っていないようです。

もっとも、Xamarinのコンポーネントチームでも、最近ビルドシステムを刷新してMavenからの自動取り込みも行うようになった?ようなので、ここまで抜本的ではないにしても、何かしらの小刻みな改善は施していくかもしれません。jetpack対応は以下のツリーで行われています。Xamarin.AndroidやXamarin.Formsのエコシステムに期待する人は、彼らの動向に注目しておくとよいでしょう。

https://github.com/xamarin/AndroidSupportComponents/tree/AndroidX

.NETはどのくらいAPLに近づくことができるか

.NET, .NET Core, monoのランタイム・フレームワーク・ライブラリ Advent Calendar 2018の1日目は「.NETはどのくらいAPLに近づくことができるか」というお題でお送りします。

APLとは何か

APL（audio programming language）というのは、主として音楽を作成したり音響効果を実現したりする目的で音声を処理するためのもので、主に非プログラマー（というか、「ガチの」プログラマーではない人々）でも「簡単に」書けるようにするために開発されています。ここで言うAPLというのはひとつの言語ではなく、さまざまな言語の総称です（固有名詞であるA Programming LanguageことAPL言語は、オーディオとは一切関係ありません）。類似の概念としてVPL(visual programming language)があると言ってもよいでしょう。

APLのガラパゴス

APLの例としては、Csound、ChucK、Pure Data、Alda、Faust、Tidalといったものが挙げられます。面白いのは、これらの多くがそれぞれ独自の言語を定義しているということです。もっとも、これらの少なからぬ部分がSchemeなどのLisp系の言語の体系を利用していることを考えると、独自の文法であるとまで言えるかは何とも言えないところです。とはいえ、最終的に実行するプログラムが独自の生態系を構築しているということは言えるでしょう。

これらの言語の一般的な傾向として興味深いのは、これらはほぼ間違いなくJavaや.NETのような仮想マシン技術を用いて実装されないということです。音楽や音響効果を記述するのは、たとえばゲームの開発などにおいては有用そうですし、これらがJavaや.NETで開発されていないというのは意外なことではないでしょうか?　なぜ音声処理を行うのにユーザーたるわれわれが独自言語を学習しなければならないのでしょうか? 生オーディオや生MIDIを扱うAPIが存在しているように、音声オブジェクトのライブラリとして提供してくれれば、後は自分の好きなようにどうとでも生成するのに…

しかしAPL開発者には彼らなりの理由づけがあってそうしているのです。面白いことに、それらの理由づけのいくつかは論文化されており、各APLの公式サイトや関連コミュニティなどで紹介されていたりもします。

今回は、その中からExtempore言語の作者Andrew Sorensenによる "The design, implementation and application of a cyber-physical programming language" という論文が、「なぜ.NETではダメなのか」というような疑問に対して、さまざまな実装の可能性を検討しつつ論じていて面白かったので、これを紹介しながら内容を吟味していきたいと思います。

https://openresearch-repository.anu.edu.au/handle/1885/144603

（Extemporeは自称「サイバーフィジカル言語」で、音楽だけを対象とするものではないそうで、この特徴は割と多くのAPLに共通するものなのですが、ここでは踏み込まないでおきます。Impromptuという言語処理系をもとに誕生したようです。あと、この論文自体は.NETについて議論しているものではありません。CLRへの言及などはまれに登場しますが。）

おまけ。OSCON 2014のキーノートで行われたExtemporeのライブコーディングも見られます。

https://www.youtube.com/watch?v=yY1FSsUV-8c

音声処理の用途

一般的なAPLが「仮想マシンではダメだ」としながら担っている仕事は、主に音声の「リアルタイム」に近い処理です。「リアルタイム」とはなんぞや?という疑問は今はおいておいて、音声のリアルタイム処理がどのような場面で必要になるか、いくつかの例を分かりやすい順に挙げていきましょう。

(1) バーチャルなピアノの鍵盤をソフトウェアで実現することを考えてみてください。ピアノのキーを押すとそれに反応してピアノの音が出ます。押したキーの位置に応じて音階が変わります。キーを押してから音が出るまでに時間がかかっていたら、ユーザーはこれを使いたいとは思わないでしょう。

(2) MP3プレイヤーは、ユーザーが指定したMP3ファイルをデコードしてサウンドデバイスに出力します。PCMデータのデコードにかかる時間は、生PCMを再生する時間よりは短いですが、再生するタイミングが適切に管理されて守られていないと、音が飛び飛びになってしまって、ユーザーは聴くに耐えなくなります。

(3) DAW（デジタルオーディオワークステーション）は、複数のトラックで音楽を編集して制作するためのものです。場合によっては、PCMとして生成されるオーディオトラックの他に、MIDIデバイスにメッセージを送信するMIDIトラックが存在するかもしれません。オーディオトラックとMIDIトラックの間で時間差が生じてしまうと、リスナーにとってはちぐはぐな音楽として聞こえることになります。

(4) デジタル楽器を使ったライブ演奏を行うことを考えてみてください（冒頭で紹介したOSCONのキーノートスピーチのように、最近ではAPLを使った Live Codingと呼ばれる実演もあります）。ライブ中にアプリケーションが固まったり処理が一時的に遅くなってしまったら致命的です。

もちろん、「リアルタイムでない」（リアルタイムであることが要求されない）音声関連の処理もいろいろあります。たとえば生PCMデータをMP3にエンコードする仕事は、何もリアルタイムで行う必要がありません。音声に対してエフェクターとして機能するソフトウェアもいくつかあります。これらは(i)再生しながらエフェクトをかける場合はリアルタイムで処理する必要がありますが、(ii)単に変換して結果を保存したり他のソフトウェアに渡すような場合はリアルタイムである必要はありません。

また、前記(1)〜(4)で求められている要件は、厳密には「リアルタイム」とは限らないものもあります（たとえば(2)や(3)はタイミングが合っていれば即応的である必要はありません）。しかし観念としては処理時間の正確さが重要であるものであり、ここで列挙しておくべきものでしょう。

リアルタイム性

いずれにせよ、音声処理ではリアルタイム性が求められる場面が多数あることがわかりました。しかし「リアルタイム」とはどのような意味なのでしょうか?　ピアノの打鍵から1秒経ってから音が出たら、誰が聞いてもおかしいと思うでしょう。100ミリ秒だったら?　10ミリ秒だったら?　1ミリ秒だったら?　…こうなってくるとわれわれは直感的にYES/NOで答えることが出来なくなってきます。

同じような問題がVRなどで用いられる3Dアニメーションのフレームレートについても語られます。VRも60FPSとか120FPSといった要求数値が出てきてなかなか厳しいのですが、音声も割とシビアなほうで、20ミリ秒くらいだとそれなりに気づかれてしまうようです。50FPSだと思うとなかなか厳しいことがわかります。

ここでひとつはっきりさせておくべきことがありますが、リアルタイム性とは「コンピューターの処理能力を可能な限り上げることで高度な処理も期待された時間内に終わらせる」仕組みではありません。あるタスクが一定間隔の「期待された時間」に必ず呼び出されて処理できることが、リアルタイムの要件です。

リアルタイム処理は、パフォーマンスの最大化すなわち「コンピューターの処理能力を最大限に活用して、もっともコンピューティングリソースを必要とする処理に最大限のリソースを差し向けよう」という思想とは、むしろ真っ向から対立するものであると言えます（リアルタイムに呼び出される処理はむしろ大して仕事しないかもしれず、それでも定期的に呼び出すことは重要なので、タスクマネージャーはその優先度を上げたままで維持します）。

現代のマルチタスク・コンピューティング環境において、「期待された時間」の枠は、OSのプロセスとスレッドの管理に依存するところが大きいです。前述のSorensenの論文は、そもそも「OSが自動的にタスク切り替えを処理するプリエンプティブ・マルチタスクにするか、アプリケーションが手動でタスク切り替えを管理する協調的マルチタスクにするか」というところから、リアルタイム処理の可能性を検討するのですが、協調的マルチタスクは、もはや一般的なデスクトップ環境があらかたプリエンプティブである現代において現実的ではないので、すぐに検討から外されています。

いずれにせよ、プリエンプティブなマルチタスク環境においては、リアルタイム処理を実現するためには、リアルタイムの精度で必ず呼び出しが発生するプロセス／スレッドが存在することが求められます。一般的なスレッドには、そのような保証はまったくありません。スレッドは大量に生成されて、また多くは既存のスレッドをスレッドプールから使い回されます。全てのスレッドが期待された時間に必ず呼び出されるような理想的な世界があれば問題にはなりませんが、現実はそのようにはなっていません。せいぜい、リアルタイム処理のために特権的に許されたスレッドだけが、優先度の高い割り込みを実現できるのです。それもRTLinuxのような特殊なOSカーネルによって実現してきたのです。

唐突に本題に戻りますが、.NETでこのようなリアルタイム用スレッドの作成が出来てコードが実行できるのであれば、.NETでAPLの要件を満たしたコードが書けるかもしれません。この論点は後でまた言及します。

（Sorensen論文は、さらに「時間をどう計測するか」というトピックについても一節を使って論じていて面白いのですが、さすがにそこまで紹介する意味はほぼ無いので、これだけの言及にとどめます。）

ガベージコレクション

仮にリアルタイム処理を行えるスレッドが利用できたとしても、それはあらゆるアプリケーションがリアルタイム処理に対応していると言える十分条件になるわけではありません。リアルタイム処理においては、1回の呼び出しサイクルが、1サイクル分の時間以内に処理を終えて呼び出し元（OS）に制御を戻すことが求められます。すなわち、この処理で予定外に長い時間がかかってはいけないのです。そして、これは処理時間の平均値の問題ではなく、WCETと呼ばれる「最悪の場合にかかる処理時間」 （worst case execution time）の問題なのです。

この観点で、.NETやJavaをはじめ、その他各種言語ランタイムで問題になるのがGCの処理です。GCの多くは確保されたオブジェクトの利用状態を安定的にトラッキングするために、よく"stop the world"と呼ばれる全アプリケーション・スレッド停止処理を施した上で、メモリをスキャンして、使用されなくなったオブジェクトをマークして、これをスイープします。

stop the worldはCLRのような世代別GCでは、一般的には第2世代以降のみに当てはまる話ですが、いずれにせよ、ここで重要なのはstop the worldが発生しうるということです。stop the worldは当然ながらリアルタイム処理を行っているアプリケーション・スレッドも止めなければなりません。…あれ? リアルタイム処理では、1回の呼び出しサイクルで行われる処理が1サイクル分の時間に必ず収まらないといけない、という条件はどうなるのでしょうか?　はい皆さんご想像の通りです。これは満たせません。

実際には、ここには「力こそパワー!」が働く余地があって、極端な話、GCのstop the worldが十分に短いサイクルで実現できるのであれば、これは問題になりません。たとえばGoのGCはマイクロ秒単位で完了するらしいです。ビックリですね…! GC開発者が2016年に「10ミリ秒の停止なんてもう古い!」みたいなことを書いています。

https://groups.google.com/forum/#!msg/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ

あと全然関係ないところでHISEというプロジェクトがしれっと "Customized and real time safe Javascript Engine" などと書いていてたいへん気になるところです。ざっと見た感じでは、JS実装はどうやらインタープリタの独自実装で、一方でメモリ確保は自動で行わないように拡張したものであるようです。

http://hise.audio/

翻って、われらが.NETはどうでしょうか。2017年にMatt WarrenがまとめたGC停止時間に関する投稿がひとつの情報源として信頼できるでしょう。

http://mattwarren.org/2017/01/13/Analysing-Pause-times-in-the-.NET-GC/

Workstationで20ミリ秒強…これではオーディオのリアルタイム処理を任せられるとは言えなそうです。もっとも、この投稿ではGCのLatency Modesに関する言及が何もなく、もしかしたら全く調整を試みずに測定しただけなのかもしれません。Low Latencyモードは.NET 3.5で追加されたもので、この記事がよくまとめています。

http://blogs.microsoft.co.il/sasha/2008/08/10/low-latency-gc-in-net-35/

もっともLowLatencyモードは「gen-2以降はGCしない」という剛毅な動作条件なので、長時間実行しっぱなしのライブパフォーマンスのような用途で使う余地はありません。

同じ2017年1月のこちらの記事では、もう少し悲観的な数値が出ています（最後のほう）。このベンチマークではbackground (concurrent) workstation GCとLowLatencyモードを明示的に対象としています。WCETが200ミリ秒を超えることがちょいちょいあるようです。これではやはり使い物にならないでしょう。

https://blogs.msdn.microsoft.com/seteplia/2017/01/05/understanding-different-gc-modes-with-concurrency-visualizer/

（少しだけGCの速度について補足すると、goはreified genericsをサポートする.NETに比べると、だいぶシンプルな要件に基づいて実装されているはずなので、実装の本気度合いの比較と考えてしまうのはフェアではないとわたしは考えています。ただし、言語の総合的な可能性を評価する要素にはもちろん含まれます。）

JITの予見できない動的コード生成

GCの話はここまでにしておいて、もうひとつ、この論文が取り上げるJITの話題に移りましょう。一般に、仮想マシンのJITエンジンは、実行時にCPUネイティブの実行可能なコードを生成します。.NETプログラムを初めて起動したときにつっかかるような遅さを体感できると思いますが、その正体はJITコンパイルです。より正確を期するなら、JITコンパイル処理そのものよりは、JITコンパイラをプログラムとしてロードして実行するための遅さ、であると考えたほうがよいでしょう（コンパイル処理自体にあれほど長大な時間がかかるとまでは言えないので）。しかしそこまで極端に長い時間はかからないとしても、JITコンパイル処理自体には無視できないコストがかかります。

一般的には、ある仮想マシンコードのメソッドを実行するためには、まずJITコンパイルしてから実行することになります。ここで先般から話題にしているリアルタイム処理の要求事項の話を思い出してください。リアルタイム処理の呼び出しが行われたときに、初めて実行するコードがあったとします。このコードはまずJITコンパイルされなければなりません。このコンパイル処理はリアルタイム処理に期待される応答時間内に完了するでしょうか?　…ちょっとこれは期待できそうにないですね。これがSorensenが提起するもうひとつの問題です。

ちなみに、これは.NETやJavaの問題というよりは、一般的な言語ランタイムに共通する問題です。Sorensenが論文で言及しているのはSonic PiのRuby、GibberのJavaScript、ImpromptuのScheme、OvertoneのClojureなどです。

Extemporeは、ではどのように設計され実装されているかというと、この言語はSchemeのインタープリターとXTLangという独自の実行系のハイブリッド構成になっていて、XTLangではGCに依存しない、リアルタイム処理で期待されるコードを書く、それ以外はSchemeで書く、ということになります。XTLangで書かれたコードは、いったんコンパイルしてLLVM IRに変換し、それをネイティブコードに変換して実行することになります。

Extemporeは、ライブパフォーマンスなどの場面で、REPLのようにコードの断片を実行できることを、主目的としており（CやC++では実現できない課題としてこれを挙げています）、実際それがExtemporeコードの一般的な実行方法になります。ただ、XTLangのコンパイルには時間がかかるので、事前にコンパイルコマンドを実行しておくことで、実行時遅延の問題を回避します。

この論点ですが、2018年までにAOTやインタープリターのような、さまざまな.NET実行環境を見てきたわれわれとしては、「仮想マシンであればJITコンパイル」というのは、やや固定観念的であると評価せざるを得ないでしょう。古くからAOTをサポートしていたmonoランタイムだけでなく、.NET CoreでもAOT実行が可能になりつつあり（可能である、と言ったほうが良いでしょうか?）、この点での懸念は、少なくとも理論の上では無くなりつつあると考えられます。

もっとも、インタープリターで実行するのであれば、ネイティブコードのパフォーマンスは一切期待できず、何のために仮想マシン言語を使うのか、という話になるでしょう。その点AOTはまさにXTLangと同じことをやっているのであり、基本的にはリアルタイム処理を期待する場面ではAOTを適用するようにすれば良いと言えそうです。もっとも、Xamarin.iOSでも問題になるように、AOTでも不完全AOTになってしまうものは、JIT処理が発生する余地があるということで、リアルタイム処理に関する懸念をクリアできません。

いずれにせよ、ExtemporeはAOTに相当する静的コード生成をREPLのレベルで実現しているので、.NETでこれに相当するものを実現するためには、現存するC#のREPL環境では足りず、部分的に独自にAOTコンパイルを行えるようなREPL環境が必要になるでしょう（先ほど「少なくとも理論の上では」と留保した理由です）。

言語ランタイムとサウンドサーバーのプロセス内通信

Sorensen論文が本当に面白いのは、この論文はExtempore以外のさまざまな他の実装のアプローチについても、彼なりの視点で検討を加えているところにあります。そのひとつは、言語ランタイム側はリアルタイム処理を行う音声処理部分と、FFI（foreign function invocation/interface）などによってintra-process communication（interではなくintraであることに注意）を行うことで、他言語実装によるメリットを得る、というアプローチです。ChucK、Impromptu、Fluxusはこのアプローチで実現しているようです。

このアプローチの問題は、アプリケーションがクラッシュした場合に問題を解決するのがとても困難である、とまとめられています。これは確かに事実ではあるのですが、「難しいかどうか」はどうしても主観的な判断になってしまうので、その妥当性も評価が難しいところです（というかこの論文ここはスルーしてもらえたのか…）。

プロセス間通信による実装アプローチ

intra-process communicationが困難ならinter-process communicationすなわちIPCではどうでしょうか。これもSorensenは検討しており、実際にこのアプローチで実現している例としてSuperColliderを挙げています。プロセスが分離していると、クラッシュするのはクライアントかサーバーのいずれかになるので、問題の切り分けが容易になりますし、ABIではなくプロトコルによってやり取りが決まるようになります。特にSC3は仕様の安定化を図ったことで、SC1やSC2のようなクライアント・サーバー間の厳密な同一バージョン依存が無くなった、と説明されています。

しかし一方で、安定した仕様になってしまった結果プロトコルへのメッセージの追加が容易に行えなくなったことが問題である、という議論を加えてもいます。仕様を簡単に変更できることがintra-process communicationの大きなアドバンテージである、とまで書かれています。

Extemporeもクライアント・サーバー方式であり、プロセスはクライアントとサーバーで分離しているのですが、tightly-coupledとloosely-coupledの2つのアプローチの間ではフラフラしていたようです。基本的には不可分のものとしているつもりであるようで、その機能の一部をCのライブラリとして分離したりしなかったりといったことを、後方互換性を気にせずに行ってきた、というような話も書かれています。

このあたりの事情をどう評価するかも悩ましいところですが、わたしの個人的な意見としては、実装のアプローチがクライアント・サーバー分離モデルであることと、仕様の安定化の有無は個別に判断すればよいことであって、仕様は正直「ここは安定」「ここは未定」みたいな宣言で押し切るしか無いように思います。安定仕様がダメだったら、非互換の別の仕様として立て直すしか無いでしょう（今「たぶんSwiftはこうやって現状のようになっていったんだろうなー」という考えが浮かびましたが多分気のせいでしょう）。

.NETの文脈でこれを考えるなら、intra-process communicationの方法はあまり考えつかないのですが、CLR hostingやmono embedded APIによるホスティングでしょうか…あまりメリットが無いような気がしますが可能と言えば可能でしょう。（前述のstop the worldと向き合わなければならない事に変わりはないのですが、ここでは個別に検討します。）

inter-process communicationのアプローチは、特段論じるべきことはあまり無く、強いて言えばIPCに必要な共有メモリのサポートなどは.NET Coreでもだいぶ最近になってクロスプラットフォームで実装されてきた機能であることに注意したほうがよい、という程度でしょうか。TCPなどの通信スタックを使ってしまうと、リアルタイム処理を期待しているのに…となってしまいそうです。

ただ、そもそも根本的な問題として、クライアントとサーバーを分けて、ではサーバーは.NETやJavaで実装・拡張したくないのか、と考えると、やはりやりたくなるんじゃないかなあという気はします（個人の主観の問題でしょうか…?）。そうなると結局stop the worldなどの問題に正面から向き合うことになるでしょう。

.NETのGCに挽回の余地はあるか?

さて、ここまで長々とSorensen論文を中心に、APLを.NETで実現する場合の課題にはどんなものがありうるか、検討してきました。やはり一番問題になるのはGCのstop the worldではないでしょうか。

実のところ、この点では.NETよりはJavaのほうが可能性が広がっています。Java界隈には、リアルタイム処理を実現するための手段としてRTSJ（Real-Time Specification for Java）という仕様があり、JSR 282として標準化されています。RTSJの主な特徴をざっくり列挙するとこんな感じです:

  • RTSJでは、リアルタイム処理用のスレッドをユーザーが作成できる
  • そのスレッドではメモリの確保手段が限定されている
  • そのメモリ領域はGCの対象とならない

これらの取り決めをしておくことで、リアルタイム処理を妨げられないスレッドが実現できるというわけです。

Javaにはこのような機構があるのに.NETには無いのでしょうか?　.NETにはCER (constrained execution region) という機構があって、「GCをLowLatencyモードに切り替えるときはこれを使え」と言われるものですが、これは別にメモリ管理を別途行うようにするというほどのものではないので、RTSJのようなことは出来ません。このあたりの柔軟性の無さは、やはり.NETがずっとクローズドソースで閉鎖的に開発されてきたからでしょう。CLR/CoreCLRのGCもあまり柔軟ではなく、このようなメモリ管理機構に耐えうる設計になっているのかはわかりません。

一方、.NETや.NET Coreとは異なり、MonoはGCの実装を差し替える機構がそれなりに整備されているので、RTSJ的なGCとハイブリッドに協調するGCを構築できる可能性があるかもしれません。こちらはずっとOSSだったにも関わらず、RTSJのような試みはなかったと思います。何処かではあったかもしれません（わたしは聞いたことがありません）。

実のところ、RTSJも高価な商用製品による実装がほとんどであり、オープンソースの実装というものは無いように思います。そういう意味では、気軽な音楽アプリとは住んでいる世界が違うかもしれません。

この方面で一番現実化しそうなのはUnityとくにECSかもしれません（リアルタイムオーディオのリクエストは何年も前から出ているようです）。ECSで要求されるC#コードの制約がどれくらい問題になるかはUnityを使っていない勢のわたしにはわかりませんが、機構としては一番可能性がある領域かなと思っています。

まあこれはあくまでGCに関連する部分だけの話です。REPL環境が作れないんじゃないかという気もしますし、Unityのエコシステムは.NETのそれとは根本的に異なるガラパゴスであり、これとデスクトップ環境の標準的なコントロールに基づくUIを繋ぐのはだいぶ無理がありそうなので、頑張って機構を作っても、利用する側の開発体験が悪くなるだけになりそうですし、こういうのはMono Frameworkが一番向いていますね。

考察

さて、ここまでSorensenの論文を主な肴としつつ長々と書いてきましたが、最後にこれまでの話をもとに、どんなアプローチであればAPL開発者が納得できるような仕組みが構築できるのか、考察していきます。現時点では、次の2通りのアプローチがあると思います。

  • Low Latencyモードでメモリ不足で落ちないところまで頑張ってみる
    • and/or Low Latencyモードで解放されずに増え続けるメモリ使用は「リーク」とみなしてつぶす
  • クライアントとサーバーをIPCで繋ぐ。やりとりは共有メモリ。サーバも.NETで作るなら、Low Latency GCで「リーク」しないように作り込む

後者のほうが現実的かな?という気がしています。ただ、いずれも定性的に「リーク」を検出できる機構になっておらず、これでは不安である、と言われてしまう可能性はあります（まあそれを言い出したらGCの無い言語の上にコードを構築すること自体が不安ということになりそうですが）。

わたしがAPLを使ったり作ったりしたくなるような時が来たら、このIPCもどき方式で試してみようかなと思っています（個人的にはライブパフォーマンスに走る予定は無く、停止時間はほぼ重要ではないので、作るとしてもあくまで仮想的なクライアント／サーバーを分けておく程度で、アプリケーションは単一のままになりそうですが）。

なお、これは全て「アプリケーションがリアルタイム処理用のスレッドを作成できる」OSであることを要求事項としています。Androidなど、これが実現できない環境については、また別個の考察を必要とするものです。（本当はこの辺の話をDroidKaigi 2019でしようと思って準備していたのですが、セッション不採択になってしまったので他の機会に…）