writiing

src/main.tex

@@ -27,7 +27,7 @@
 \maketitle
 
 % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{はじめに-音楽プログラミング言語の形式化}
+\section{はじめに-音楽プログラミング言語の分業化}
 
 音楽のためのプログラミング言語・環境は、Cycling'74 Max\cite{max}やPure Data\cite{pd}、CSound、SuperCollider、ChucKといった言語を代表として様々なものが開発されてきている。こうした言語の多くは歴史を遡ると1950年代にベル研究所でマックス・マシューズらが開発したMUSICシリーズに遡ることができる。MUSICシリーズは音圧波形を時間・音圧の2次元で離散化・量子化した数列として表すことで、計算によって任意の波形を生成することが可能になるパルス符号変調という理論に基づいて計算機で音を出した最初の事例である。
 
@@ -35,19 +35,31 @@ CやC++といった汎用プログラミング言語で音声合成を行う場
 
 そうしたライブラリや言語では、Unit Generator(UGen)と呼ばれる、オシレーターやフィルターといった基礎的な処理単位を、モジュラーシンセサイザーの様に組み合わせていくことで処理を行う。\footnote{モジュラーシンセサイザーとUnit Generatorは実際には同時期に現れたコンセプトではあるが、音楽プログラミング言語は積極的にビジュアル的なメタファーを物理的なシンセサイザーから取り入れてきている。}
 
-多くの言語ではUGen自体の実装にはC++などの汎用言語を用いて、動的ライブラリの形で提供される。
+2000年代以降では、Sonic PiやTidalCyclesに代表される、メロディやリズムパターンをソースコードから生成し、リアルタイムでソースコードを書き換えることで演奏を行うライブコーディング環境が開発されてきたが、これらの言語は信号処理をSuperColliderなどのUGenベースの言語に任せ、それらの言語ランタイムへ命令を送信をするクライアントとして実装されている。そして、多くの言語でUGen自体の実装にはC++などの低級言語が用いられ、動的ロードライブラリの形で提供される。
 
-こうしたUGenパラダイムにはいくつかの問題点が指摘できる。
+このように音楽のためのプログラミング言語は、表現可能な範囲をユーザーや実装者の関心のある領域ごとに細分化する形で発展してきている。その一方で、NishinoとNakatsuによるサーベイで指摘されているように、近年のコンピューター音楽実践ではマイクロサウンド\footnote{音声波形を細かく切り刻んで再構成するような音声合成手法\cite{roadsmicrosound}。シンセサイザーのカテゴリとして、グラニュラー合成と呼ばれる物の基礎的な考え方でもある。}や、サンプル単位精度でのイベント処理のような高度な処理が求められる中で、Unit Generatorというコンセプトを基礎に置くこと自体の妥当性が問われてもいる\cite{Nishino2016}。
 
-まず1つはコードの再利用性である。多くの言語では、実際にはほとんど同じような内容であるにも関わらず、それぞれが基本的なUGenを実装し直しており、言語間での相互運用性も少ない。
+ユーザーおよび開発者の利便性に限った点に絞ったとしても、UGenパラダイムにはいくつかの問題点が指摘できる。まず1つはコードの再利用性である。多くの言語では、実際にはほとんど同じような内容であるにも関わらず、それぞれが基本的なUGenを実装し直しており、言語間での相互運用性に欠けている。2つ目は、UGenがプリミティブなデータ型として提供されており、非線系オシレーターの用に既存のUGenの組み合わせでは表現できない新たなUGenの定義がその言語上では難しいことである。3つ目に、UGen自体のパラメトリックな接続の抽象化（例えば、オシレーターを任意の本数複製したり、フィルターをカスケードしたり）することが難しい点である。これは言い換えると、多くの言語では、UGenを引数として受け取って新たなUGenを定義するような関数を定義できないということである。
 
-2つ目は、UGen自体を基礎的なデータ型
+\subsection{関数型プログラミング言語に影響を受けた信号処理言語}
 
+Unit Generatorコンセプトに基づく言語の問題点は、既存の音楽プログラミング言語の多くが実装に依存しており、言語としての意味論が形式化されているものがほとんど無い、とも言い換えられる。
 
+この観点で、実用的に使われている音楽プログラミング言語の中では、例外的に強く形式化された言語としてFaustが挙げられる\cite{Faust2002}。
 
+Faustは、入出力を持つブロックを、並列、直列、分岐、合流、再帰の5つの合成子を用いて組み合わせる。基本的な算術演算、条件分岐、遅延をプリミティブなブロックとして提供することで、ほぼあらゆる種類の信号処理を記述することができる。また後の拡張では、項書き換え系に基づくマクロを導入することで、ユーザーによる任意の数の入出力を持つブロックの抽象化を可能にした[2]。
 
+この形式化を通じた強力な抽象化能力により、FaustはC、C++、Rust、LLVM IRなどの様々なバックエンドにコンパイルでき、あらかじめ用意されたアーキテクチャファイルと呼ばれるボイラープレートコードと組み合わせることで、MaxやSuperColliderのUGenとしてエクスポートすることも可能になっている。
 
-% 音楽プログラミング言語用のバックグラウンドを追加する
+その一方、Faustの理論的基盤であるブロックダイアグラム代数（Block Diagram Algebra-BDA）は、一般的なプログラミング言語との理論的・実用的な互換性に欠ける。Faustでは外部のC関数を呼び出すことは可能だが、ポインタや参照を扱えないのでホストの内部状態をFaust側から制御することは難しい。
+
+また、Faustのマクロは、パターンマッチに基づいてBDAを生成する独立した項書き換え系である。そのため、パターンマッチングのための数値引数は暗黙のうちに整数であることが要求され、BDA上では整数と実数の方の区分けは存在しないにもかかわらず、コンパイル時エラーを起こすことある。この暗黙の型付けルールは、初学者のユーザーにとっては直感的なものとは言い難い。
+
+ラムダ計算のような、より汎用的な計算モデルに基づく信号処理の計算モデルを提案することは、さまざまな汎用言語間の相互運用を可能にするほか、既存の最適化手法の流用や、コンパイラやランタイムの実装を容易にする可能性をもつ\footnote{これまで、BDAはモナドの高位抽象化であるアローとしてラムダ計算ベースの汎用関数型言語に変換可能なことが証明されてはいる[3]。ただ、汎用関数型言語の内部DSLとして信号処理を範疇に入れた音楽プログラミング言語を実装するには、多くの言語では動的なメモリ割り当て・解放のタイミングがユーザー側で制御できないなど、ハードリアルタイム処理に適さないという問題が残る。}。
+
+Kronos[4]とW-calculus[5]は、それぞれFaustに影響を受けたラムダ計算ベースの抽象化の例である。Kronosは理論的基盤としてSystem-$F\omega$ というラムダ計算のバリエーションに基づいており、型を入力として受け取り、新しい型を返す関数を定義することができる。Kronosでは、型レベルの計算が信号処理グラフの生成に対応し、値の計算が実際の処理に対応する。Kronosにおいては遅延だけが唯一の特殊なプリミティブ演算であり、フィードバックを伴うルーティングは型計算における再帰的関数適用として表現される。ただし、意味論の厳密な形式化はなされていない。
+
+W-calculusは、変数の過去の値にアクセスする機能（すなわち遅延）とともに、プリミティブ操作としてフィードバックを含む。W-calculusでは、記述する対象をフィルタやリバーブのような線形時不変システムに限定した上で、Coqを用いた厳密な意味論の定義がなされている。W-calculusで書かれたシステムではシステムの線形性が保証されるほか、異なる表記のシステムの同一性の証明などが可能になる。他方でW-calculusでは高階関数の使用は許されていない。
 
 \section{音楽のためのプログラミング言語mimiumの仕様}