Files
quartz-research-note/content/mimiumでのライブコーディングエンジン.md

2.6 KiB
Raw Blame History

date
date
2025-06-27 16:54

#mimium #livecoding

mimiumでもライブコーディングがやりたいよね

一般化するとこういうモデルにならんだろうか

!img/general-livecoding-model.png

Tracksの部分の抜き差しだけできるのがChucKのShredシステム。

とりあえずはこれをRust実装してもいいけど、最終的にはこのモデル自体をmimium上で実装することもできそう

不要なトラックの削除と空きスロット再利用を実現するためには、普通の配列とは別に単方向リストかSlotmap的なものを作る必要がありそう

Reducerは基本的には全てのチャンネルの加算だけでいいので滅多にいじる必要ないけど、いじりたいケースが出てくるかも

ChucKではエフェクトのテールが更新時にぶちぎれる問題があったので、それを防ぐためのPostFX Chain

各トラックごとのエフェクトのライブ切り替えとかも実現しようと思えばできるかな

...これ、結局SuperColliderのJITLibと同じことかもな

jitlib_basic_concepts_01 | SuperCollider 3.14.0-dev Help

信号処理の状態持ち越し

Incremental Functional Reactive Programmingの仕組みを用いることはできるだろうか

//これが
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)

に更新される

enum StateLeaf{
   Nested(Box<StateTree>),
   Delay(usize),
   Feedback(usize),
}
struct StateTree{
  children: Vec<StateLeaf>
}

クロージャの呼び出しの時は?

コンパイル時ではなく、Closure命令でクロージャが作られる際にアロケートとIDの振り分けが起きる

クロージャ