diff --git a/content/img/general-livecoding-model.png b/content/img/general-livecoding-model.png
new file mode 100644
index 00000000..ccb94337
Binary files /dev/null and b/content/img/general-livecoding-model.png differ
diff --git a/content/mimium.md b/content/mimium.md
index 85ddaf7d..d1489106 100644
--- a/content/mimium.md
+++ b/content/mimium.md
@@ -39,6 +39,7 @@ https://github.com/mimium-org/mimium-rs
 - [[mimiumのプラグインシステム]]
 - [[WASIでmimiumをビルド＆デバッグしてみる]]
 - [[mimiumの配列実装]]
+- [[mimiumのREPLをVMで実装]]
 
 ## 応用先について
 
diff --git a/content/mimiumでのライブコーディングエンジン.md b/content/mimiumでのライブコーディングエンジン.md
index c7674f6e..ed40d235 100644
--- a/content/mimiumでのライブコーディングエンジン.md
+++ b/content/mimiumでのライブコーディングエンジン.md
@@ -3,4 +3,19 @@ date: 2025-06-27 16:54
 ---
 #mimium #livecoding 
 
+一般化するとこういうモデルにならんだろうか
+
+![[img/general-livecoding-model.png]]
+
+Tracksの部分の抜き差しだけできるのが[[ChucK]]のShredシステム。
+
+とりあえずはこれをRust実装してもいいけど、最終的にはこのモデル自体をmimium上で実装することもできそう
+
+（不要なトラックの削除と空きスロット再利用を実現するためには、普通の配列とは別に単方向リストかSlotmap的なものを作る必要がありそう）
+
+Reducerは基本的には全てのチャンネルの加算だけでいいので滅多にいじる必要ないけど、いじりたいケースが出てくるかも
+
+ChucKではエフェクトのテールが更新時にぶちぎれる問題があったので、それを防ぐためのPostFX Chain
+
+各トラックごとのエフェクトのライブ切り替えとかも実現しようと思えばできるかな
 
diff --git a/content/mimiumのREPLをVMで実装.md b/content/mimiumのREPLをVMで実装.md
new file mode 100644
index 00000000..4172a246
--- /dev/null
+++ b/content/mimiumのREPLをVMで実装.md
@@ -0,0 +1,57 @@
+---
+date: 2025-06-27 17:10
+---
+#mimium #memo 
+
+今の所の問題点として
+
+- マシンが一つの結合されたコンパイル済みバイトコードしか受け付けていない
+	- これを配列として複数保持する必要あり
+- 外部関数の参照インデックスのテーブルはVM上に載っているが、内部関数は一つのプログラム上の絶対位置しか参照できない
+- プログラム上で定義した内部関数を、他のプログラムでも参照できるようにする、シンボルテーブルがいる
+- またグローバル環境の評価も同様に、シンボル-(GlobalPos,型)変換のテーブルをコンパイラが持っていないとだめ
+
+- マシンをオーディオドライバ立ち上げとともにオーディオスレッドにMoveしてしまっているので、メインスレッドで新たにコンパイルしたプログラムを何かの方法でオーディオスレッドに送ってやらないといけない
+	- しかもできればロックフリーで
+		- [GitHub - hawkw/sharded-slab: a lock-free concurrent slab (experimental)](https://github.com/hawkw/sharded-slab)　これかな
+		- それか普通にDashMapか
+- シンボルテーブルもDashMapで作ってればなんとかなるのかな
+- VMの中にControllerみたいなDashMap系をArcで包んだものを用意しておいて、メインのマシンはオーディオスレッドに送ってしまい、Arcでコントローラーだけをメインスレッドに残しておく
+
+- ExecContextはRepl起動から終了まで次の情報を持ち続ける
+	- グローバル変数のシンボルテーブル（型情報含む）
+	- 内部関数のシンボルテーブル（型情報含む）
+	- 外部関数のシンボルテーブル（型情報含む）
+
+
+ExecContextは、起動時VMのインスタンスを作る。この時VMConrollerのArc参照がVM内に渡される。
+
+ExecContextは、ソースコードを受け取るたびにコンパイラのインスタンスを作ってはプログラムを出力し、終了する。
+
+出力されたプログラムはVMControllerのPrograms(DashMap)に非同期でインサートされ、シンボルテーブルも更新される
+
+Replで送られた新しいプログラム（一行だけ）のプログラムをどのスレッドで、いつ実行するかが問題
+
+DSPの頭でReplで溜まった処理(無名関数のキュー)を順番に消化する？あるいは、
+
+```rust
+dsp = |l,r| ->(float,float){ ( new_process )}
+```
+
+こんな感じでREPLに送ると、実際には
+
+```rust
+fn repl_001(){
+	| | {
+		dsp = |l,r| ->(float,float){ (　new_process )}
+	}@now
+}
+```
+
+みたいなのを実行したことになるとか
+
+これだとスケジューラープラグイン実装されてることが前提にはなるし、スケジューラーにタスクを登録するのをController越しに行える必要がある
+
+というか、メインスレッドに相当するものを別途作る方がやっぱり良さそう
+
+