[obsidian] vault backup: 2025-11-03 11:42:18[

content/NY日記-20251029.md

@@ -7,4 +7,6 @@ Julieに会いにNew Jerseyへ。しかし連絡がなさすぎるので不安
 
 ・・・結局、タイミングが合わなかったのでとりあえずBell Labs Technology Showcaseの展示だけ見て帰ることに。行きのローカル電車のタイミングを見誤ると1時間単位で次が来ないことがわかったので、こっちに来て初めてLyft呼ぶことに。
 
-展示はまあ想像通りの規模でそんなに多くはなかったけど、World First Transistorを生で
+展示はまあ想像通りの規模でそんなに多くはなかったけど、World First Transistorを生で拝めたので満足。思ってたよりは小さかった。
+
+

content/mimiumでのライブコーディングエンジン.md

@@ -100,6 +100,6 @@ fn update_state_tree(oldtree:StateTree,newtree)->StateTree{
 
 ```
 
-できそうなので論文にしてみるか→ [[関数型信号処理プログラミング言語のソース変更時に内部状態を差分保持するシステム]]
+できそうなので論文にしてみるか→ [[多段階計算と増分関数型リアクティブプログラミングのによる信号処理のライブコーディング]]
 
 

content/多段階計算と増分関数型リアクティブプログラミングのによる信号処理のライブコーディング.md

@@ -1,48 +1,56 @@
 ---
 date: 2025-09-25 11:42
 ---
-#paper 
+#paper #research
 
+(NIME2026のドラフトです)
 ## 概要
 
-本稿は、筆者の開発している関数型音楽プログラミング言語[[mimium]]における、ソースコード更新の際に実行中の信号処理の内部状態を可能な限り保持する仕組みのデザインの提案である。
+本稿では、筆者の開発している関数型音楽プログラミング言語[[mimium]]で用いている、デジタル信号処理を対象のドメインに含めたライブコーディングシステムの設計を述べる。
 
-多くの音声信号処理をターゲットにしたプログラミング言語では、ソースコードを更新して評価し直すたびにディレイやフィルタなどの信号処理プロセッサの内部状態がリセットされる。これはライブコーディングのように、実行中にソースコードを書き換えて演奏をするようなユースケースを阻む壁の一つである。
+音声信号処理をターゲットにしたプログラミング言語では、ソースコードを更新して評価し直すたびにディレイやフィルタなどの信号処理プロセッサの内部状態がリセットされることが一般的である。これはライブコーディングのように、実行中にソースコードを書き換えて演奏をするようなユースケースを阻む壁の一つである。
 
 そこで筆者の開発する音楽プログラミング言語mimiumの機能を拡張し、信号処理で使われる内部状態の構造を変更前後で比較し、可能な限り変更前の状態を持ち越して新しいソースコードで評価できる仕組みを設計した。
 
-このシステムの特徴は、ソースコード自体の変更増分は解析せず、全てのソースコードを毎回再コンパイルし直し、コールツリーに基づく内部状態の構造の比較のみを行う点である。この方法を採用することで、既存のコンパイラやVMの定義の変更を最小限にしたままライブ評価を実現できる。
+このシステムの特徴は、ソースコード自体の変更増分を解析せずに、全てのソースコードを毎回再コンパイルし直し、コールツリーに基づく内部状態の構造の比較のみを行う点である。この方法を採用することで、既存のコンパイラやVMの定義の変更を最小限にしたままライブ評価を実現できる。
 
-## 背景
+## 背景とモチベーション
-
-音楽のためのプログラミングにおけるライブコーディングとは、音楽を生成するプログラムのソースコードをリアルタイムで書き換えながら演奏するパフォーマンスのスタイルである[@]。
 
+音楽のためのプログラミングにおけるライブコーディングとは、音楽を生成するプログラムのソースコードをリアルタイムで書き換えながら演奏するパフォーマンスのスタイルである[@magnussonAlgorithmsScoresCoding2011]。
 
 既存の信号処理をターゲットにした音楽プログラミング言語における問題の一つとして、コードの変更時に信号処理の内部状態がリセットされる問題がある。ディレイやフィルターは、内部状態（メモリ）への継続的な書き込みと読み込みを行うことで処理を実現しているが、その内部状態のインスタンスはコードのコンパイル後、信号処理を実際に始める前に0埋めで初期化されることが一般的である。
 
-Max（MSP）やPureData、SuperColliderのJITLibにおける信号処理のように、信号処理のインスタンスのグラフ接続自体を実行中に変更できるような仕組みの場合、内部状態は変更されず（グラフ接続の変更処理自体が間に合えば）オーディオが途切れることはない。
+Max（MSP）[@Max]やPureData[@puckettePureData1997]、SuperCollider[@McCartney2002]のJITLibにおける信号処理のように、信号処理のインスタンスのグラフ構成自体を実行中に変更できるような仕組みの場合、内部状態はキープされる。TidaiCycles[@McLean2014]やSonic Pi[@Aaron2013]のようなSuperColliderのクライアントとして実装される言語も同様である一方、信号処理を使った表現の幅はSuperColliderのプリミティブとして用意されたUnit Generatorの組み合わせに留まることになる。
 
-[[Faust]]やMaxのGenのように、サンプル単位レベルでの信号処理の記述ができるプログラミング言語の場合は、コードを一度低レベルな命令（FaustであればLLVM IRなど）に変換し、そのコードをインスタンス化してから実行するために、インスタンス化のタイミングで毎回内部状態はリセットされる。
+Faust[@Orlarey2009]やMaxのGen、のように、サンプル単位レベルでの信号処理の記述ができるプログラミング言語の場合は、コードを一度低レベルな命令（FaustであればLLVM IRなど）に変換し、そのコードをインスタンス化してから実行するために、インスタンス化のタイミングで毎回内部状態はリセットされる。
 
-[[ChucK]]のようなサンプル単位の制御処理を実現している言語も同様である。ChucKはShredという単位で信号処理インスタンスを実行中に追加、削除、更新ができるが、1つのShredが更新されるごとに内部状態はリセットされる。そのため、複数のShredが実行されていればどれか1つのShredを更新するたびに無音が挟まるようなことはないものの、Shredの中でディレイやリバーブを使用していた場合、そのディレイやリバーブのテールは更新時に途切れてしまう問題がある。
+同様に例えばChucK[@Wang2015]はShredという単位で信号処理インスタンスを実行中に追加、削除、更新ができるが、1つのShredが更新されるごとに内部状態はリセットされる。そのため、複数のShredが実行されていればどれか1つのShredを更新するたびに無音が挟まるようなことはないものの、Shredの中でディレイやリバーブを使用していた場合、そのディレイやリバーブのテールは更新時に途切れてしまう。
 
-一般的に、記述できる信号処理の最小単位を小さくしていくほど、コードの動的変更に対応することが難しくなるトレードオフがあるといえる（要引用）。
+こうした特徴をまとめると、音楽プログラミング言語の設計には記述できる信号処理の最小単位を小さくしていくほど、コードの動的変更に対応することが難しくなるトレードオフがあるといえる。
-
-## ユースケースと先行例
 
 
-[[Incremental Functional Reactive Programming]]がある。
+こうした課題に対し、Reachは関数型のUnit Generatorを組み合わせて信号処理を記述する言語で、ソースコードの変更差分を解析して信号処理の内部状態を可能な限り保持する仕組み:**Incremental Functional Reactive Programming**(IcFRP)を提案している[@reach_incremental_2013]。この仕組みは、SuperColliderのJITLibのようなシステムと比べるとユーザーが現在の信号処理インスタンスに対して削除や追加などの命令を行うのではなく、常にその時のソースコードに望む信号処理を書けば必要な状態の更新はランタイム側が自動で担ってくれるという点で、ユーザーの演奏中の思考モデルが大きく異なると言える。
 
-これはソースコードの増分比較に基づいている。同じ差分でも、複数の変更のパターンがあり得るので、単なるテキスト比較ではなくEmacsの拡張として操作の履歴を取得している。
+ただ、実装としては、ソースコードの単なるテキスト差分の解析では、複数の変更のパターンの可能性を絞り込めないため、テキストエディタEmacsの拡張として操作の履歴を取得することで実装しているため、実装は複雑なものと言える。
 
-プリミティブを小さくする＆＆ソースコードの変更→評価の間隔が短くても済むような仕組みを作れば良い。
+本稿では、筆者が開発してきた関数型音楽プログラミング言語mimiumに、IcFRPの考え方を応用したライブコーディングシステムを提案する。
+
+以下、本論文はmimiumのこれまでの言語設計の簡単な説明と、導入される2種類の機能拡張について順番に説明する。
+
+その後、本ライブコーディングシステムの他のシステムと比較した特徴および問題点を議論する。
+
+
+## mimium and lambda-mmm
+
+mimiumは、Rustに近いシンタックスを持った関数型の音楽信号処理をターゲットにしたプログラミング言語である[@matsuura2021]。現在の内部実行モデルとして、値呼び単純型付きラムダ計算を拡張し、最小限の内部状態を持つプリミティブ操作：ディレイとフィードバックを加えたLambda-mmm[@matsuura_lambda-mmm_2024]という計算体系を持っている。
+
+mimiumはコードを専用
 
-## lambda-mmm
 
 内部状態はDelayかMem、Feedのいずれかに還元される。
 Memは1サンプルのみのディレイであるため、最終的な計算結果としてDelayに与える遅延時間を1としたものと同一に見做せるが、実行モデル的に1サンプルのみのディレイはリングバッファの読み書きインデックスの追跡が必要ないため、区別しておく方が効率的に実行できる。
 
-詳細は(Matsuura,2024)を見よ。
+
 
 ## コールツリーの解析
 

content/木の差分を取るアルゴリズム.md

@@ -3,7 +3,7 @@ date: 2025-10-03 12:02
 ---
 #programming 
 
-[[関数型信号処理プログラミング言語のソース変更時に内部状態を差分保持するシステム]]に関連して。
+[[多段階計算と増分関数型リアクティブプログラミングのによる信号処理のライブコーディング]]に関連して。
 
 [F# Tree Diff Algorithm. Implementing an algorithm to find the… \| by Luke Burgess-Yeo \| F#ing About \| Medium](https://medium.com/f-ing-about/f-tree-diff-algorithm-5b7f9c85beac)