diff --git a/content/ChucK.md b/content/ChucK.md
index 882c9101..d10d0cba 100644
--- a/content/ChucK.md
+++ b/content/ChucK.md
@@ -11,7 +11,7 @@ C言語っぽいシンタックスでサンプル単位での正確なスケジ
 
 命令型＋クラスを作ったりのオブジェクト指向（継承もあり）。
 
-shredという論理時間ベースの計量スレッドみたいなものを言語内からスポーン、もしくはコマンドから立ち上げることができる。1つのファイルをスレッド単位で立ち上げたり殺したりをリアルタイムで切り替えることで、ライブコーディングを実現している（ただし更新のタイミングでディレイやリバーブのテールは切れる）。
+shredという論理時間ベースの計量スレッドみたいなものを言語内からスポーン、もしくはコマンドから立ち上げることができる。1つのファイルをスレッド単位で立ち上げたり殺したりをリアルタイムで切り替えることで、[[ライブコーディング]]を実現している（ただし更新のタイミングでディレイやリバーブのテールは切れる）。
 
 最近も活発に更新が進んでいて、モジュール機能などが導入された。
 
diff --git a/content/Glicol.md b/content/Glicol.md
index b39c474e..b1a4aaa1 100644
--- a/content/Glicol.md
+++ b/content/Glicol.md
@@ -4,6 +4,6 @@ date: 2025-01-15 15:29
 #programming-language #computermusic #livecoding
 
 
-[[Rust]]製のライブコーディング環境。
+[[Rust]]製の[[ライブコーディング]]環境。
 
 [GitHub - chaosprint/glicol: Graph-oriented live coding language and music/audio DSP library written in Rust](https://github.com/chaosprint/glicol)
diff --git a/content/Incremental Functional Reactive Programming.md b/content/Incremental Functional Reactive Programming.md
new file mode 100644
index 00000000..f1bda770
--- /dev/null
+++ b/content/Incremental Functional Reactive Programming.md	
@@ -0,0 +1,30 @@
+---
+date: 2025-08-20 15:12
+---
+#programming-language #research 
+
+[[Caleb Reach]]による、信号処理エンジンの[[ライブコーディング]]のための手法の提案。
+
+[49.dafx2013\_submission\_60.pdf](https://www.dafx.de/paper-archive/2013/papers/49.dafx2013_submission_60.pdf)
+
+[[ChucK]]や[[Faust]]など、ライブコーディングでシグナルグラフを丸ごと作り直すタイプの言語では、ディレイやリバーブのテールがコードの再コンパイル時に状態が吹き飛ぶためぶった切れる問題がある。
+
+[[Functional Reactive Programming]]の手法で、各項（状態を持つプリミティブ）毎のユニークなラベルをつけて、再コンパイル時に状態を持ち越せるところでは持ち越せるというやり方を提案している
+
+ただ、単純なテキスト同士の差分比較ではユニークなラベルの増分更新は意外と難しく、例えば
+
+`(define x (+ (f 2) (f 3) 2))`
+
+が
+
+`(define x (+ (f 5) (f 2) (f 3) 2))`
+
+に更新されたとき、ぱっと見は「`(f 2) (f 3)`の手前に新たに`(f 5)`が挿入された」と考えることができるが、原理的には「`(f 2) (f 3)`をまず`(f 5) (f 2)`へ書き換え、後ろに`(f 3)`を挿入した」と区別することはできない。そうなると新たに挿入された項だけ0で初期化して新たにアロケートする、となった時に、どこを0初期化すべきか決定できない。
+
+きちんと文脈を持ち越すためにはエディタレベルでの編集履歴と突き合わせる連携が必要となる（論文中では[[Emacs]]の拡張として実装しているらしい）
+
+この言語における関数定義と適用はあくまでコンパイル時計算（+や`*`は状態を持たないランタイム時に実行される計算ノード）
+
+
+
+
diff --git a/content/Lua.md b/content/Lua.md
index e685f4b0..36cc575b 100644
--- a/content/Lua.md
+++ b/content/Lua.md
@@ -9,7 +9,7 @@ date: "2023-09-12T15:40:18+0900"
 
 JITコンパイラで超高速に動く別の処理系[[LuaJIT]]もある
 
-Luaでオーディオビジュアルライブコーディングをするための[[LuaAV]]などがある（更新されてないけど）
+Luaでオーディオビジュアル[[ライブコーディング]]をするための[[LuaAV]]などがある（更新されてないけど）
 
 動的型付けで手続き型っぽいが、関数を第一級オブジェクトとして扱える。そのためクロージャを使用できるが、この実装にupvalueという方式を採用していることで有名（？）
 
diff --git a/content/Sonic Pi.md b/content/Sonic Pi.md
index 983fb622..43f62968 100644
--- a/content/Sonic Pi.md	
+++ b/content/Sonic Pi.md	
@@ -9,7 +9,7 @@ date: "2024-02-06T02:00:06+0900"
 
 言語のフロントエンドは[[Ruby]]、オーディオ合成エンジンは[[SuperCollider]]、イベントスケジューリングには[[Erlang]]のバックエンドになっている[[BEAM VM]]を使ってる。
 
-最近新バージョン（というか別プロジェクト）で[[Luerl]]というErlang上で実装された[[Lua]]と、独自のDSLであるTau5Langというのをサポート予定らしい。
+最近新バージョン（というか別プロジェクト）の[[Tau5]]という言語では、[[Luerl]]というErlang上で実装された[[Lua]]と、独自のDSLであるTau5Langというのをサポート予定らしい。
 
 [GitHub - samaaron/tau5: Code. Music. Live.](https://github.com/samaaron/tau5)
 
diff --git a/content/facet.md b/content/facet.md
index 8db0a9df..74c36b29 100644
--- a/content/facet.md
+++ b/content/facet.md
@@ -3,6 +3,6 @@ date: 2025-06-12 10:32
 ---
 #programming-language 
 
-[[Max]]上で動作するJSベースのライブコーディング用スクリプティング言語
+[[Max]]上で動作するJSベースの[[ライブコーディング]]用スクリプティング言語
 
 [GitHub - nnirror/facet: Live coding and synthesis with NodeJS and a browser](https://github.com/nnirror/facet)
\ No newline at end of file
diff --git a/content/mimiumでのライブコーディングエンジン.md b/content/mimiumでのライブコーディングエンジン.md
index e7268f08..571ece16 100644
--- a/content/mimiumでのライブコーディングエンジン.md
+++ b/content/mimiumでのライブコーディングエンジン.md
@@ -3,6 +3,8 @@ date: 2025-06-27 16:54
 ---
 #mimium #livecoding 
 
+mimiumでも[[ライブコーディング]]がやりたいよね
+
 一般化するとこういうモデルにならんだろうか
 
 ![[img/general-livecoding-model.png]]
@@ -22,3 +24,60 @@ ChucKではエフェクトのテールが更新時にぶちぎれる問題があ
 ...これ、結局[[SuperCollider]]のJITLibと同じことかもな
 
 [jitlib\_basic\_concepts\_01 \| SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/JITLib/jitlib_basic_concepts_01.html)
+
+## 信号処理の状態持ち越し
+
+[[Incremental Functional Reactive Programming]]の仕組みを用いることはできるだろうか
+
+```rust
+//これが
+fn dsp(){
+  delay(100,100,input)+ delay(200,200,input)
+}
+//こう更新されるとする
+fn dsp(){
+  delay(300,300,input) + delay(100,100,input)+ delay(200,200,input)
+}
+```
+
+`delay(100)`にはID(delay_1)が、`delay(200)`にはID(delay_2)がそれぞれつけられる
+
+（どう増分検出するかの仕組みは置いといて）、再コンパイル時に100と200はそのまま、新しく増えたdelay(300)にID`(delay_3)`を挿入する
+
+そうすると、StateStackのためのメモリは完全にリニアにはしないほうが良くて、ツリー状のデータ構造に戻した方が良さそう
+
+[[Red Green Syntax Tree]]のGreen Node→状態メモリのマップだと考えるとわかりやすいのか？
+
+```
+dsp
+|       \
+delay(1) delay(2)
+```
+
+から
+
+```
+          dsp
+    /      |       \
+delay(3)delay(1) delay(2)
+```
+
+に更新される
+
+```rust
+enum StateLeaf{
+   Nested(Box<StateTree>),
+   Delay(usize),
+   Feedback(usize),
+}
+struct StateTree{
+  children: Vec<StateLeaf>
+}
+```
+
+
+クロージャの呼び出しの時は？
+
+コンパイル時ではなく、Closure命令でクロージャが作られる際にアロケートとIDの振り分けが起きる
+
+クロージャ
diff --git a/content/色素増感太陽電池実験2.md b/content/色素増感太陽電池実験2.md
index 05e16dbb..b18c9916 100644
--- a/content/色素増感太陽電池実験2.md
+++ b/content/色素増感太陽電池実験2.md
@@ -1,7 +1,7 @@
 ---
 date: 2025-04-22 15:39
 ---
-#reseach #dssc #semiconductor 
+#research #dssc #semiconductor 
 
 ## 陰極の作成