[obsidian] vault backup: 2025-06-27 17:54:31[
All checks were successful
Build / build (push) Successful in 6m52s
All checks were successful
Build / build (push) Successful in 6m52s
This commit is contained in:
BIN
content/img/general-livecoding-model.png
Normal file
BIN
content/img/general-livecoding-model.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 114 KiB |
@ -39,6 +39,7 @@ https://github.com/mimium-org/mimium-rs
|
||||
- [[mimiumのプラグインシステム]]
|
||||
- [[WASIでmimiumをビルド&デバッグしてみる]]
|
||||
- [[mimiumの配列実装]]
|
||||
- [[mimiumのREPLをVMで実装]]
|
||||
|
||||
## 応用先について
|
||||
|
||||
|
@ -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
|
||||
|
||||
各トラックごとのエフェクトのライブ切り替えとかも実現しようと思えばできるかな
|
||||
|
||||
|
57
content/mimiumのREPLをVMで実装.md
Normal file
57
content/mimiumのREPLをVMで実装.md
Normal file
@ -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越しに行える必要がある
|
||||
|
||||
というか、メインスレッドに相当するものを別途作る方がやっぱり良さそう
|
||||
|
||||
|
Reference in New Issue
Block a user