幻想音楽祭サークル参加のKPT

https://dl2.pushbulletusercontent.com/mDQ1Wd6QAKKlr2JyX3u6mrsdw0XjPFml/20190302105736_p.jpg

幻想音楽祭の出展は無事終了しました。音楽サークルとして創作したのもイベント参加も初めて、他サークルの人々も一般参加者も知り合いがほぼ皆無、しかも単独サークルという99.9%アウェイな状況でしたが(!)、ブースでは多くの方に興味をもって音楽を聞いてもらえたり、展示していたMMLの解説に興味を持って話を聞いてもらえたりと、たいへん楽しく過ごすことが出来ました。来てくださった皆様ありがとうございました…!

「事前にPVを見てこれを買いに会場まで来ました」という方がいらっしゃって、これは「こんなことがあるのか…!」とちょっと信じられないくらい嬉しかったです。これを原動力として買ってくれた方の期待にまた応えられるような作品を作りたいと思いました。

10枚売れたときは「おおっ」ってなりました。売り子をお手伝いいただいた id:Colloid に「2桁行くって割といい数字ですよ」というコメントをいただいて、多分そうだろうな?とは思いつつ、事後になってどんなもんなんだろって思ってネットの海を探してみましたが、「2桁もいかなかった経験がある人は結構多いと思うので」という記述を見て、なるほどやはりそういうもんなんだな…と思いました。前述した今回のうちの状況を鑑みると、これはやっぱりけっこういい数字なのではないでしょうか…!

売上を支出と比較して考えると、今回の作品は用意していったCDが全部はけても赤字というラインだったので、打ち込みツールのプロモーション活動というか、この方向で開発活動を進めていくための足場作りであると割り切っています。もちろん、だからといって音楽制作の手を抜いたつもりはありません。(時間的に間に合わなかった作業はもちろんありますし、テクニックが身についていればアレもコレも出来た…みたいなことはもちろんあります。レベル上げが必要なやつですね…!)

KPT

同人音楽サークルは今回が初めてでしたが、M3などには何度も一般参加していますし、ネットの海にはいろいろな情報が流れています。いろいろ参考にしながらやったことがありますが、事前告知のエントリーですでに長々と書いた辺りはカットして、今回はいろいろKPTのかたちで振り返ってみたいと思います。

  • (K) ダウンロードコンテンツにMP3だけでなくMIDIソースとTracktionデータを含めた(「うわあ、こんなの入れちゃっていいんですか?」という話もされましたがw いいです。どんなものをどうやって作ったのかを広めるために作っていますし、これで「引き」がよくなりました)
  • (K) 制作過程を紹介したペラ紙とMML本の見本誌を用意した(これを読むために立ち止まってくれた方がたくさんいた)
  • (K) クロスフェードを作成してyoutubesoundcloudに登録した(どちらのアカウントも初利用)
  • (K) musicbrainzCDDBデータとMP3 song fingerprintingに基づくタイトル情報等を登録した
  • (P) ジャンルの最初にProgressiveと書いていたけど、最初の曲は3/4固定で、残りの曲もインパクトのある部分は後半に集中していて、試聴では不利な構成で、各曲1分ずつなどそれなりの時間をかけて視聴した人ほど買わない傾向があった(期待はずれだと思われた可能性が高い)
    • (T) 次回は譜面を用意してこようと思う(タブレットでも可)
  • (P) スケジューリングが思い通りにならなかった: これは事前の見通しの問題ですが、たとえば(1)アルバムジャケットを印刷依頼するためには、その時点で裏ジャケットに載せる曲名リストが確定していなければならない(最後の追い込みがうまくいったら1曲追加できる、みたいなことはできない)、(2)PVをアップロードするためには、その時点で作品がだいたい完成していなければならないが、告知用のPVが必要になった時点でまだ仕上がっていない、といった問題
  • (P) 参加サークルによるサンプル曲の募集に対応できなかった(何一つ完成していなかったので…!)
    • (T) なるべく1曲くらいはこういう用途に対応できるように音源を用意しておきたい
  • (P) ついたてが無かったのでPCの背中を使って紹介を掲示したのだけど、手作り感が目立ってしまった
    • (T) 次回はついたてを用意しておく or 組み立て台を調達する(隣のサークルさんが用意していて「いいな〜」ってなった)
  • (P) 名刺的なものを何も用意していなかったので、不在の時に「連絡先は…?」みたいなことになった(とはいえ週休七日だし名刺的なものを用意するには完全にサークル用の何かが必要)
    • (T) サークルと肩書をでっちあげる or 無職を失う

音楽は試聴するまで内容がわからないので、試聴しか伝達手段が無いと、じっくり聴く人でもない限りは、最初のせいぜい1分くらいで次の曲に進む人が多いです。その1分の間にインパクトのある内容(プログレであれば癖のある変拍子や音色選び)が無ければ、期待通りの内容とは思ってもらえません。ただ、曲の構成を「試聴に最適化されたかたちに」変えるというのは避けたいと思っています。全体的にどのような楽曲なのかは、楽譜になっていればある程度見えるはずです(特に変拍子など)。

実のところ、最初はSMFからmusescore経由で譜面を印刷して閲覧用に持っていくつもりだったのですが、最初の楽曲がすでに50ページを超える内容だったので、今回は見送ったのでした。結果的には「あったほうがよかった」と思っています。タブレットがこの目的にはちょうど良さそうですが、調達が必要な案件です。

今後の予定

実のところ、サークル出展自体が初めてだったこともあって、他のイベントに目を向ける余裕は全くありませんでした。M3春なども参加できる予定はありません。コミケはちょっとしんどそうなのでスルーすると思います。というわけでリアルイベントには、出られるとしても秋ですかね…(!) Apolloには気軽に出られそうなので多分参戦するんじゃないかと思っています。いずれにしても、じっくり制作に時間をかけられる体制を確立しておくことが必要ですね…!

今からでも入手したい

…という方のために、CDの無いダウンロード版としてのデータをboothから入手できるようにしました。もしかしたらCDもプラス500円+送料くらいで販売するかもしれません。

xamaritans.booth.pm

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

gensouongaku.info

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

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

TL;DR

目次

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

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

見せて

はい…(抵抗感) youtubesoundcloudにうpしてあります。

youtu.be

soundcloud.com

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

発端

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

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

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

制作環境の決定

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

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

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

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

この時点でわたしが「わかる」と言える音色はSC-8820までのGM/GS音源の音色くらいだったので、Collectiveで音色を選んでそのパラメーターを調整するか、Collectiveにない音(かなりあります…)については、juicysfpluginサウンドフォントFluidR3_GM.sf2でGMにフォールバックする感じでした*6。ただ、これは早々に行き詰まりそうだったので、SC-8820のフル音色を徹底的に活用してMMLMIDI楽曲としてまず完成させつつ、その後に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をはじめ大抵のDAWMIDIトラックやらインストゥルメンタルトラックやら呼ばれるものは、そして各種オーディオプラグインは、内部的に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などを使えるツールでいくらでも加工できる…と言いたいところなのですが、ここにはひとつ罠があって、*.tracktioneditXML 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がメモリを永久に食い続ける問題を回避
    • GUICanvas)の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上にうpしました。

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社のイベントというのが実態に近いのですが、GoogleAppleMicrosoftも来てオーディオ関連のセッションを行う程度にはポピュラーやイベントです。日本からもクリプトンがスポンサーをやっていたりしましたね。

しかし音楽ツールやフレームワークの開発だけ調べていても心もとないので、しばらくは音楽制作とかを勉強してみたいと思っています。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-androidmake 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の比較をすることもないかな…それよりむしろJavaAPIにあってバインディング側に無いものを探したり出来たほうがよいかな…みたいな気持ちで途中まで作って放置してあります。

実際には、バインディングの生成過程のどこかで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というべきでしょう)のバインディングを全部刷新して、GoogleAndroidリリースに即日とは言わないまでもすぐに対応できるようにしたい、というものです。

これは技術的な制約よりは政治的な制約と技術的負債(MicrosoftVisual 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.SerializationSystem.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は現状、MacWindowsでしかまともに動作しない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