[obsidian] vault backup: 2025-10-06 17:32:31[
All checks were successful
Build / build (push) Successful in 21m3s
All checks were successful
Build / build (push) Successful in 21m3s
This commit is contained in:
@@ -34,9 +34,10 @@ Max(MSP)やPureDataにおける信号処理のように、信号処理のイ
|
||||
|
||||
プリミティブを小さくする&&ソースコードの変更→評価の間隔が短くても済むような仕組みを作れば良い。
|
||||
|
||||
## lambda-mmmの記法
|
||||
## lambda-mmm
|
||||
|
||||
内部状態はDelayかFeedのいずれかに還元される。
|
||||
内部状態はDelayかMem、Feedのいずれかに還元される。
|
||||
Memは1サンプルのみのディレイであるため、最終的な計算結果としてDelayに与える遅延時間を1としたものと同一に見做せるが、実行モデル的に1サンプルのみのディレイはリングバッファの読み書きインデックスの追跡が必要ないため、区別しておく方が効率的に実行できる。
|
||||
|
||||
詳細は(Matsuura,2024)を見よ。
|
||||
|
||||
@@ -51,6 +52,8 @@ Max(MSP)やPureDataにおける信号処理のように、信号処理のイ
|
||||
|
||||
エントリポイント`dsp`からの非クロージャ関数呼び出しを辿っていけば静的に使用する内部状態の木構造が導出できる。
|
||||
|
||||
再帰関数を用いて複雑な信号処理を実現する場合でも、多段階計算を使用してコードを記述した場合は、実行時にクロージャを生成することなく静的な関数呼び出し
|
||||
|
||||
## 状態構造ツリー同士の比較
|
||||
|
||||
ソースコードをなるべく頻繁に編集するのであれば、内部状態の構造の変化は木の要素のうち1箇所の削除、追加、置き換えである可能性が高い。
|
||||
|
Reference in New Issue
Block a user