Music Tech Meetup #1 (Night)を開催します

ここ1年くらいずっと「音楽ソフトウェア系の開発者とユーザーの両方をターゲットにした音楽技術の勉強会をやりたい〜」などと言っていたのですが、ようやく時は満ちた…! ということで来月2/6に開催します。

connpass.com

今日の正午くらいに募集開始したのですが、マニヤックな分野の勉強会にもかかわらず既に20人くらい申し込みいただいていてありがたいかぎりです。

経緯

1年も前から言っていたというのは割と本当で、去年もちょうど年末くらいから似たようなことを言っていたのでした。2年続けてロンドンのADCに参加していたので、自分たちはその知見を持ち帰って共有できるし、音楽関係のソフトウェアやSDK（JUCEとかVSTとか）などで面白いセッショントークが出来る人が何人かいたので、開催したらきっと面白いことになると思っていました。

去年はそうこうしているうちにmusic.dev勉強会が発表されたので、とりあえず自分で開催しなくてもいいや…!となったのでした。music.devは一般参加が10人しか入れなかったこと以外は理想的で、バリエーションに飛んだトークが集まって楽しく勉強になる集まりでした。

去年はさらにJUCEもくもく会みたいなことをもう少し音楽技術全般をターゲットにして開催してもいいかなと思っていたら、ちょうどMake Music Things!というまさに音楽全般もくもく会のようなものが始まったので、これまた自分で運営しなくてもいい…!となって、2019年は周りの皆さんの活動におんぶにだっこ状態でのうのうとやってこられたわけです(!)

今回は、セッションを伴う勉強会みたいなことがしばらくなかったのと、music.devは主催のケロさんが2月は東京に来られる準備で忙しそうで#2がかぶることはなさそうだったので、ついに自分で開催しようとなったわけです。

せっかくなので数十人規模で開催したいなーと思ったのですが、Make Music Things!の会場は最大10人ちょいになってしまうので、主催の小出さんと開催は一緒にやっていただいて、会場はどこかを借りてやろうとなりました。ちょうどその頃にLAPRAS社の伊藤さん（まだお会いしたことはないです）のツイートがTLに流れてきまして、

これは会場の大きさ的にも雰囲気としても割とピッタリで天佑なのでは…!?となって、ご相談してお願いすることになりました。勉強会は、いつも会場探しが一番しんどいので、ここを簡単にクリアできたのは本当にありがたいです。

勉強会の方針

今回の勉強会は、ある程度自分たちが知っている人に来てもらえる一方で、知らない人だらけだけど日頃からあるような勉強会ではない（けど興味ある）からちょっと顔を出してみよう、という方がそれなりに来られると思っています。人数もどうがんばっても50人くらいなので、なるべく会場でカジュアルに誰でも話せるようなふいんき（なぜか変換できない）にしたいと思っています。

もうひとつ、IT系技術の勉強会はプログラミング言語やプラットフォーム、開発ツールなどに関連するものが多く、ほとんどが開発者「だけ」をターゲットにしているのですが、わたしみたいに開発フレームワークを提供する立場にいた人間としては、参加する「開発者」にも「ツールの開発者側」と「ツールのユーザー側」がいると思っています。両方がいて勉強会が成り立っているわけですね。これは音楽系のソフトウェアの場合でも当てはまるはずなので、この勉強会では技術やツールの開発者と同様にユーザーとしてのミュージシャンやDTMerの人たちをターゲットにする、音楽を制作するための技術や知見を広めるセッションもあります*1。ふだんこの方面のセッションを聴けることはそうそう無いと思うので、割と貴重な場になると思います。

今回はセッションがありませんが、音楽技術のとくにゲーム開発の分野では、音楽の制作と同時にサウンドドライバーを制作したり、古くはMMLのようなプログラム類似の言語で作曲したでしょうし（今でも商業でやっている人がいますね）、今でもスクリプトでサウンドオブジェクトを制御することもあるかと思います。あるいはミドルウェアを導入したりといった知見も広く求められることがあり、この意味ではサウンドエンジニアも開発者との境界線が割と曖昧だと思います。この分野だとCRI ADX2などの勉強会も別途さかんですが、知見を共有できる人がいたらぜひ来てほしいと思っています。あとはVRなどで3Dサウンド処理もホットなトピックですよね。

この集まりは現状スポンサーがいるわけでもないので、夜の勉強会ですが軽食を用意するのもしんどいです…というのを逆手に取って、参加される方にお気に入りの食べ物などを持ち寄っていただくことにしました。開始と同時に食べ物をつまみながら話を聞いていただこうと思っています。発表が終わるのを待ち続けてフードが冷めちゃったら悲しいので、食べておいしい時に食べましょう。もちろん手ぶらでも大丈夫です。全員がたくさん食べ物を持ってきたら余るでしょうし…!

今回の勉強会では、可能な限り多くの人に抵抗感なく気配りしてもらえるようなCode of Conductを考えて設計してあります。困ったことがあったら相談してください。

セッション紹介

Audio Developers Conference 2019で見てきたオーディオ開発最新動向

わたしが勉強会を開こうと思った発端が「ADCのセッションとかで発表されているような話を紹介して、詳しく知っていそうな人とかに参加してもらってわいわい話したい」みたいな感じなので、同じくADCに2年連続で参加しているJUCE Japanのしおざわさん @COx2 と2人で漫談することになりました。（ってタイトルをわたしが勝手に付けてしまっているのですが、このへんは諸々調整する予定です…!）

ADCにはさまざまなプレイヤーが参加しています。Roland、YAMAHA、KORGなどの楽器メーカー、Native Instrumentsみたいなオーディオプラグインベンダー、ROLIやSteinbergのようなオーディオプラグインフレームワークベンダー、AppleやGoogleあるいはELKのようなプラットフォームベンダー、音楽と機械学習のソリューションを提供するベンチャー企業など、バックグラウンドはさまざまです。2日間で行われたセッションのほとんどはyoutubeで公開されています（1日目、2日目）。

現地でも見ましたがフルパワーで見ていたわけではないので、わたしはいろいろチェックして臨むつもりです。

エフェクターを作ろう

Make Music Things!を運営している小出さんによるセッションです。小出さんには他のセッション予定とかぶらなそうなトピックの狭間で決めていただいた感じなのですが(!)、結果的にハードウェア寄りでエフェクターを作るための回路設計についてお話しいただく予定です。お仕事がその方面みたいです。うらやましい…!*2

Make Music Things!の集まりは、ソフトウェアだけしかやらないわたしみたいな参加者も何人かいるし、Maker Faireとかに出展するような物を制作している参加者も何人かいるという感じで、独特のバランスでまとまっています。1人で黙々と作業することもできますし、他の人と相談やら雑談やらしながら過ごす人もいます。割と物理層の話で盛り上がったりすることもあります。

概ね毎月やっていて1/25にも第6回があるので、この辺の開発に携わっている人とわいわいやりたい人がいたらぜひ来てみてください。

変拍子兄さん & 腕毛の人 の変態音楽理論（タイトル未定）

タイトルはまだ未定なのですが、変態音楽理論アカデミーというnoteのページを公開されている変拍子兄さん @OrangeTheKeyqa と、一緒に音楽活動されている腕毛の人 @stereonoah のお二人に、独自に構築されている音楽理論に関する発表をお願いしました（もしかしたらしゃべるのは2人ではないかも）。内容はほぼ白紙でお任せしてあるのですが、たぶん微分音を活かした作曲の方法論などが内容となるのではないかと思います。

微分音というのは説明なしでは「??」となるかと思います…。ふだんわれわれが音楽を打ち込む時に使う音階は12平均律（一般的には12も抜いて単に平均律）とよばれ、周波数の比率で1オクターブの音をド〜シの12音に分割構成しています。しかし世の中には他に純正律と呼ばれる、特定の和音だけがよりきれいに響くような周波数で構成された音階などもあります。さらにはそもそも1オクターブを12で割る必要だって無いはずでは…?と考えると、1オクターブを24分割したり31分割(!?)したりといったことも出来るわけです。MIDIメッセージはどう考えても12音階なわけで、どうやってこれを乗り越えて作曲するのか…? など、いろいろ刺激的な話が聴けるかと思います（白紙委任ですが!）

ちなみに、このおふたりとは昨年の同人音楽イベントでサークルスペースが隣同士だっただけです（ゆ〜くれというこれらの音楽理論などによる音楽を発表しているこのお二人のユニットです）。普段から勉強会でセッションやっているようには見えなかったのですが、音楽理論系のセッションをお願いする場としてはピッタリだと思ったので、おっかなびっくりお願いして受けていただきました（ありがたい〜）。

ライトニングトーク

今回もう1つセッションがあるかもしれませんが、無いかもしれません。その代わりに、というわけではありませんが、LTタイムを設けてあります。おそらく自分が開発したり使っていたりするソフトウェアや楽器、あるいは音楽制作手法などについて喋りたいという方が少なからずいるのではないでしょうか。と思って募集に含めたのですが、既に申し込みいただいていて、「計画通り…!」（画像略）という顔をしています。まだ枠があるのでやりたい方はぜひ申し込んでください。

ちなみに、勉強会参加者枠を別にすることも考えたのですが、LTで何かしゃべれることあるかな…?って悩んで参加枠を迷っているうちに人数がいっぱいになって悲しい思いをすることが稀によくあるので、LT申込み枠は分けずにコメントで書いていただくという設計にしました。いろいろ考えてます…!

Music Tech Meetup #2 (Day) もやりたい

今回は1回目ということで、お試しという感じで平日の夜開催ということにしました。会場も平日限定ですし（そういうところが多いはずです）、まずは平日に開催して感触を得ておこうという腹づもりです。

まだ第1回を公開したばかりなのですが、他にもあの人やこの人にもしゃべってもらいたい…!みたいなリストを（勝手に）かかえていて、「でもこの話なら50分とかでフルタイムでお願いしたい…」みたいな状態になっているので、そのうち土日開催してフルタイムセッションを容赦なく詰め込むのも開催したいと思っています。

そういうわけで今後の展望も意識の隅におきつつ、まずは2/6の勉強会をうまいこと開催したいと思っていますので、この分野に興味のある方は（まだあまり機会が無いと思うので）ぜひ参加してください。

*1:昨年のmusic.devもそうなっていました。

*2:いや無職はひとの仕事を羨ましがらないぞ…!!

さいきょうのCode of Conductを求めて

こんど新しく勉強会を立ち上げるのだけど、2020年に新規コミュニティを立ち上げるのは、自分が今までやってきたような勉強会（Xamarin.Forms読書会とかmono meetingとか）を作ってきたようなのとはだいぶ状況が違うようだ。特に最近よく話題になるのはCommunity Code of Conduct（CCoC, CoC）に対する何かしらの意思決定を求められる、というところだろう。

今回いろいろ考えてCoCをまとめることにしたのだけど、一般的なCoCに比べてだいぶ大きな改善を施したので、それに至るまでにいろいろ検討したことを参考までにまとめておきたい。

目次

完成品

この行動規範は、コミュニティイベント参加者のコミュニティイベントに関連する行為についてのみ適用されます（被害者や視聴者がコミュニティ参加者に限定されることはありません）。

このコミュニティのイベントにおいては、参加者には、性別、性的自認・性的指向、年齢、障害、身体的特徴、人種、民族、宗教（あるいは無宗教）、技術的指向などを理由としたハラスメントの無い状態を維持すべく行動していただきます。コミュニティ主催者は、コミュニティのために、コミュニティ参加者によるいかなる種類のハラスメントも歓迎しません。性的な意図での画像等の表現は、イベント会場での発表や歓談、Fediverseその他のオンラインメディアを含め、コミュニティイベントに関連するものとしては不適切であり提示しないものとします。

違反行為の態様によっては、このコミュニティでは退席を求めることもあり、また以降の参加を認めないこともあります。有償イベントの場合、払い戻しを受けることはできません。しかし、誰もが問題を意識せずに違反行為を行う可能性があります。この行動規範は問題を改善するためのものであり、実効的な改善が期待できるうちは違反を繰り返さないよう注意するに留めることを目指します。

この行動規範に反する問題のある行為を受けたり、困っていそうな人を発見した場合は、コミュニティ運営メンバーに連絡し対応を求めてください。主催は参加者のみなさんが安心して参加できるために必要な処置を、予防的なものも含めて実施します。コミュニティ運営メンバーによる違反行為についても同様に情報提供を求めますが、十分な対応が期待できない場合はFediverseなどのソーシャルメディアに助けを求めてください。ハラスメント処分について不満がある人も同様です。ハラスメントに該当するか否かは規範的な判断が不可避であるため、主催者と当事者では判断が異なることがあり得るためです。

契約書などの規約に著作権は存在しないので（船荷証券事件）、無断で自由に複製したり、自分たちのCoCに取り入れたり、好きなように使っていただいて問題ない。

2022/12/19追記: 本文を一部改定し、"Twitter"をSNSの例示から除外し、Fediverseに置き換えました。

2023/02/03追記: 「主催は参加者のみなさんが安心して参加できるために必要な処置を、予防的なものも含めて実施します。」という一文を途中に追加しました。コミュニティに安心して参加してもらえるためには、主催はCoC違反と判断するか否かに関わらず「当事者の安心を確保するため」に（合理的な範囲で）対応することを明示的に宣言するものです。

CoCの本質は何か

CoCの策定について論じる前に、CoCの本質的な性格について少し前提を共有しなければならないだろう。一般的なCoCとは、実効性（処分）を伴う私的社会集団の規則として実装された法あるいは規範である。

「実効性（処分）を伴う」というのは、CoCに違反した者に対して、コミュニティへの不参加や、法的に有効に支払った参加費の返還を伴わない役務（債務）の不履行が正当化される、ということだ。当事者の合意が無いのに債務を不履行とするのは、法律的には不法行為だ。法的な不利益処分を伴うのだから、本来は「CoCは単なるガイドラインである」という（主にあいまいさに対する）釈明は通用しない。CoC違反による処分は、コミュニティ活動を違反行為によって妨げられるという損害を抑止するという理由で法的な後ろ盾を得る。

「法あるいは規範」というやや中途半端な表現を用いたのは、ローレンス・レッシグがCODEで提示した古典的な四規制力（法、規範、市場、アーキテクチャ）では自明に分類できなかったためなのだが、法律のような強制力を伴う一方で、その私的社会構成員の意思を反映しなければならないという憲法も無く、恣意的に策定される危険性がある、という理解にもとづく表現だ。これを規範に近づけると、究極的にはCoCが無い状態である（構成員の良識に100%依存する、あるいは主催者がそう言明するような事態）。

CoCを策定するのであれば、それは健全な法とならなければならず、参加者の合意（すくなくとも理解）が得られる必要がある。2020年現在は、CoCのありかたを巡って、さまざまな立場があり、それらが衝突している状態にあり、このような闘争状況においては、規範に近いルールの制定であっても、策定内容をめぐる合意について、法律と同レベルの正統性（規制根拠）が必要になるはずだからだ。

また、人の自由を拘束する、特に表現の自由を拘束するものでもあるから、法律に関する表現の自由を制限する場合の正当化に要求される二重の基準なども、適切に満たすことを目指さなければならない。

規則とは雰囲気で身勝手に規定してはならないものであり、策定者は規則の策定を拘束する規則や理念（法律であれば憲法）を遵守しなければならない。「CoCを策定しろ」と要求する者は、コミュニティの代表者に対してそれだけの覚悟を示せ、と言っているのに等しいということを自覚しなければならない。そして残念なことに(?)、現状ではその要求はどちらかといえば妥当なものであると自分は考えている。

CoCを策定することに対する批判的議論とそれらへの対応

CoCの策定にあたっては、そもそもCoCを策定すべきか否か、という意思決定がある。最近はCoCを策定しないだけで非難される・ペナルティを受ける・「差別」される*1という風潮があり、CoCを制定「しない」という決定それ自体が意味のある意思決定になっている状態だ。

CoCを「策定しない」ほうが望ましいと考える立場は、（おそらくアナーキズムにも類する議論が既に多数あるだろうが）自分が理解している範囲だと概ね次のような論理がある。

他人の行為を「禁止」できる「コミュニティ」とは一体何者なのか?

この問題を解決するためには、「コミュニティ」における活動とは何を指すのか、について明確に定義する必要がある。CoC違反に基づく処分を執行することができないのであれば、それはもはや規則ではないし、正当な権利もなく他人の行為を禁止する行為は厳しく制限されなければならない（究極的には業務妨害罪にもなり得る）。

具体的には、コミュニティ活動とは無関係なTwitter上の投稿内容が差別的であったり性的であったとしても、それを理由にコミュニティから排斥することは許されない。それはコミュニティ活動ではないからだ。コミュニティ参加の場たとえばセッショントークにおいて差別的な発言をする「おそれ」がある、と主張する場合には、その「おそれ」は具体的なものでなければ、法律における表現の自由の規制を正当化する「二重の基準」を満たしていない。

なお、CoCを遵守すべき主体はコミュニティ参加でありその守備範囲であるイベント等に付随する場合に限られるが、言及される対象はコミュニティ参加者に限られない。これは現時点で参加していない人の新規参入を妨害してはならないためである。

参加者が合意していないものを強制できるのか?

民主主義社会において、法律は主権者たる国民を代表する国会（日本国の実装の場合）が策定する（そして国会議員は憲法に拘束され、その立法内容は憲法に反してはならない）。法律の場合、国民に法律を遵守する義務があるのは、それが間接的には自らが定めたためである、という理屈で正当化される。憲法学には憲法制定権力は何であったか、という論点で議論がなされるし、刑法で言えば、罪刑法定主義や明確性の原則といったかたちで実装されている。

CoCにはこれが無く、あくまでコミュニティ運営者が身勝手に策定しているものだから、少なくとも参加にあたって事前に十分に提示して同意してもらう必要がある。

強制力があるかないか、という問題で言えば、CoCを「執行」出来る場面は限られている、ということは言える。限られてはいるが無いわけではない、という程度のものなので「それならば無いほうがマシ」という再反論は有効だ。

一方で「CoCは憲章であり違反に対応する手続きを定めていることで差別等への抑止力になる」という指摘はあり、この点では具体的な処分が機能しなくても意味があるといえる。

CoCに合意できない一部のメンバーを積極的に排除するために規定するものなのではないか?

CoCを策定する行為そのものが差別的な意図に基づいていないことは必要条件だ。特定個人を狙い撃ちで排除するために定めるCoCの条項は原則として無効になるべきものだ。排除された者が「差別的だ」と感じたら、その主張をきちんと取り上げて判断する公正な機関が必要だし、無ければSNS上でコミュニティが非難されることになる。

ここには三権分立の機能していないコミュニティという組織に特有の問題があり、コミュニティ運営者が自ら定めたCoCおよびそれに基づく処分について、自らが違反であると判断することはおそらく稀なので、公正な判断機関に準ずるものとしてSNS等における「裁判」が機能する余地がある。SNSもポピュリズムで動く側面があり公正であるとは言いがたいが、少なくとも別の視点をもたらし得る存在ではある。排除される者がSNSに助けを求められるということを、少なくとも明記しておくことは、より公正なルールを担保することに繋がる。

善良なコミュニティには「ルール」を規定する必要はない。「真面目な」生徒が大半を占める中学校・高校には校則がほとんど無いではないか?

これには部分的に正しい側面があるが、試験等で生徒をフィルターしてきた学校とは異なり、CoCを規定しなくても問題がないというような議論が出てくるくらい一般的なコミュニティはほぼ「差別的であってはならない」だろうし、どんな参加者でも最初は歓迎する義務があるはずだ。となると、「善良な」構成員しか集まらない、という主張は、一般的には論理として成り立たないといえる。

違反の判断基準が恣意的ではないか?

正当な批判であり、100%対策されているので問題ないと反論することは論理的に不可能であると考えられる。

これは刑事法では「規範的」判断といわれるもので、たとえばわいせつ物陳列罪における「わいせつ」の範囲は何か、といった、明確な答えのない問題になる（そのため同罪には根拠が無いという批判も有力だ）。CoCの場合は、単に「差別はいけません」のような言い方では明確性の原則に反するので、少なくともどういう項目で差別該当性が判断されるかを列挙することが望ましい。

ただ限定列挙にするほど厳密にするのは難しいかもしれない。理想をいえばCoCは常に更新されるべきであるが、現実には追いつかないだろう。フィクションを前提にした規則は、空洞化し悪用される可能性が上がる。

いずれにしても、問題となりうる「曖昧さ」を可能な限り縮小して、CoCが無いことによる不利益と比較衡量して納得してもらうしかないだろう。

処分の有無の判断基準が恣意的ではないか?

正当な批判であり、100%対策されているので問題ないと反論することは論理的に不可能であると考えられる。

これは刑事法でも同様なのだが、犯罪に対して処罰が固定されることは通常はあり得ず*2、通常は情状を酌量される。また通常は初犯に対しては執行猶予がつく。法律に恣意的な運用の問題が無いわけではないが、法律でも同程度の問題が生じているので、少なくともCoC固有の問題ではない（規則を定めれば定めるだけ恣意的な処分が世の中に増えるということになるのだから、「法律もそうだから問題ない」という反論は成り立たない）。

一方で「公平性を担保するため、常に退会処分とする」といった運用に傾くと、同じ違反行為を犯すならより悪質な行為に走るということにもなる（饅頭を盗み食いしても殺して財布を奪っても死刑なら、後者のほうが利益が大きい）。「注意」のような処分すなわち執行猶予がつくほうがコミュニティ全体としての安心感が上がるはずだ。

こういった対策で問題の生じる可能性をなるべく縮小して、CoCが無いことによる不利益と比較衡量して納得してもらうしかないだろう。

CoCで策定されるべき事項とそうでない事項を検討する

2020年時点で議論されている「CoCは必要である」という議論に一般的に欠落しているのが、次のような問題に対する真剣な検討である。

  • CoC適用の公平性担保
  • 正当な理由のない禁止の禁止

これらはいずれも「コミュニティ運営を拘束し負担を大きくする」ものである。自己中心的なコミュニティ運営者がこれらの問題や議論を避けるとしてもそれは本能だが、正当化される本能ではない。これらの議論を回避することで被害を受けるのはコミュニティ参加者なのである。

CoC適用の公平性担保、特にSNS等に訴えかけられるという次善策の提示

三権が分立した法律の世界のイデアにおいては、立法者と司法者は別個の機関であり、これによって法の公平な執行に対する期待値が上がる。CoCの対象であるコミュニティには通常そのような体制は無い。しかし、コミュニティ運営者が「差別はいけません」などと言いながら、一方では自分の嫌いな参加者に対して差別的に待遇していたら、CoCは正当化しえない。こういう場合に備えて、まず運営者もCoCに違反する可能性があることや、そのような場合に被害者がどのような対応を取ることが出来るのか、提示しておくことは重要だ（もっとも「SNSで訴えかけると良い」というくらいしかできないが）。

「SNSで訴えかけることが出来る」と言明しておくことにはもうひとつの効果がある。「SNSで公に指摘するべきではなく、運営に相談すべきである」という言い分を否定することができるのだ。SNSで指摘するのは本人がしたいからそうするのであって、それを強制的に隠蔽するべきではない。もちろん運営が適切に対処していて、被害を受けたという主張が正しくなさそうであれば、虚偽を拡散したという非難を免れることはできないが、それは本人の責任だし、「被害を100%立証できなければ公に発言すべきではない」という主張は、個別の事実関係なしには語れない以上、妥当ではない。被害者が被害を受けたという事実を、本人の意思に反してコミュニティ運営者が隠蔽するような状態を、コミュニティ運営が正当化することはありません、という意思表明だ。

もちろん、運営が相談されたら対応するのは当然のこととして、CoCに規定する。

正当な理由のない禁止の禁止と「非技術的なノイズ」問題

CoCは強制力のある法としての側面があるのだから、正当な理由のない禁止条項は排除されなければならない。一方で、CoCは行為規範として容姿等に言及する行為を禁止対象として列挙するのが一般的だ。

この禁止を正当化する理由としてよく挙げられるのは「外見・容姿に関する言及は非技術的な評価であり、（技術的な勉強会においては）ノイズであるから有害である」という立て付けの議論だ。もうひとつ「外見・容姿に関する言及は身体的特徴に関する差別的なものである」という考え方がある。自分は、一般的には後者を否定する余地はなく、禁止は妥当であると考えている。前者については、状況に応じて禁止すべき時とそうでない時があると考えている。

非技術的な情報が技術勉強会においてノイズになることは間違いない。しかし「ノイズであれば排除して良い」ということは必ずしも言えない。二重の基準論で考えれば、ノイズを排除しなければ他の利益が損なわれる（損なわれた）など、表現を規制するに足る正当な理由が必要になる。外見に（非差別的に）言及する*3参加者がいた結果、まともに勉強会として参加できる雰囲気ではなくなった、という事態があれば、それは禁止に値する有害なノイズであったと言える。

何がノイズになり、何がノイズにならないかを事前に予測するのは、多くの場合は容易ではないが、一方で法の執行には「予見可能性」が無ければならない。独自の視点で「この発言は差別的ではないか」と気付く参加者もいるかもしれないし、言われれば同意する参加者もいることだろうが、発言者にそのような意思が無かった可能性をきちんと考慮し、まずは配慮を促すという対応が必要である。「望ましい」ではなく「必要である」とする根拠は「予見可能性」だ。人は自らが予見できなかった行為・結果について責任を問われることはない。故意が認められないためだ。

また発言者も含め他の参加者が不同意を表明する自由は、必ず守らなければならない。

「非技術的なノイズ」の問題は、参加者がSNSなどで外見・容姿について言及する場合だけでなく、講演者が自ら非技術的な興味を引く目的で外見を調整する行為にも当てはまる。これを「どこまで許されるか」という議論にすると答えの見えない問題になるが、視点を変えて、たとえば外見を整えるために参加者の手を借りたり「いい写真」の撮影を依頼するような行為があれば、それは非技術的なノイズを増やす故意があると言える。

同様に、外見・容姿にかかる言及は「優遇」であることも多く、「被害者の同意」がある場合もある。これは他の講演者や参加者と相対的に比較する状況や側面があれば明確に有害だし、そうでない場合でも参加者が自らの容姿・外見等を意識させられるような状況が生じるのであれば、それは差別的言及である。特定メンバーに対する外見的な優遇は外見的な差別であることを意識すべし。

いずれにしても、容姿・外見等に関する言及があった場合は、当人らがネガティブに感じるようなものであれば十分にCoC違反の条件を満たすし、そうでない状況でも当人の故意の有無などをきちんと個別具体的に把握して、実害のあるものは排除するよう「毅然と」＝公正に対応する必要がある。単に積極的に科罰的に振る舞うことを「毅然とした対応」と勘違いしてはならない。

障害からの回復という目的を忘れない

人は誰でも失敗するし、これはCoC違反についても同様だ。CoCは違反者を糾弾するために存在するのではなく、問題を是正し再発を抑止するために存在する。CoCに違反した人は（その判断に同意するなら）反省等を示して再発を防ぐよう気をつければ良い。「気をつける」以外の対策がなければそれは単なる精神論であり再発する可能性があるのだから、具体的な改善案が無いのなら再発を弾劾してはならない。

ここまでの項目ではコミュニティ運営者により大きな責任が課せられるような内容が続いたが、運営者も万全ではないし、CoCはコミュニティ運営者が間違えることを想定していなければならない。判断ミスの回復に務めるべきではあるが、単に判断を誤ったことを理由に直ちに退任させられたらそれは運営者に対する不正なサンクションである。クビは改善が期待できなくなってからで十分だし、処分の公平性は運営者に対しても妥当する。

カジュアルに失敗し、カジュアルに問題を指摘し、カジュアルに改善することが、CoCを据えるコミュニティが目指すべき状態である。

さいきょうを目指して実装されたCoC

以上のようなことを考えながら、最初は3年前に自分が翻訳したcommunitycodeofconduct.comのやつをコピって多少いじるだけにしようと思っていたのだけど、冒頭に挙げたもののように、だいぶ書き換わることになった。CoCは法の世界のように憲法と法律が分離していることはなく、すべてが単体で完結しているので、その中に憲法的な「代表を縛る」ための条項を公平性の担保としていくつか追加することになった。実体法と手続法も一体化しているが、これは一般的なCoCも同様だろう。

近々公開する勉強会でこれが採用されるかどうかは未定だが（コミュニティは自分が作るとしても自分が恣意的に全て決めて良いものではない）、採用されなくても誰かしらの指針になると良いなと思っている。

最強のルールとは、みんなに気持ちよく遵守してもらえるようにフェアに設計され、違反行為にもインクルーシブに対応できるようなソフトローであると自分は考える。

追記: フィードバック

内容の語句にはいろいろ選択肢があるはずなので、自分のスタイルに合わせて調整するのが良いでしょう。

*1:「差別を受けたと感じた者がそう表明した」場合は、少なくともその気持ちをリスペクトすることが求められる。差別に配慮する人間ならそう考えるはずだ。

*2:是非はともかくとして外患誘致罪のような例外がある

*3:差別的に言及する行為が容認されないことは書くまでもないだろう。

juce_emscripten: 最新のJUCE on WebAssembly

English version

目次

2020年元旦からわれわれの界隈には刺激的なニュースが出てきました。

www.dtmstation.com

この記事で触れられているDreamtonics社がgithubで公開しているというのは、このjuce_emscriptenというJUCEのforkプロジェクトです。emscriptenを活用してwasmおよび周辺ファイルを生成します。

github.com

ちょっとだけ（本当にちょっとだけ）開発の手伝いをしていたので、詳しい解説をまとめようと思います。

Dreamtonics/juce＿emscriptenは、JUCEオリジナルからのforkではなく、もともと5年くらい前にemscriptenでJUCEのWeb版を作ろうとしていた先人のプロジェクトのコードに基づくものです。これはかなり古いJUCEのバージョンに基づいているので、Dreamtonics/juce_emscriptenは最新版のJUCEにアップデートして、自社プロダクト（完全にJUCEで作られたアプリケーション）をビルド出来るようにした、ということになります。

（JUCEアプリケーションがWebブラウザで動作する先例としては、WebAudioModules (WAMs)を使用したWebDexedやWebOBXDといったアプリケーションがありました。WAMについては https://qiita.com/COx2/items/1f19d045936eebc3b82d でもう少し詳しく触れられているので、これを読むと良いと思いますが、WebAudioModules APIはemscriptenを使用してJS上とネイティブコードの相互運用のごく基本的な部分だけを規定して、あとはC/C++のアプリケーションをそのまま移植できるようにしたものといえます。これらを実際にJUCEと統合した部分のソースコードはWebOBXDのリポジトリで見られます。）

この最新のjuce_emscriptenがどれだけ実用的になっているか、まだ試していない人はここで試してみてください。

synthesizerv.com

juce_emscriptenを体験する

juce_emscriptenでは、JUCE本家のサンプルであるexamples/DemoRunnerがビルドできるように設定されています（後で言及しますが、juce_emscriptenはProjucerが対応していないので、Emscriptenでビルド出来るように調整されたMakefileが用意されています）。わたしが確認した限りではLinuxとMacでビルドできます。WindowsならWSLでもできるでしょう。

emsdkがローカルで使える状態になっていない場合は、まずemmakeを使えるようにセットアップする必要があります。juce_emscriptenのREADME.mdにあるビルドの説明が簡単です。

$ git clone https://github.com/emscripten-core/emsdk.git
$ cd emsdk
$ ./emsdk install latest
$ ./emsdk activate latest

emsdkがセットアップできたら、Emscriptenのツールチェインを呼び出せるように環境変数を設定します。インストールは1回で十分ですが、環境変数はその後いつでもemmakeを呼び出す前にシェル上で設定しておく必要があります。

$ source ./emsdk_env.sh

あとはemmakeでビルドするだけです。Emscripten用のビルドはexamples/DemoRunner/Builds/Emscriptenディレクトリ上にあります。生成済みのものがあるので、Projucer --resaveで生成する必要はありませんし、実のところ上書きするとビルドできなくなるので注意が必要です。

$ cd /path/to/juce_emscripten/examples/DemoRunner/Builds/Emscripten
$ emmake make

ビルドしたWebアプリケーションはローカルのChrome/Chromiumで実行できます。公式ドキュメントではcd build && python -m SimpleHTTPServerですが、わたしはnpx http-server buildで動かしています。HTTPサーバなら何でも良いです。

f:id:atsushieno:20200101003632p:plain
DemoRunner sshot

2021.12.30追記: このエントリーを書いてから、SPECTRE対策でSharedArrayBufferは無効化されるようになり、この手順では使えなくなりました。2021年現在、SharedArrayBufferはサイト側でCORS対策していないと利用できません。npx http-serverだと対応できない（--corsオプションだと足りない）ので、この辺のやり方を真似するとよいでしょう。

JUCEのプラットフォームバックエンドの基本

一体何をどうやったらデスクトップアプリケーション向けのフレームワークであるJUCEがWebブラウザで動作するようになるのでしょうか?　普段からクロスプラットフォームライブラリの実装を追いかけている人から見れば自明のことですが、どのクロスプラットフォームのライブラリも、プラットフォーム固有の部分を個別に実装して、（一般的には）共通のAPIのみを安定APIとして公開する、というアプローチが採られます。

JUCEの場合、本家がすでにWindows, Mac, Linux, iOS, Androidをサポートしており、そのプラットフォーム固有部分はJUCE本体の各モジュールで実装されています。JUCEはわれわれがよく目にするReact Native, Xamarin, Flutterといったクロスプラットフォーム開発フレームワークとは異なり、オーディオアプリケーション開発が主眼にあり、オーディオ／MIDI IO部分もクロスプラットフォームで実現する必要があります。オーディオ/MIDI IOはjuce_audio_devicesというモジュールで、GUIはjuce_gui_basicsというモジュールで、主に実現しています。

また、GUIは主にメインスレッド上で動作するメッセージループのコールバックに基づいて動作する仕組みがどのOSにも存在しており、これはjuce_eventsというモジュールに独立して存在しています。メッセージループのコールバックの仕組みはオーディオI/Oでも用いられており、このjuce_eventsはjuce_audio_basicsにとっても依存モジュールのひとつです。GNOMEデスクトップ開発に慣れている人であれば、gtkとglibが分かれていることを知っているかもしれませんが、juce_eventsはjuce_coreと合わせるとglibのような位置付けになります。

これらのモジュールのソースコードの中に、プラットフォーム固有の実装が含まれています。juce_audio_devicesの場合はjuce_audio_devices/nativeに、juce_gui_basicsの場合はjuce_gui_basics/nativeにあります。それぞれのディレクトリにAndroidだのiOSだのwin32だのといったファイルが含まれていることがわかるでしょう。

そして、プラットフォーム固有の実装は、自分で追加することもできるのです（そういえば今年のJUCE Advent Calendar1日目の記事もそういう内容でしたね）。juce_emscriptenは、ここに新しくemscripten / wasm用の実装を追加するものです。

自分のプロジェクトをjuce_emscriptenでビルドする際の注意点

juce_emscriptenは、条件が合えば自分のプロジェクトでも利用することが可能です。DemoRunnerとSynthesizer Vが動くというだけではもったいないので、他のアプリケーションも動くようにしたいですよね(!?)

ただし、現状ではjuce_emscriptenはSynthesizer Vが動作するために必要最低限のコードが実装されているものであって、まだいろいろ足りない部分があり、またビルドしたアプリケーションが動作するまではいくつかの手作業が必要になります。以下で少しずつ詳しく説明していきます。

missing modules

まず、README.mdのStatusセクションを見ると、どのモジュールがサポートされていないかがわかります（流動的に増えるかもしれないのでリンクだけ示しておきます）。

特によく引っかかりそうなのは、JUCEでよく使われていそうなオーディオプラグインサポートのためのモジュールjuce_audio_plugin_clientで、これはまだサポートされていません。juce_audio_plugin_clientを使っているアプリケーションはstandaloneでもビルドに失敗します。

もしサポートされていないものを使っている場合は、そのモジュールの機能を使わないように改造するか、ビルドエラーをもとに自分で実装する(!)しかありません。ゼロから自分でGUIもオーディオも実装するよりは、はるかに楽になっているはずですし、移植のための知見も本家との差分から調べやすくなっているとは思います。

missing Projucer builder type

また、現状ProjucerでプロジェクトファイルをEmscripten用に生成することはできません。Emscriptenの一般的な使い方と同様に、ProjucerでいったんLinuxMakefileを生成して、その内容に手を加えることになるでしょう。DemoRunner.jucerには、Emscripten用の出力ターゲットが追加されているので、これを再利用するのが一番手っ取り早いです。

注意すべきは、Projucerで出力したMakefileは、そのままでは使えないということです。DemoRunner.jucerには次のようなコメントがあります:

After resaving, do the following by hand:
Remove $(shell pkg-config ...) from the Makefile
Change JUCE library path to juce_emscripten
Add .html extension to target app
Optionally, add -s SAFE_HEAP=1 -s ASSERTIONS=1 to JUCE_CFLAGS for Debug build
Optionally, add -s WASM_OBJECT_FILES=0 to JUCE_CFLAGS and
 --llvm-lto 1 to JUCE_LDFLAGS for Release build.

重要なのは(1)JUCEモジュールのパスをProjucerの指定するmodulesのパスからjuce_emscriptenリポジトリのmodulesに置き換え、(2)pkg-configを呼び出している部分を全部消すことと、(3)JUCE_TARGET_APPに拡張子.htmlを追加することです（こうすることでemmakeのビルド結果が.html、.js、.wasm等のセットになります）。これはProjucerで保存するたびに行う必要があります。

2020/02/02追記: これらに加え、JUCE_CPPFLAGSに -I/usr/include/freetype2 を追加してやる必要もありそうです。（本当は/usr/以下のパスを指定するのは良くないような気もしますが…）

LinuxMakefileのビルドファイルを手作業で編集するのが面倒になったら、Projucerに手を加えるような変更をcontributeすると良いかもしれません(!)

ちなみに、Projucerで新規GUIアプリケーションを作成して生成されたプロジェクトは、実のところビルドできません。利用モジュールの中にサポートされていないjuce_openglが含まれているためです。Projucer上でこのモジュールを外すと良いでしょう。

missing resources

もうひとつEmscriptenの制限でちょっと面倒なのは、フォントファイルをはじめとする各種リソースをemccの--preload-fileオプションで組み込まなければならないということです。実のところフォントを組み込まないとシンプルなASCII文字列すら描画してくれません。先のDemoRunnerでは、Linuxビルドが参照しているX11のフォントリソースを取り込んでビルドするようになっています。

DemoRunnerのビルダーを使い回す場合は（使いまわしたほうが楽だと思います）、DemoRunner固有の--preload-fileオプションは外しても大丈夫ですが、X11R6のフォントはコピーした上で--preload-fileを指定するのを忘れないようにしましょう。

足りない機能は自分で移植できる

いかがでしたか?（キュレーションサイト風） juce_emscriptenを使うと、既存のJUCEアプリケーションをWebブラウザ上にもってくることが、だいぶ現実的に可能になってきたことが見て取れたのではないでしょうか。

ただ、JUCE本体は幅広いツールチェインでサポートするプロジェクトの種類も多様です。おそらく"GUI Application" 以外の種類のプロジェクトを移植するには、juce_emscripten本体をちまちまとハックする必要があるかもしれません。とはいえ、おそらく最も面倒であろうGUIとオーディオI/Oのコア部分は、オリジナル開発者とDreamtonicsによって移植されているので、足りないところは問題にぶち当たった時にちまちまと実装してcontributeしていくと、完成度が上がっていくのではないでしょうか。

おまけ

2019年の仕事振り返り

仕事と言っても無職だけどな…!

2019年は、1年半前に始まった大無職時代をどのように生きるか、という問題に立ち向かった長い1年でした（こう書くと物は言いようっぽい）。音楽ソフトウェア開発者として、何もなかった頃の1年前と比べると、割といろいろ勉強できたと思います。

目次

1-2月 音楽制作環境（特にDAW）に慣れる

3/2に幻想音楽祭という音楽同人イベントがあり、第1回っぽいし初参加するにはちょうど良さそうな規模だったので、一度まじめに音楽制作というやつに取り組んでみてもいいかな〜と気軽に応募したのが通っていたため、昨年末から今年の最初の2ヶ月はそのために費やされました。

今でもそうといえばそうなのですが、特段「創作したい」という意識があるわけではなくて、自分の作っているMMLコンパイラ中心の制作環境がどこまでプロダクションで使えるのか試しておきたかったですし、自分の実用に耐えるレベルになる、というところまでは作り込んでおきたい、そうでないとこのアプローチを推奨することはできない、と考えていました（います）。

また完成品を作るにはどこかの時点でDAWを使わないといけないはずなので、DAWの使い方もちゃんと覚えよう、というhigh意識で進めていました。使っているDAWはこの時点でTracktion Waveformだったわけですが*1、この使い方は実際だいぶ勉強できていい経験になったと思います。

それまでほぼ創作活動は行っていなかったので、さすがにフルタイム無職とはいえ2ヶ月で完成度の高い作品を作り上げるのは無理がある、とわかっていたので、まずは過去作品を掘り出して使える部分を使いまわしながら2,3曲でっち上げたミニアルバムを出して、あとは技術書典4の時に書いたMMLコンパイラの本を展示・公開してブースの体裁を整えよう、と思いました。

「昔作っていた」を使い回すために、昔書いたMMLを自分のコンパイラのMML文法に書き直す作業から始めたのですが（MMLはツールごとに文法が全然違う、インド・ヨーロッパ語族の言語みたいなもんです）、さすがにコンパイラ自身についてバグフィックスなどすることはあまり無く*2、どちらかといえばビジュアルMIDIプレイヤーでのコンパイルから再生を自動化するワークフローや、仮想MIDIキーボードへのMMLサポート組み込みといった、周辺ツールの改造がだいぶ進みました。

MMLでの打ち込みにはRoland SC-8820を使っていたのですが、これをやりこんでも最終的なプロダクションには使えないだろう、Waveform上でVST/AUに置き換えて完成させる必要があるだろう、とは思っていました。JUCEで作られているWaveformはLinux環境でもほぼ問題なく動きますが、VSTプラグインはほぼ全滅でWaveform付属のCollectiveくらいしか無かったので、最終的にはMacを調達してKontaktなどに置き換えました。

WaveformのMIDIインポート機能には拍子とテンポまわりにバグがあって、変拍子だらけの曲を作っていた自分としては致命傷だったのですが、対応が難しそうだったので、データ形式がXMLだったのをいいことに、WaveformのデータモデルのライブラリをC#で作って自前でMIDIインポートも自作して乗り切りました。

これが割と良い経験になったのでした。それまでWaveformにどんな機能があってどんな内容のデータが楽曲データとして保存されているのか、そもそもオーディオプラグインにどんな機能があるものなのか、全然わかっていなかったんですね。モデルの情報は特に無くて、Waveformの楽曲データから全て推測で作成したのですが（まあいざとなればtracktion_engineはOSSで公開されていますし）、十分にいろいろな情報が含まれていたので、Waveformのデータモデルを扱う機能は概ね把握できたと思っています。

3-5月 オーディオプラグインまわりをいじり始める

幻想音楽祭のための創作活動が終わって一息ついたのですが、2月にAndroid QのAPIが初登場して、人手不足だったXamarin.Androidチームから新APIのバインディングを作る仕事を請負でやってくれないかみたいな話を内々に相談されていたのでそれを片付けたり（結局2日でほぼ終わってしまったので無償で）、去年公式リポジトリに投げてアップデート対応が必要だったFluidsynthのAndroidサポートにOboe（低レイテンシーオーディオ）対応なども追加したりと、いろいろ雑務(?)をこなして過ごしていました。

その一方で、DAWを使った制作プロセスの反省も含めて、もう少しオーディオプラグインをこちら側に近づけて、最初の打ち込み過程からMMLで直接いじりたいと思うようになりました。最初から作り込まずにベタ打ちで続けてもやる気出ないですし、2回作り込むの二度手間ですし（しかも最初に作り込んだのが邪魔になる）。今使われているDAWは作り込むのに向いていないんですよね。

楽曲再生エンジンだけならtracktion_engineが使えるわけですが、再生部分などはどうなっているのか相変わらずブラックボックスだったので、まずオーディオプラグインがどんなものでどこまでできるのか、今度は開発者としての視点で、VST3とJUCEを中心にいろいろ機能を調べるようになりました（特にJUCEはAUにも対応しているので）。Waveformのデータモデルから、オーディオプラグインでどんなことが実現できるのかはある程度見えていたので、良い動機づけになりました。

ただVST3はJUCEでサポートされておらず、最低限ホストを動かすためのパッチまで作ったりしましたが、進展が見られず、自分で進めたところでROLIの開発者と作業がかぶって無駄になるし、これじゃ良くても次のADC2019の頃まで出なさそうだなと踏んで、LV2をいじり始めるようになりました。LV2をいじったところで楽器が出てくるわけではないのですが、調べものとしては悪くなかったと思います。この辺の成果はひとつ10月に同人誌として結実しました。

6-8月 無職を失う

この頃は無職の意識高いツイートに腐心していたのですが（ツイッターはやってません）、

からの…

特段隠すつもりはあんまりなくてリアルではペラペラしゃべっているのですが、音楽系ソフトウェアのベンチャーで手伝いを始めて、最初3か月くらいしたら公知にするか…という感じでした。7月に始めて3か月くらい実験的に契約の予定だったのですが、ひと月でもうフルタイム社員にしちゃえという流れになりました。「ちょっと早くないかな…こっちは事前通告でいつでも辞められるけど会社側はそうもいかないし、3か月くらい試せば…?」などと言っていたのですが、実際3ヶ月で無職に戻ることにしたので（主に「自分で作りたいやつ」を作れる時間が全然とれなかったため）、結局謎のままで終わったのでした。

仕事は主にJUCEを使ったデスクトップアプリの開発で、C++開発者が求められていたのですが、5年くらいのキャリアが求められているところにC++キャリア0年での入社でしたが(!)、C++自体がわからなくてハマったのは最初の数週間くらいで、後はまあ言語で困ることは特に無かったです。JUCEは概ねモダンC++の世界なので、言語的なつまづきポイントは少なかったと思います（そういうものか…?）。まあもともと.NET開発者だった時もP/Invokeしまくってたし…

会社自体は面白いものを開発していてこの方面ではニュースバリューもあると思うので、気が向いたら年始に何か書くと思います。辞めてからもまだ手伝ったりしているし(謎)

JUCEをがっつり触れたのは良かったし本家にパッチを書いて送れる程度には分かってきたので、今後も機会があるたびに使える部分を使っていこうと思っています。

9-10月 M3に追われる

M3に初めてサークル参加しました。本当はこの時までにもう1枚CDとして新作を作るつもりだったのですが、わたしの仕事を始めるムーブが本当に良くなくて、当選してから創作するための時間が全く取れず（好きな時に創作できることはもちろん無く）、結局5月頃に少し書き出していたDAWのエンジン部分に関するテキストに手を加えてシーケンサーエンジンを支える技術として同人誌頒布と春先の新譜(!)の2本でサークルとしての体裁を整えることになりました（MML本も見本としては置きました）。

次回は技術書典8と日程まるかぶりなのと、開発しておきたいものがあってそっちに注力していたら当日までに創作する時間をとれる気がしないのとあって、申し込んでいません。ただM3で何も出来なかったというダメージが大きく、それが仕事を辞めた大きな要因のひとつです。別にただのフルタイム労働であって長時間労働させられていたということは全然無いのですが、それで時間が取られすぎるということは労働すること自体が問題だったということでしょう。もちろんいずれ労働しないと食っていけなくなるわけですが、自由なうちは自由にします。

11月 ADC2019〜原点回帰

11月半ばまではフルタイムで仕事していたので特段なにもしていなかったのですが、下旬にADC2019に行ってきました。2018の時は、無職になってまだ3ヶ月くらいの新人の頃だったので、どんなカンファレンスなのかもあまりわかっていなかったのですが、今回はそれなりに勝手を知っていたこともあって、かなりエンジョイ勢でした。今年はオーディオプラグインまわりでいろいろ遊んでいたので、SteinbergのブースでVST3の話を質問したり、NIのブースでKontaktの質問したり、AppleのブースでAUの仕組みを教えてもらったり…といった感じでした。あとGoogleのオーディオチームと1on1で話せるというので、Androidで自分が作っているものを見せてじっくり相談してきました。ROLIの人ともLinuxサポートまわりの話ができたし、収穫はいろいろありました。ADCの話は来年何かしらの発表の場を設ける予定です。

12月になってもまだ実は仕事が続いていて、週2日だけ手伝っていたのですが、それもひと区切りついたので、最近ようやく5月頃の状態に戻って自分のソフトウェアの開発に本腰を入れられる状態です。11月下旬から12月はAndroid同人誌の原稿やらアドベント カレンダー用の調査執筆が多発して、あんまり進められなかったので、これからだ…!という気持ちで年末を迎えています。

2020年は…?

2020年をどう過ごすのか、自分でもまだわかっていません。今個人で作っているソフトウェア次第ですが、どこかしらに所属して開発するかもしれないし、そうでなければ自分で何とかするかもしれません。ある程度は自由な時間を確保したいので、他によほど面白いものでも無い限り、フルタイムで無関係な仕事をすることは無いと思います。まずは有職中にほとんど進展が無かったプロジェクト（こんな感じ）を進めるところからですね…

f:id:atsushieno:20191230004611p:plain

とりあえずはかなり柔軟に時間を使える予定で、自分のプロジェクトもフルタイムで進める必要があるわけではないので、適当に面白そうな仕事の話とかあったら相談してください〜

*1:ちなみにライセンスだけはFL StudioだのCubaseだのも無駄にいろいろ持っていたりして…

*2:ただlanguage serverまわりはvscode自体の更新に伴う問題が多く、創作上のメリットが皆無だったのでほぼ放棄することになりました

libinstpatchとは

音楽技術etc. Advent Calendar 2019の…うーん…とりあえず21日目くらいにしようかな…のエントリーです。残りは上手く埋まったら埋めていきます。とりあえず今回はlibinstpatchについてです。短めに。

github.com

libinstpatchはswami projectの一環として公開されているインストゥルメンタルパッチの抽象表現ライブラリです。インストゥルメンタルパッチとは何かというと、具体的には次の3つの実装があるので、これを見ると何となくでもすぐに理解できると思います:

要するにサウンドフォントやDLSはどちらも性格が似ているので、両方ともまとめて扱えるようにしてしまおう、というものです（GigaSamplerはどの辺のコミュニティで使われているのか正直よくわかりません）。どちらも懐かしいといえば懐かしい存在ではありますが、現役で使われていなくもないものですね。

どういうところで使われるかというと、サウンドフォントベースのサンプラーや仮想MIDIデバイスのソフトウェアで使うことができます…そうです、Fluidsynthの最新版2.1でこのlibinstpatchがサポートされた結果、FluidsynthでもDLSが使えるようになりました。実のところ作者がFluidsynthのメンテナなので、推して知るべしではあります。libinstpatchをどうやって使うかも、ここから使われ方を見てみれば分かるかと思います。

SFもDLSも（たぶんGigaSamplerも）単なるインストゥルメンタルパッチのデータストレージにすぎないので、このライブラリ自体がやっていることは単純です。サウンドフォントを読み書きするライブラリのAPIと機能的には大して変わらないはずです。

データロードの部分だけはIpatchConvert_から始まる名前のフォーマット別実装が含まれています。特に難しいことはないでしょう。

Xamarin/binding-tools-for-swiftについて

Xamarin Advent Calendar 2019 24日目のエントリーです。えっオマエ生きてたの?って感じですが、軽めのネタ・調べ物で参戦です。

目次

what is it?

2019年はXamarin方面では落ち着いた1年になっていたかと思います。ネイティブ・プラットフォーム側はJetpack ComposeやSwiftUIが発表され、これから新しい時代が始まろうとしていますが、Xamarinは独自のクラシックなエコシステムに立脚するだけで続いていくのか、新しい波にきちんと乗っていけるのか、来年は動きを見せていくべき1年なのだろうなと思います。

Xamarin.Android方面ではbinding generatorからKotlin artifactを取り除いたり、AndroidSupportComponentsからAndroidXサポートを切り出したリポジトリが出現するなどの進展は見られましたが、それ以上に大きな動きは無いようです。まあ退屈と言えば退屈ですね。

一方で、今年公開された中でわたしがダントツに面白そうだと思ったのは、xamarin-macios方面で今年の秋頃に公開されたらしいbinding-tools-for-swiftです。

github.com

これまでもtom-swiftyやらSwiftNetifierやら、いろんな名前で開発されてきたSwiftとC#の相互運用のためのツールが、ついに公開されたということですね。tom-swiftyの名前はツール名としても残っているみたいですね（Tom Swiftyという単語はWikipediaにも項目があるくらい一般的であるようです）。

binding-tools-for-swiftに関する公式リポジトリ以外の情報は現状ほぼ皆無ですが、Xamarinで開発を担当してきたメンバー（らしい。わたしがいなくなってから入ってきた人みたい）が導入的なブログポストをまとめています。

plinth.org

現在製品化されているXamarin.iOSとXamarin.MacはObjective-CのAPIに対応するバインディングとバインディング生成機構を、ObjCRuntimeを経由して実現するものですが、Swiftの場合はランタイムも含めさまざまな独自要素が含まれてくるので、新しいバインディング生成ツールが必要とされてきました。

Swift自体はもう何年も前から存在する言語なので、今さらと思われるかもしれませんが、一般的な評価として、Swiftの言語仕様が安定してきたのはSwift3〜4あたりの比較的最近のことであり、言語機能はObjective-Cよりも複雑で、さらにABI安定性もSwift4でようやく目標となったような段階なので*1、バインディングツールに関しては、ようやく本腰を入れて取りかかれる状態になったとも言えます。（ABI不安定なときにがっつり実装しても新バージョンのSwiftで台無しになったら残念なことになるので…）

わたしはAppleユーザーとは言いがたいですしこれまで試したことも無かったのですが、今回はこのbinding-tools-for-swiftをどうやって使うのか、何が面白いのかといった話を書きます。

binding-tools-for-swiftという名前は長いので、以降公式ドキュメントの慣行に準じてBTFSと表記します。

今使えるの?

BTFSはまだ著しく開発中で、おそらく大概のライブラリはバインドに失敗するのではないかと思います。仕様としてバインディング作成が難しい（Xamarin.Androidのように、言語間の違いを吸収して完全自動でバインドするのが、チャック・ノリスにしか出来ない）とかいう以前に、そもそもツールチェインが整っていないとか、エラーログがまともに出力されない、といったレベルの状態なので、われわれ外部の開発者はもう少し整備されるのを待ったほうがよさそうです。

BTFSのビルド手順はトップディレクトリでmakeを実行するだけなのですが、現状では、xamarin-maciosをビルドするのと同様に、特定のバージョンのXcode、monoやXamarin.iOS、Xamarin.Macのダウンロードが必要になります（Xamarinプラットフォームはmasterでも可能そうですが、おそらくBTFS開発者向けです）。Xcodeだけでも15GBくらいは必要になるのでストレージに余裕の無い人は試せないと思います。不足コンポーネントをダウンロードするためのjenkinsスクリプトのコマンドなどを示してくれるので、それに従っていればいずれビルドできるでしょう（適当）。

いったんビルドできたら、mono tom-swifty/bin/Debug/tom-swifty.exe --helpを実行して確認してみるとよいでしょう。

実際にライブラリをバインドするときは、quickstart guideにもある以下のコマンドを実行することになります。

mono /path/to/tom-swifty.exe --swift-bin-path SWIFT_BIN_PATH --swift-lib-path SWIFT_LIB_PATH -o /path/to/output_directory -C /path/to/YOURLIBRARY.framework -C /path/to/binding-tools-for-swift/swiftglue/bin/Debug/PLATFORM/XamGlue.framework -module-name YOURLIBRARY

SWIFT_BIN_PATHとSWIFT_LIB_PATHには以下のようなパスを指定することになります。BTFS用に手を加えられた独自のswiftコンパイラが必要になります。

/path/to/binding-tools-for-swift/SwiftToolchain-v3/GITHASH/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin
/path/to/binding-tools-for-swift/SwiftToolchain-v3/GITHASH/build/Ninja-ReleaseAssert/swift-macosx-x86_64/lib

わたしはBTFSをビルドしてコマンドラインで実行できるところまでは進めましたが、バインド出来るライブラリは特に見つけられませんでした。AudioKitあたりはバインディングがあってもいいんじゃないかなーと思ったのですが、framework以下の実行ファイルへのシンボリックリンクを読めないレベルの完成度でした。

一般ユーザーのところに降ってくるまでには、MSBuildタスクなどが完成してMSBuildやVS{Mac, Win}から呼び出せたりNuGetで取ってこられるようになったりしていると思います。

とりあえず、今まだ使えないとしても、BTFSがどんな工程を経てユーザーのライブラリに対するバインディングを生成するのか、という部分は実装のステータスとは別に面白い話になると思うので、このエントリの以降の内容はFunctional Outlineのドキュメントで説明されているビルドプロセスについて、他のドキュメントにも言及しつつ説明していきます。

どんなバインディングが出来るの?

BTFSでは、以下の言語要素がサポートされています。

サポートされていないのは↓のような要素です。

ObjectModelingのドキュメントにおおよその構造が書かれていますが（ちょっと長いのでここでは引用しません）、ISwiftObjectというインターフェースを実装するオブジェクトとなるようです。Xamarin.AndroidにおけるIJavaObjectみたいなものでしょう。（XAの場合は、IJavaObject自体は単なるJavaオブジェクトのマーカーでしかなく、必ずJava.Lang.Objectクラスから派生することになりますが。）

Objective-CのときもプロトコルはストレートにC#にマッピング出来ない存在でしたが、Swiftのプロトコルへのバインディングもやや複雑な説明を要する存在になっています。Protocol Handlingのドキュメントで詳しくまとめられていますが、EveryProtocolという何やら神っぽいクラス(!?)を定義して、それを渡して廻すようです。

swiftライブラリのメタデータ構築

Swiftのライブラリをソースからビルドすると、swiftmoduleというライブラリのメタデータを格納したファイルや、SILと呼ばれる中間表現のバイナリファイルになります。BTFSではこれらを対象にバインディングの元になるSwiftTypeという型情報を構築していきます。最終的にSwiftTypeを集めたものはInventoryと呼ばれるメタデータの集合体になり、次のビルドプロセスであるところの「ラッピング」の入力になります。

もっとも、このアプローチでは十分な型情報を得ることができないので、次にXML relectionという解析プロセスを経て型情報を完成させます。

ちなみに、これらの過程ではswiftのライブラリのバイナリから識別子を取得する必要があるのですが、swiftコンパイラはswiftの識別子をバイナリコードとしてプラットフォーム準拠の形式にするためにmanglingという加工処理を行います（C++コンパイラなどでも行われています）。BTFSにはこれを解析するDemanglerというコンポーネントが含まれています。

独自swiftc拡張

BTFSのドキュメントによると、swiftcが生成するswiftmoduleやライブラリファイルには、バインディングの生成に必要となる型情報が十分には含まれていないため、Xamarinで独自にswiftcに手を加えた(?)コンパイラをビルドするようです。XML reflectionの過程で使用されるのはこのスクリプトでビルドされる…かもしれない…コンパイラです。（通常はビルド済バイナリのダウンロードが走るだけになりそう）

https://github.com/xamarin/binding-tools-for-swift/blob/master/jenkins/build-swift.sh

XmlReflectionのドキュメントを眺めてみると、既存のswiftcに手を加えるというよりはそもそも自前でswiftコンパイラを作るみたいな壮大な(?)話が書かれています。まあパーサを作ってXMLでメタデータを生成するだけなのでそれほど非現実的でもないかも…? わたしもXamarin.Androidのビルド用でJavaスタブコードのパーサー書いたりしましたし（たぶん今でも使われているはず…?）

ともあれ、このXml reflectionのアウトプットはModule Declarationと呼ばれ、これも次のビルドプロセスであるラッパー生成処理への入力となります。

ラッパーswiftライブラリの生成

InventoryとModule Definitionという2つの類似するメタデータ集合が出来上がったら、次はこれらをもとにいよいよバインディングを生成…というわけにはいきません。 ユーザーのswift APIを、いったんC#のP/Invokeで呼び出せるスタイルのAPIでラップしたswiftコードを生成します。この過程はWrappingBuilderという部品が実現しています。

BTFSの中で、メタデータ情報を解析して型ツリー情報を構築するのはDynamoと呼ばれています。このBTFSから、swiftコードを生成したり、後でC#コードを生成したりすることになります。

ラッパー生成処理は、実際には2つのユーティリティで行われています。WrappingBuilderが基本的なクラス構造を定義して、もうひとつOverrideBuilderという部品が、C#でopenクラスを派生できるように必要になる派生クラスを生成します。Xamarin.Androidにもgen-java-stubs.exeとかGenerateJavaStubsというMSBuildタスクがあるのですが、それに相当するものと考えてよさそうです。

C#バインディング生成

ラッパーを準備してAPIメタデータを整地したところで、いよいよC#バインディングの生成に入ることが出来ます。まず、ラッパーのライブラリから、再びSwiftTypeのInventoryとreflectorによるModule Declarationの2つのメタデータ集合を生成します（処理内容は最初と同じです。対象がラッパーになっただけです）。ここでまたDemanglerが必要になります。

C#のコードを生成するのは、ラッパーを生成する時に登場したDynamoの役割です。これでようやく完成です!

BTFSの制限

BTFSがサポートしているのはSwift 5までの文法で、Swift 5.1はサポートしていません。SwiftUIが多大に依存しているOpaque Result Typesなどはまだ使えないということですね。

まとめ

今回はXamarin/binding-tools-for-swiftで行われているバインディングのビルド過程を追ってみました。途中で独自のswiftコンパイラハックを加えていたりと、非常にいかがわしい萌え技術が使われているのではないでしょうか。

*1:たとえばこのswiftのname manglingに関するドキュメントを見ると4.0と4.2で違っていることがわかります

LV2の概要

音楽技術Advent Calendar 2019の11日目のエントリーです。（まあだいぶ穴が開いているのですが、マイペースに埋めていきます。）

What is LV2?

LV2は主にLinux環境で利用できる、クロスプラットフォームのオーディオプラグインの仕様です。

オーディオプラグインとは、主にDAW (digital audio workstation)環境でDTM（desktop music）の作業を行う場面で、楽器やエフェクターとして利用できるオーディオデータの生成・加工ソフトウェアとして使われるものです。オーディオプラグインは、さまざまな「ホスト」となるDAWなどのソフトウェア*1の上で、さまざまなものを繋ぎ合わせて使用することが多いです。よくある使い方としては、サンプラーのプラグインでサンプリング音源データをノート（キー）に合わせて波形を調整して、それをロータリーエンジンやリバーブのプラグインで加工して、ミキサープラグインでゲイン調整してオーディオデータとして出力する、といった流れになります。

オーディオプラグインは、複数のホスト、複数のプラグインベンダーの間で互換性が求められるもので、デファクトスタンダートとなる仕様がいくつか存在しています。有名どころではSteinberg VSTやApple AU (AudioUnit)が挙げられます。オーディオ処理がもともとプラットフォーム固有の実装になりがちだったこともあってか、ここには業界標準となるような仕様が存在しないのが現状です。また、DAW開発社でも、自分たちのDAWでしか使用できない独自のプラグイン形式を規定して公開しているものがあります。Avid Audio eXtensions (AAX)などがその典型です。

本稿で取り上げるLV2とはLADSPA v2の略であり、LADSPAとはLinux Audio Developer's Simple Plugin APIの略です。Linux環境ではVSTやAUのようなデファクトスタンダートのように使われている仕様のオーディオプラグイン機構が動作しなかったため、独自にオーディオプラグイン機構を開発して発展させる必要がありました。それでもっともポピュラーだったと言える仕様がLADSPA (v1)です。

オーディオI/Oそのものはプラットフォーム固有の実装とならざるを得ない部分があるのですが、一旦そこを抽象化すると、実際のオーディオ処理の部分は、実のところプラットフォーム固有の実装になることはあまり無かったため、LADSPA v2は最早L (Linux)固有のものではなく、MacでもWindowsでも動作可能なものになっています。LV2と同様、VSTもクロスプラットフォームでMacでもLinuxでも使用できる存在となっていきました。

LV2は2019年現在、ardourやqtractor、museなど主要なLinux用DAWでサポートされていますが、それ以外の製品、特にWindowsやMacでは未採用の製品が多いです。

LV2プラグインの概要

LV2は（VSTなどと同様）現在進行形で拡張されている仕様です。後方互換性を維持するために、LV2仕様はモジュラーアーキテクチャになっており、コア部分と拡張部分を切り分けてあります。そのため、使用可能な最低バージョンがモジュールによって異なります。これはVST3のMA（モジュールアーキテクチャ）と似ている側面があります。

LV2仕様のモジュールリスト どのプラグインフォーマットでも、プラグインにはメタ情報が含まれているものですが、LV2の場合はこれをRDFによって提供することになっています。実際には、XMLとしてのRDFではなく、RDFを「シンプルな」テキスト形式で記述するTurtle (Terse RDF Triple Language)と呼ばれる独自記法に変換した.ttlというファイルに記述することになります。

RDFの記述内容は、プラグインのAPIについても当てはまり、VST3やAUの場合は、単にCやObjective-CのAPIを実装するだけで済むのですが、LV2の場合は、実際にコードとして実行するために必要になる最小限の部分のみをコードとして実装し、残りの部分はこのメタデータとして作成する作業が必要になってきます。すなわち、(1)プラグイン利用者の視点でいえば、そのプラグインにどんなポートやパラメータがあるか、どんな入力を受け付けるかは、RDFの情報だけでも把握できますし、(2)プラグイン作成者の視点でいえば、そのプラグインにどんなポートやパラメータがあるか、どんな入力を受け付けるかは、コードだけで完結せず、メタデータに記載しなければならないことになります。

プラグインでは独自の型を規定して公開することも可能です。MIDIメッセージやプリミティブ型（Atom型）などLV2標準に含まれる型の多くが、このルールに基づいて規定されています。もっとも、一般的なプラグインにおいて、複雑な独自型を公開型として定義する必要は滅多に無いでしょう。

モダンなプラグインフォーマットでは、プラグインが単一のライブラリファイルとして提供されていることはなく、関連ファイルとまとめて1つのフォルダなどにまとめて配置するものが多いです。LV2も同様で、「LV2パス」のいずれかに.lv2という名前で終わる「プラグインバンドル」のディレクトリ*2に関連ファイルをまとめます。この中に入るのは典型的にはこのようなファイル群です:

LV2フォルダ構成 ファイル名は任意に決定できますし、1つのプラグインバンドルに複数のプラグインを含めることもできます（manifest.ttlに記載する必要があります）。マニフェストの内容は、このようなテキストにまで圧縮できます（Turtle syntaxとはこのようなものです）:

<http://example.com/arbitrary-paths/foobar>
    a lv2:Plugin ;
    lv2:binary <foobar.so>  ;
    rdfs:seeAlso <foobar.ttl> .

.soはLinux環境における共有ライブラリなので、実際のプラットフォームに合わせて変わります。

LV2の拡張性

LV2の標準仕様は、バージョン1.0時点で既知であった最小限の機能のみを提供し、それ以降のバージョンで追加された機能については、ホストから渡されない限り、プラグインが利用することはできない仕組みになっています。

拡張機能の中には「URIと一位識別子URID（uint32）のマッピング」「プラグインのステートの保存と復元」「UIの呼び出し」など、かなり本質的なものが含まれているため、LV2をプログラムで扱うのであれば、LV2拡張に対する基本的な理解が不可欠です。

LV2拡張のインスタンスは、LV2_Featureという構造体で表されます。

struct LV2_Feature
{
    const char *URI;
    void *data;
}

LV2拡張はURIで種別が識別され、それぞれの拡張に応じて必要になるデータがdataに渡されます。多くの拡張機能はコードによる実装を必要とし、それらは（直接ないし間接的に）関数ポインタとしてホストからクライアントに渡されることになるので、dataが空であることは通常はありません。たとえばURIがLV2_URID_MAP_URI（http://lv2plug.in/ns/ext/urid#map）のとき、dataに渡されるべきものはLV2_URID_Map構造体です。

// typedef void* LV2_URID_Map_Handle
// typedef uint32_t LV2_URID
struct LV2_URID_Map
{
    LV2_URID_Map_Handle handle;
    LV2_URID(* map)(LV2_URID_Map_Handle handle, const char *uri);
}

LV2プラグインは、lv2.hをインクルードしてLV2_descriptor()およびLV2_lib_descriptor()という関数を定義することになります。いずれもLV2ホストがプラグインをdlopen()でロードした後、dlsym()で動的に呼び出すことになります。LV2_lib_descriptor()ではLV2_Feature*型のfeatures が定義されており、ここにはLV2ホストから「ホストがサポートするLV2拡張」のデータを含むリストが渡されます。

先のLV2_URID_Mapの例でいえば、mapがこの拡張機能の実体であり、この関数ポインタをプラグイン側はLV2_URID_mapの実装として呼び出せる、という仕組みです。

LV2プラグインの後方互換性

LV2プラグイン機構は、LV2 Coreと数多くのプラグインによって成り立っていますが、それぞれのプラグインにはバージョンがあり、これらは必ずしも後方互換性があるとは限らないようです。筆者が試した範囲では、Atom型として定義されている型がXML Schema Datatypesに由来するxsd:*型であるとしてRDF上で定義されているものがいくつかあり、これらのプラグインをlv2_validateツールで検証するとwarningが報告されました。LV2の仕様自体が後方互換性を意識していても、実際に後方互換性が達成できるかどうかは、拡張となるプラグインのバージョン間互換性・設計次第であるようです。

もしかしたらこれはLV2_Atomをサポートした時点で生じた非互換問題で、2012年に出たこの記事でQTractorの開発者に言及されている問題かもしれませんが、2012年の問題が2019年になっても問題になっているとしたら、7年も前の非互換変更が今でも尾を引いているということであり、後方互換性の問題は無視できないかもしれません。

LV2ホスティング

オーディオプラグインを使うためには、オーディオプラグインにMIDIなどの制御命令や音声データを渡して処理させるホストが必要です。一般的にはDAWと呼ばれるソフトウェアがこれを担いますが、プログラムとしてはLV2プラグインをロードして処理を実行できるものであれば何でもかまいません。たとえば、プラグインのテストには、テストのみを目的とするローダーが使われるでしょう。

LV2をサポートするDAWとしては、Ardour、Audacity、Carla、QTractorなどが有力です。

LV2ホスティングを実現するためのリファレンス的な実装として、lilvというライブラリがあります。ローカルにインストールされているLV2プラグインやプラグインクラスをリストアップして、プラグインのインスタンスを生成して、ポートをデータバッファに接続して、オーディオ処理を走らせることができます。

lilv

lilvはLV2ホスティングのためにあるCライブラリです。RDFの詳細の多くを隠蔽しつつ、プラグインクラスを検索し、プラグインのインスタンスを生成して、音声データ処理を行えます。

RDFの処理は、同じ作者が開発しているserd（RDFの解析）、sord（Turtle syntaxの解析）、sratom（LV2 atom型とRDFの相互変換）、そしてlv2の4つのソースコード・パッケージにのみ依存しています。実際にはlv2などがさらにlibsoundioやcairoなどをオプションとしてサンプルプラグインのビルド時に参照することになるので、依存関係はもう少し膨れ上がります。

LV2のRDFを書けるようになるためには、RDFについてそれなりに勉強しなければならないことになりますが、率直に言えば、オーディオプラグインを開発するためにRDFを勉強するというのは、全く本質的な作業ではない、と言わざるを得ないでしょう。これは、lilvのAPIを調べていくことである程度緩和されます。RDFの面倒な部分はとりあえず置いておいて、lilvのAPIでworld, plugin class, plugin, port, instanceといった概念を理解したほうが早いです。

*1:有名どころではSteinberg社のCubaseやApple社のLogic Proなど

*2:単なる一般則なのか仕様で厳格に決められているのかは不明ですが、筆者はこの例外を見たことがありません