技術書典14 サークル参加情報

告知が直前になってしまいましたが、5/21の技術書典14にサークル「オーディオプラグイン研究所」としてオフライン参加予定です。配置番号は「え-01」です。エノ列です。

オフラインサークル参加は自分でもびっくりしたことに2018年の技術書典5以来、なんと5年ぶりなんですね。当時は音楽技術サークルではなくXamarinサークルだったので（MMLコンパイラ本があったのですが、当時はC#アプリケーションだったのでまあギリ一貫してる…?）、完全に別物としての参加です。

オーディオプラグイン研究所としては（前身のcircle gingaも含め）もう5年分の成果があるわけで、発行している同人誌もけっこうな数になってきました。オフラインの技術書典に参加するのはある意味「初めて」で、これまでは主にM3で頒布してきたので、改めてオーディオプラグイン研究所としてこれまでどのようなストーリーラインで刊行物を発行してきたのか、ひと通り紹介していきたいと思います。この順番だと新刊紹介が一番最後になってしまうので、新刊にだけ興味がある方は最後のほうまで飛ばしてください。

MMLコンパイラmugeneによる音楽制作ガイド

この本を書いたのは技術書典4の頃だったのですが、Xamarinチームに在籍していた頃も趣味でmanaged-midiとかmugeneという自作MML to MIDIコンパイラを作っていたこともあって、ずっと「~（.NETは飽きたので）~音楽系ソフトに主軸を移したい…!!」という思いが高じてついカジュアルに書いてしまったやつです。MMLコンパイラとしては割りと柔軟にマクロを定義して自由にMIDIバイナリを出力できたので、それなりにおもちゃ以上の存在ではあったと思います。「こういう本があるべき」みたいな高い意識はなく、単に同人誌として書きたかったことを書いたものです(!)

mugeneのrepo自体は今はarchivedで、mugene-ngとしてKotlinで作り直されていて、新たにMIDI 2.0もサポートしており、Kotlin/JSを活用してnpm化もして、言語ランタイム不要なvscode-language-mugeneという拡張機能に組み込めています。

mugene fantasy suite (CD)

2018年にXamarinを卒業してからも、しばらくの間はmanaged-midiやmugene MML compilerなどC#で書いてきたプロジェクトをしばらく維持していましたが、上記のMMLコンパイラmugeneを音楽制作にちゃんと使ったことは無く、そのことに忸怩たる思いがあったので、2019年3月に幻想音楽祭という比較的小規模なイベントで音楽サークルとして参加し、そのためにdogfoodingを兼ねて(!)制作に使うことにしました。詳しくは↓に書いています

https://atsushieno.hatenablog.com/entry/2019/02/22/181235

今回はそのCDをグッズとして販売します。まあ音楽作品としてはアレですがMMLの実例として…!

DAW・シーケンサーエンジンを支える技術 [第2版]

上記CDは、音楽の打ち込み部分はLinuxデスクトップとMIDI音源として大昔に使っていたRoland SC-8820を使ってMMLだけで完結させたものの、最終的にはMac上でTracktion Waveform (DAW)とKontaktやOzone等のオーディオプラグインを使って素人マスタリングしたものでした。

音楽ソフトに主軸を移していこうというのに、いつまでも古臭いMIDIの知識で生き延びられるはずはないし、ちゃんとオーディオ処理と向き合っていこう…という気持ちになったものの、当然ながらC#でまともなオーディオアプリケーションが開発できるはずは無く、modern C++を勉強していこうという初心者の気持ちになって、2019年から本格的にJUCEを使ったソフトウェアの開発に入門していきました。今思に開発していて今回の新刊の題材であるAudio Plugins For Android（当時はandroid-audio-plugin-framework）もこの頃に雑に始めたものです。

CD制作でTracktion Waveformという割とマニアックなDAWを選んだのには理由があって、2018年にこのDAWのGUI以外の部分がTracktion EngineというOSSで公開されたのです。TracktionはJUCEのメンバーが開発してきたDAWで、商用DAWとして本格的な実用性があって（それなりに安定もしていて）エンジンがOSSで公開されているというのであれば、いざとなれば音楽プレイヤーをOSSで提供できる楽曲データをDAWでも打ち込める…! というアドバンテージがあったわけです。

Waveformの楽曲データは単なるXMLで、これは自分としてはntracktive, kotracktiveといったTracktion用の解析ライブラリをC#やKotlinでも簡単に作れるものでした。Tracktionの楽曲フォーマットを調べることで、MIDIでは出来なかったDAWの各種機能が、割と幅広くわかるようになりました。そういったオーディオプラグイン用のプレイヤーやエディターみたいな「シーケンサーエンジン」の設計については、ほとんど情報がなく（そもそもVSTホスト開発の情報などが希少なわけです）、そういうのをざっくり把握できる本があるべきだなと思って書いたのがこの本です。

LV2オーディオプラグイン開発者ガイド

自分のメインのデスクトップは2011年にWindowsから乗り換えて以来Ubuntuなのですが、この方面に飛び込んでから2021年頃までは「Linux DTMがしんどい」と感じることが多い期間でした。Steinbergが2018年にVST2 SDKの公開を停止し、VST2のプラグインがビルドできなくなっていく中、当時ROLI傘下にあったJUCE 5.xではVST3プラグインをLinuxでビルドできず（この状況はPACE買収後のJUCE6で改善しています）、Linuxで利用できるプラグインはLV2だけでした。多くのJUCEプラグインが非公式のLV2 forkでビルドされていました。

LV2のプラグインにも面白いものがあり、特に当時は「いつまでもFluidsynthでサウンドフォントというわけにはいかない…OSSでKontaktに代わるものは何を使えばいいのか…」となってSFZを発見し、その最先端実装であるsfizzにちょいちょい関わるようになり、android-audio-plugin-framework（当時）でも使えるようにしたい…となっていわゆるLV2 SDKをAndroidに移植するようになったり…と、少しずつLV2に詳しくなっていきました。日本でもLV2プラグインを開発している人が何人かいるのでとても最先端ではありませんが、例によってホスト側の視点に立つことが多く、たぶんそれなりにユニークな知見が溜まっていました。技術書典9とM3が近づいてきたので、一度この辺の経験をもとにLV2開発本を書いてみよう、となってこの本ができました。

開発以前にそもそも「使う」知見も必要じゃないか…となって、結果的に「LV2とはなんぞや」から入るような本になったのですが、同人誌らしいユニークなやつになったと思います。執筆当時はまだでしたが、2022年にはLV2がJUCE7でも正式にサポートされ、Reaperでも使えるようになって、一気に利用場面が広がっています。

この頃うつぼかずらさんのVST3プラグイン開発本も出て、JUCE Japan本と合わせてプラグインの開発にとっかかるには概ね困らなくなったと思います。（まだAUが無いし、AUv2とAUv3はだいぶ違うという話もある）

MIDI 2.0 UMPガイドブック

2020年。オーディオプラグイン研究所で一番ポピュラーなところを狙った一冊です。

謎の勢いでLV2本を書いたものの、冷静になると「さすがにこの本は売れないだろうな…」とは考えざるを得ませんでした。もう少しキャッチーなトピックの音楽技術ネタは無いものか…そういえばMIDI 2.0の正式版が出ていたな…ちょっと調べてみるか…という感じで、雑に始まったものでした。最初のMML本は3日で書いたので、1週間もあればカジュアルな本が1冊くらい書けるだろうと高をくくっていました（実際1週間くらいで書いています）。

MIDI-CIはしばらく前から存在していたので、新しく登場したUMPくらいがいいだろうと思って調べ始めてみると、これが割とモダンなDAWとオーディオプラグインのイベント入力にも十分に耐えうるデータフォーマットで、これはもっと普及してもいいと思うようになりました。もしMIDI 1.0について知っていれば差分は難しくないので、単なる解説書程度なら簡単に書けると思います。ただそれだけだと「仕様書とほぼ同じ内容」になってしまうので（それでも日本語資料は皆無なので価値はあるといえばありますが）、仕様書では読み取ることができない「なぜこうなっているのか」の部分を自分なりに解釈して解説しています。

MIDI 2.0エコシステム構築術

MIDI 2.0本は当初の目論見どおり()順調に売れてよかったのですが、MIDI 2.0を採用したプロダクトはなかなか登場しませんでした（今でもほとんど無いと言わざるを得ないでしょう）。MIDIのように相互運用性が課題の技術では、鶏と卵の問題に陥りがちです。

でも…この場合の鶏と卵って一体何のことを言うんだろう?という考えが浮かびました。われわれは既にMIDI音源を使ってDTMをやっていないわけです。われわれが使っているのはオーディオプラグインであり、ソフトウェアシンセサイザーです。であれば、プラグインがMIDI 2.0をサポートするようになって、DAWがMIDI 2.0をサポートするようになれば、ハードウェアは後回しでもいいのでは? と考えるようになりました。

この頃、ついに重い腰を上げて、C#のmanaged-midiをKotlinにktmidiという新しいライブラリとして移植していたのですが、せっかくUMPにも詳しくなったのだからMIDI 2.0サポートを追加しちゃえ、となって、UMPサポートを追加していました。managed-midiにはMIDIプレイヤーのAPIもあったので、MIDI 2.0用のMIDIプレイヤーなども独自に作り込んでいました。MIDI 1.0プレイヤーは当然SMFをターゲットにしていたのですが、MIDI 2.0にはそもそもSMF相当のものが無いので（今でもありません。仕様はMMAで開発中ステータス）、そういうものを作る必要があるよね…といった考えを持つようになりました。

また2019年に作り始めたAndroid用のプラグインフレームワークでも、MIDI 1.0のメッセージでイベント入力を受け付けるようにしていたのですが、「MIDI 2.0も受け付けられるようにしたらｶｺｲｲんじゃね?」などと考えるようになって、実際に実装していました。MIDI 2.0をサポートするプラグインAPIは、当時最先端だったと思います。

こんな感じで、MIDI 2.0を音楽制作の世界で採用するための下地を整備していこう、という「オピニオン」がいろいろ蓄積されていたので、それを一度アウトプットしておこうという気持ちで書かれたのがこの本です。技術書としては「エッセイ」に近いかもしれませんが、AppleがAUでUMPをサポートし、JUCEもMIDI2サポートを次のターゲットにしていて、ここに書いてきたことがどんどん実現しつつあります。

MML to DAW via MIDI 2.0: 次世代MMLコンパイラ開発研究

2021年刊行。上記の薄い本ではMIDI 2.0採用に関する「主張」を書いたわけですが、やはりここでも「主張したソリューションを自分で実践すべきでは…?」という思いが残り続けました。

この頃、managed-midiからktmidiへの移行が過渡期にあって、MMLコンパイラが生成したSMFからTracktion Engineの楽曲データを生成するaugeneというツールを、ktmidiでも移植してaugene-ngというツールにしていました。そのとき、「ktmidiはMIDI 2.0をサポートしているんだから、MMLもMIDI 2.0対応にできるし、augene-ngはMIDI 2.0の32ビットCCやNRPNからオーディオプラグイン操作もできる次世代MMLコンパイラにできるのではないか?」という発想が浮かんできて、そのまま実装されることになりました。

MIDI 1.0時代のaugeneは、2019年にロンドンで行われたAudio Developers Conferenceで行われたLT大会で紹介してきたこともある程度には古いのですが、この時点でもJUCE AudioPluginHostで設定したプラグインのルーティング情報をプラグイン設定として扱う実装を作っていたものの、打ち込みに実戦投入はしていませんでした。MIDI 1.0の範囲でしかできないことをやってもな…という気持ちがあったのですが、今回は32ビットパラメーターを直接操作できるというので、MMLサンプルもめでたく完成しました。この本はこの具体的な成果を踏まえて「MIDI 2.0を技術的に組み込んだ打ち込みはできるんだ（MMLで出来たことはDAWでも出来るでしょ…!）」という話を書いたものです。この後、Appleも実際にAUにMIDI 2.0を組み込んで、Logic ProもMIDI 2.0をサポートしてきたので、すっかり追いつかれてしまいました(!)

ちなみに、サンプル制作は、前回制作したCDの楽曲でも出来なくはなかったのですが、「OSSなんだしパブリックCIでMP3レンダリングまで再現できるようにしたい」というこだわりが生じて、それを実現させること自体がひとつのプロジェクトとなった感じでした。結果的には何とかなりました。これは本書の余談でこの本には書かれていません。

CLAPオーディオプラグイン開発者ガイド

2022年にはCLAPという新顔が登場して、オーディオプラグイン開発の世界が大きく揺れた1年でした。それまでVSTとAU、あと圧倒的に事例は少なくなるけどLinuxのLV2、といった感じで大勢が決まっていたところに、新しい汎用プラグインフォーマットのAPIが登場して、既存フォーマットの多くの問題点を解決したモダンなAPIだというので、大いに注目を集めました。

新しいオーディオプラグインフォーマットを作るというのは勇気のいる仕事です。「すでにプラグインフォーマットがたくさんあるのに、これ以上新しく対応したくない」という声が出てくるのは必定です。当然ながらそういう反応も出てきましたが（そして今でもCLAPは苦戦しているといえば苦戦しているので、そういう反応が多くを占めているともいえます）、割と歓迎されて将来を期待されていた（いる）ようです。LV2ともろに競合するところもあって、CLAPコミュニティには「LV2はいらなくなった」などと書いているユーザーもいて、あまり治安が良くない側面もあるのですが、オーディオ開発界隈あるあるかな…とは思っています（そう思うようになった）。

Android用のプラグインフォーマットAPIで独自の戦いを邁進している自分も、当然ながら大きな関心をもち、オンライン勉強会も開催して、いろいろ調べたりしました。この本はそれらの成果のひとつの集大成です。CLAPの本ではありますが、前述のLV2本を書いてあったこともあって、この本は「他のプラグインフォーマットとはどう違うのか」という部分を全面的に押し出して書いています。

Linux DTMガイドブック

CLAP本は技術書典13とM3 2022秋に向けて書いたものですが、書き上げた後で「CLAPプラグインの本なんて売れな(ry」とまた思うようになりました。もう少しキャッチーなトピックの本を追加しよう…と思ったものの、特にそんなネタは思い浮かばず、「そういえばLinux用の音源に関して自分のスタンスでいろいろOSSプラグインを紹介したやつがほしかった…」と思っていたのを思い出し、~「プラグイン紹介本」ならスクショだらけですぐにページ数稼げると思って~この本が生まれました。

Linuxオーディオは（他のプラットフォームも多かれ少なかれそうだとは思いますが）Jackの排他制御をきちんと扱えるようになったりALSAやPulseAudio、最近ではPipeWireなども知悉していないと扱えない…みたいな敷居の高い世界観になりがちですが、そうではない、カジュアルにDTMを始めたい勢がWindowsやMacでも使っている人がいるような音源をLinuxでも使える…といった世界観を作り出したいと思って書いたものです。

Audio Plugins For Androidの設計と実装

ここまででたまに言及してきましたが、わたしの最近の主な開発プロジェクトは、Audio Plugins For Android (AAP) というAndroid用のプラグインフォーマットのエコシステムを作ることになっています。オーディオプラグインの仕組みは、デスクトップだけでなくiOSにすら存在するのに、自由に他のアプリケーションと連携できるはずのAndroidにはその仕組が存在せず、DAWは自分専用のプラグインをユーザーに使わせることしかできません。自由な音楽制作ができない、たいへんよろしくない事態だと思っています。

AAPはこの状況を打開するために開発されています。ここまでの書籍でも言及してきたような現代的な機能も含め、オーディオプラグインに求められる機能を実現できるよう、MIDI 2.0ネイティブでモダンな設計を目指し、JUCEアプリなどマルチフォーマットでプラグインをビルドできるプラグインを数多く移植しています（とはいえ、まだまだ開発中で色々足りていないのですが）。

プラグインフォーマットがAndroidに存在しないのは、デスクトップとはアーキテクチャが全く異なるというところに根本的な原因があるのですが、Androidで全く出来ないというわけではなく、できるところまではそれなりにiOSのAUv3に近づけられます。何がモバイルプラットフォームにおけるオーディオプラグインを実現困難にするのか、このAAPというプロジェクトがそれらの障害をどうやって乗り越えたか、またオーディオプラグインフォーマットを設計するとはどういうことなのか、といった思想的な話など、AAPの開発に際して書いておくべきことを（公式ドキュメントとは別に）いろいろまとめあげたものです。

続きはオフライン開場で(!?)

当日の頒布品は以上の10点です…いくらなんでも多くない!?　当日スタッフが見本誌チェックするの（やります）、ちょう大変そう…すまんの…

オフライン開場には、今あるAudio Plugins For Androidのデモ環境も用意して持っていく予定です。まだ大したことができるわけではないのですが、もしこの方面に興味のある方がいたらぜひ試してみてください。

今回は当日スタッフとしても動いていて、また1人で店番をやる予定なので、もしかしたら不在になっているかもしれませんが、いる時間のほうがずっと多いはずなので、もし不在でも懲りずにまた見に来てやってください。