[obsidian] vault backup: 2025-10-12 23:12:54[
Some checks failed
Build / build (push) Failing after 11m27s

This commit is contained in:
2025-10-12 23:12:54 +09:00
parent a29eae0284
commit a8cc9738bb
46 changed files with 228 additions and 14 deletions

View File

@@ -15,15 +15,18 @@ date: 2025-09-25 11:42
## 背景
音楽のためのプログラミングにおけるライブコーディングとは、音楽を生成するプログラムのソースコードをリアルタイムで書き換えながら演奏するパフォーマンスのスタイルである[@]。
既存の信号処理をターゲットにした音楽プログラミング言語における問題の一つとして、コードの変更時に信号処理の内部状態がリセットされる問題がある。ディレイやフィルターは、内部状態メモリへの継続的な書き込みと読み込みを行うことで処理を実現しているが、その内部状態のインスタンスはコードのコンパイル後、信号処理を実際に始める前に0埋めで初期化されることが一般的である。
MaxMSPやPureDataにおける信号処理のように、信号処理のインスタンスのグラフ接続自体を実行中に変更できるような仕組みの場合、内部状態は変更されずグラフ接続の変更処理自体が間に合えばオーディオが途切れることはない。
MaxMSPやPureData、SuperColliderのJITLibにおける信号処理のように、信号処理のインスタンスのグラフ接続自体を実行中に変更できるような仕組みの場合、内部状態は変更されず(グラフ接続の変更処理自体が間に合えば)オーディオが途切れることはない。
[[Faust]]やMaxのGenのように、サンプル単位レベルでの信号処理の記述ができるプログラミング言語の場合は、コードを一度低レベルな命令FaustであればLLVM IRなどに変換し、そのコードをインスタンス化してから実行するために、インスタンス化のタイミングで毎回内部状態はリセットされる。
[[ChucK]]のようなサンプル単位の制御処理を実現している言語も同様である。ChucKはShredという単位で信号処理インスタンスを実行中に追加、削除、更新ができるが、1つのShredが更新されるごとに内部状態はリセットされる。そのため、複数のShredが実行されていればどれか1つのShredを更新するたびに無音が挟まるようなことはないものの、Shredの中でディレイやリバーブを使用していた場合、そのディレイやリバーブのテールは更新時に途切れてしまう問題がある。
一般的に、記述できる信号処理の最小単位を小さくしていくほど、コードの動的変更に対応することが難しくなるトレードオフがある(要引用)。
一般的に、記述できる信号処理の最小単位を小さくしていくほど、コードの動的変更に対応することが難しくなるトレードオフがあるといえる(要引用)。
## ユースケースと先行例