diff --git a/chapter1.md b/chapter1.md
index 2ba21de..ef14168 100644
--- a/chapter1.md
+++ b/chapter1.md
@@ -72,7 +72,7 @@ SFPCのプログラムはこうした歴史的背景をもとに、ブラック
 
 実際、この提案は2019年情報処理推進機構未踏IT人材発掘・育成事業という、革新的なソフトウェア制作に対する支援事業に採択され、その当初のアイデアはプログラミング言語設計とそのソースコードをグラフィカルに編集できるソフトウェアという2つのプロジェクトを並列して行うものになっていた。[^mitou]
 
-[^mitou]: 未踏IT人材発掘・育成事業：2019年度採択プロジェクト概要（松浦PJ）(https://warp.ndl.go.jp/info:ndljp/pid/12446699/www.ipa.go.jp/jinzai/mitou/2019/gaiyou_tk-1.html)を参照。また同時期に情報処理学会音声情報処理研究会にて同様の案についてのポスター発表を行っている[@Matsuura2019MUS]。
+[^mitou]: 未踏IT人材発掘・育成事業：2019年度採択プロジェクト概要（松浦PJ）(https://www.ipa.go.jp/jinzai/mitou/2019/gaiyou_tk-1.html)を参照。また同時期に情報処理学会音声情報処理研究会にて同様の案についてのポスター発表を行っている[@Matsuura2019MUS]。
 
 しかし結果として、2019年6月から2020年2月までの同事業でのディスカッションを中心に実装を進める中で、筆者の興味関心は徐々にその根幹であるプログラミング言語の設計そのものに移ることになった。ひとつの理由は、音声信号は、（考えてみれば当たり前だが）グラフィックにおけるコードと直接操作の相互利用ツールと異なり、**直接操作**など不可能である、ということに気づいたことにある。我々が音楽制作ソフトウェアで波形をマウスで切り貼りしているのは言うなれば音声データのありうる表象のかたちのうちのひとつでしかなくて、空気の振動それ自体ではない。音楽プログラミング言語で表現しようとしているデータ形式そのものも音そのものではない。 -->
 

diff --git a/chapter2.md b/chapter2.md
index e8b60fc..e55b808 100644
--- a/chapter2.md
+++ b/chapter2.md
@@ -28,7 +28,7 @@ draft: true
 
 筆者のプロジェクトは、採択時のタイトルが「プログラマブルな音楽制作ソフトウェアの開発」となっている通り、その当初のアイデアは音楽のためのプログラミング言語設計とそのソースコードをグラフィカルに編集できるソフトウェアという2つのプロジェクトを並列して行うものになっていた。しかし同事業での過去の採択者や同じ年に採択された人とディスカッションを重ね、プログラミング言語や計算機アーキテクチャ自体の開発に興味を持つ人からのコメントをもらう中で、筆者の興味関心は徐々にその根幹であるプログラミング言語の設計そのものへと少しずつシフトしていった[^mitou]。
 
-[^mitou]: 未踏IT人材発掘・育成事業：2019年度採択プロジェクト概要（松浦PJ）を参照。https://warp.ndl.go.jp/info:ndljp/pid/12446699/www.ipa.go.jp/jinzai/mitou/2019/gaiyou_tk-1.html 2022年1月31日最終閲覧。また同時期に情報処理学会の音声情報処理研究会にて同様の案についてのポスター発表を行った[@Matsuura2019MUS]。
+[^mitou]: 未踏IT人材発掘・育成事業：2019年度採択プロジェクト概要（松浦PJ）を参照。https://www.ipa.go.jp/jinzai/mitou/2019/gaiyou_tk-1.html 2022年1月31日最終閲覧。また同時期に情報処理学会の音声情報処理研究会にて同様の案についてのポスター発表を行った[@Matsuura2019MUS]。
 
 もちろん、未踏事業のコミュニティにおいても過去に音楽のためのプログラミング言語の開発というテーマの採択はほとんどなく、既に存在しているMaxやPure Dataといった既存のツールとの違いの説明や、この言語を作ることが最終的にどういった面白みがあるのかを伝えることは先の学会への論文投稿と同じように課題ではあった。それでも、同事業の成果報告会では、音楽制作ソフトウェアとして実用的に活用するには現実的課題を多く残しつつも、概ね好意的なフィードバックを受けることができた。
 
@@ -167,7 +167,7 @@ RtDが立ち上がる中で重要視されてきたのは研究を行う中で
 
 しかしこうしたデザイン思考は、1960年代のデザインサイエンスにおける客観主義を否定はしたものの、今日デザイナーのイメージをアイデアを書いた付箋をホワイトボードに貼ってディスカッションしている人たちに固定してしまったように、あらゆる問題の種類に対して作る（もしくはアイデアを出す）-反省という反復の枠組みだけを与える普遍主義に依然留まってしまっている。
 
-ブキャナンによる意地悪な問題のデザイン思考プロセスにおける紹介はサイモンのようなデザインの科学化に対するアンチテーゼでもあると同時に、デザイン思考がそのプロセスによって問題を確定させる（Determinate）方向に働いているが、そもそもリッテルらが提起した意地悪な問題とは、根本的に確定できない（Indeterminate）ことだったのを強調している。結局人文学的アプローチであったとしても、大枠がプロトタイピング、実験、思考の繰り返しという一般化されたフィードバックではサイモンと同じ穴の狢であり意地悪な問題には対応できないということだ。ブキャナンはこれを、確定（Determinate）にはできない主題であっても特殊（Particular）化は可能であり、デザイナーは、クライアントがまだ準主題（Quasi-subject matter）である状態のものを特殊化する事によってエンジニアなどが解決可能な問題にスライドできるという提言をしたのだ。
+ブキャナンによる意地悪な問題のデザイン思考プロセスにおける紹介はサイモンのようなデザインの科学化に対するアンチテーゼでもあると同時に、デザイン思考がそのプロセスによって問題を確定させる（Determinate）方向に働いているが、そもそもリッテルらが提起した意地悪な問題とは、根本的に確定できない（Indeterminate）ことだったのを強調している。結局人文学的アプローチであったとしても、大枠がプロトタイピング、実験、思考の繰り返しという一般化されたフィードバックでは西門と同じ穴の狢であり意地悪な問題には対応できないということだ。ブキャナンはこれを、確定（Determinate）にはできない主題であっても特殊（Particular）化は可能であり、デザイナーは、クライアントがまだ準主題（Quasi-subject matter）である状態のものを特殊化する事によってエンジニアなどが解決可能な問題にスライドできるという提言をしたのだ。
 
 こうした流れのもと1990年代以降に、**デザイン実践を通じた研究（Research through Design：RtD）**と呼ばれる研究領域が主にデザイン・サイエンス的アプローチの行きづまり（と、並行して起きていたデザイン思考の一般的方法論化）を突破するべく、デザインを「不明瞭かつ個別固有の社会・技術的問題を対象とする臨床的、生成的研究」[@Mizuno2017]と位置付けるような運動として現れてきた[^designresearch]。RtDには、問題を研究する過程で発見すること、必ずしも役に立つものだけを作るわけではないこと、問題解決だけを目的としないこと、社会そのものの変化を視野に入れること、ユーザーではなく参加者/共同製作者への転換、といった様々な特徴が挙げられる。こうした特徴は一見して多岐に渡っており統一性がないようにも思えるが、リッテルの意地悪な問題への動機をもとに考えれば、すべて*どこへ向かうべきか*という社会の中におけるデザイナーの主体性と政治性への自覚という1本の軸から派生したものとして捉えることができる。
 

diff --git a/chapter3.md b/chapter3.md
index e7d7eea..e4122ff 100644
--- a/chapter3.md
+++ b/chapter3.md
@@ -216,11 +216,11 @@ Apple IIからMacintoshで起きた変化とは、一般にコマンドユーザ
 
 そして、この性質を生み出す一端は、今日における「デザイナー」と「ユーザー」の分離にある。クレーリーは『24/7』でこのユーザーの主体性こそ見せかけのデザインされた差異でしかないことを強調する。
 
-> 技術的インターフェースの**遍在**〔The ubiquity〕によって、必然的にユーザーは、ますます流暢になり熟達するために努力するように導かれる。それぞれの特殊なアプリケーションやツールに習熟することは、結果的に、いかなるやりとりや操作の時間をも切れ目なしに削減していくという本来的な機能要求と見事に調和していく。装置は見かけ上、ひっかかりのない扱いや、手際のよさ、自己満足的なノウハウを誘い、テクノロジー資源を効率的に利用して見返りを得ることのできる優れた能力として、他人に印象づけることもできる。個人の巧みさの感覚は、その人がシステムの勝ち組の側にいて、いくらか抜きん出ているというかりそめの確信をもたらす。しかし、結局のところ、全てのユーザーは、時間や実践を等しく奪い取られた交換可能な対象へと平均化されていく。[@Crary2015,p74〜75、強調は筆者による]
+> 技術的インターフェースの**偏在**〔The ubiquity〕によって、必然的にユーザーは、ますます流暢になり熟達するために努力するように導かれる。それぞれの特殊なアプリケーションやツールに習熟することは、結果的に、いかなるやりとりや操作の時間をも切れ目なしに削減していくという本来的な機能要求と見事に調和していく。装置は見かけ上、ひっかかりのない扱いや、手際のよさ、自己満足的なノウハウを誘い、テクノロジー資源を効率的に利用して見返りを得ることのできる優れた能力として、他人に印象づけることもできる。個人の巧みさの感覚は、その人がシステムの勝ち組の側にいて、いくらか抜きん出ているというかりそめの確信をもたらす。しかし、結局のところ、全てのユーザーは、時間や実践を等しく奪い取られた交換可能な対象へと平均化されていく。[@Crary2015,p74〜75、強調は筆者による]
 
 これがすなわち、テベルジュの著作のタイトルである『Any Sound You Can Imagine』[@Theberge1997]が示唆するところである。つまり、「あなたが想像できる音ならなんでも作れますよ」というシンセサイザーやコンピューター音楽にお決まりの礼賛の言葉は同時に、「**あなたが想像できないのならその音は一切作れない**」という意味でもある。そして、「あなたが想像できる音」は、反復の系においてはあなたがこれまで聞いてきた音の集合でしかない。
 
-クレーリーの『24/7』で繰り返し用いられる遍在/The ubiquityというワードの登場によって、ここでようやく、前半で議論してきた、失敗した理想としてのメタメディアとユビキタスコンピューティングと音楽の関わりについて考えることができる。それは、Youが複数形になる時–「あなた**たち**が想像できないのならその音は一切作れない」となる時だ。
+クレーリーの『24/7』で繰り返し用いられる偏在/The ubiquityというワードの登場によって、ここでようやく、前半で議論してきた、失敗した理想としてのメタメディアとユビキタスコンピューティングと音楽の関わりについて考えることができる。それは、Youが複数形になる時–「あなた**たち**が想像できないのならその音は一切作れない」となる時だ。
 
 ## 認識論的道具としてのコンピューター楽器
 

diff --git a/chapter5.md b/chapter5.md
index f2e2055..d9479f7 100644
--- a/chapter5.md
+++ b/chapter5.md
@@ -254,7 +254,7 @@ d1 $ sound "bd*4" # gain (every 3 (rev) $ "1 0.8 0.5 0.7")
 
 音楽プログラミングのプロセスをその表現の様式によらずモデル化したものとして、アンダーソンとキビラによるコンピューターを用いる音楽パフォーマンスのためのシステムを、彼らが開発したFORMULA（FORTH言語上に構築されたPLfM）を中心に分析した研究がある[@Anderson1990]。アンダーソンらは論文内で[@fig:andersonmodel]のように、コンピューターを用いた音楽生成を人間とコンピューターが作り出すフィードバックループ、いわゆるHuman In the Loopモデルとして捉えた。
 
-![Human In the Loopとしての音楽プログラミング言語の利用モデルを、言語を特徴付ける各要素、実際に現れる特徴で表した図。](../img/humanintheloop_model.png){width=100% #fig:humanintheloop}
+![Human In the Loopとしての音楽プログラミング言語の利用モデルを、言語を特徴付ける各要素、実際に現れる特徴で表した図。](../img/humanintheloop_model.pdf){width=100% #fig:humanintheloop}
 
 このアンダーソンらのモデルにおいて、Computer Systemに相当する部分がコンパイラ、Synthesizerに相当する部分がランタイムシステムだと捉えれば、ライブコーディングのような近年の対話的プログラミングの実行モデルとしてもよく当てはまるように思える。
 

diff --git a/chapter6.md b/chapter6.md
index 4fe842a..ebad1dc 100644
--- a/chapter6.md
+++ b/chapter6.md
@@ -440,7 +440,7 @@ fn dsp(state){
 
 Extemporeは、単一の環境ですべての記述ができるという点で、このアプローチと似ているものの、ユーザはxtlangとSchemeという2つの異なる言語を使用する必要がある。xtlangでは、UGenをクロージャとして定義する際に、手動のメモリ管理やポインタを含む複雑な型シグネチャを理解する必要がある。Extemporeは音楽に限らないフルスタックのライブコーディングを行うことを想定した環境であるため、手動メモリ管理は必ずしもマイナスポイントではないが、SuperColliderの開発者であるマッカートニーが言うように、音楽のために作られた言語であれば、ユーザーが音楽の作業に集中できるように、メモリやスレッドなどのハードウェア管理を不要、もしくはオプショナルにすることは一般的に重要だと言える[@McCartney2002,p61]。
 
-Kronos（とMeta-Sequencer）も同様に自己拡張性を重視した言語である。KronosはSystem $\mathit{F\omega}$ と呼ばれる、ラムダ計算の拡張体系の1つをベースにしたより厳密な関数型言語であり、プロセッサの入出力をリスト構造としてパラメータ化できることで、よりUGenの一般的な表現が可能である。しかし、その内部表現はFaustのようにグラフ構造をベースにしている[@Norilo2016phd,p23]。mimiumの内部表現は、ラムダ計算ベースの木構造やSSA形式の命令型IRであり、より汎用プログラミング言語の中間表現に近いという違いがある。
+Kronos（とMeta-Sequencer）も同様に自己拡張性を重視した言語である。KronosはSystem `F\omega`をと呼ばれる、ラムダ計算の拡張体系の1つをベースにしたより厳密な関数型言語であり、プロセッサの入出力をリスト構造としてパラメータ化できることで、よりUGenの一般的な表現が可能である。しかし、その内部表現はFaustのようにグラフ構造をベースにしている[@Norilo2016phd,p23]。mimiumの内部表現は、ラムダ計算ベースの木構造やSSA形式の命令型IRであり、より汎用プログラミング言語の中間表現に近いという違いがある。
 
 
 # 現状の実装の問題点