[obsidian] vault backup: 2025-08-20 15:53:54[

This commit is contained in:
2025-08-20 15:53:54 +09:00
parent 2d448d58c8
commit 2d572c3073
8 changed files with 95 additions and 6 deletions

View File

@@ -11,7 +11,7 @@ C言語っぽいシンタックスでサンプル単位での正確なスケジ
命令型+クラスを作ったりのオブジェクト指向(継承もあり)。 命令型+クラスを作ったりのオブジェクト指向(継承もあり)。
shredという論理時間ベースの計量スレッドみたいなものを言語内からスポーン、もしくはコマンドから立ち上げることができる。1つのファイルをスレッド単位で立ち上げたり殺したりをリアルタイムで切り替えることで、ライブコーディングを実現しているただし更新のタイミングでディレイやリバーブのテールは切れる shredという論理時間ベースの計量スレッドみたいなものを言語内からスポーン、もしくはコマンドから立ち上げることができる。1つのファイルをスレッド単位で立ち上げたり殺したりをリアルタイムで切り替えることで、[[ライブコーディング]]を実現している(ただし更新のタイミングでディレイやリバーブのテールは切れる)。
最近も活発に更新が進んでいて、モジュール機能などが導入された。 最近も活発に更新が進んでいて、モジュール機能などが導入された。

View File

@@ -4,6 +4,6 @@ date: 2025-01-15 15:29
#programming-language #computermusic #livecoding #programming-language #computermusic #livecoding
[[Rust]]製のライブコーディング環境。 [[Rust]]製の[[ライブコーディング]]環境。
[GitHub - chaosprint/glicol: Graph-oriented live coding language and music/audio DSP library written in Rust](https://github.com/chaosprint/glicol) [GitHub - chaosprint/glicol: Graph-oriented live coding language and music/audio DSP library written in Rust](https://github.com/chaosprint/glicol)

View File

@@ -0,0 +1,30 @@
---
date: 2025-08-20 15:12
---
#programming-language #research
[[Caleb Reach]]による、信号処理エンジンの[[ライブコーディング]]のための手法の提案。
[49.dafx2013\_submission\_60.pdf](https://www.dafx.de/paper-archive/2013/papers/49.dafx2013_submission_60.pdf)
[[ChucK]]や[[Faust]]など、ライブコーディングでシグナルグラフを丸ごと作り直すタイプの言語では、ディレイやリバーブのテールがコードの再コンパイル時に状態が吹き飛ぶためぶった切れる問題がある。
[[Functional Reactive Programming]]の手法で、各項(状態を持つプリミティブ)毎のユニークなラベルをつけて、再コンパイル時に状態を持ち越せるところでは持ち越せるというやり方を提案している
ただ、単純なテキスト同士の差分比較ではユニークなラベルの増分更新は意外と難しく、例えば
`(define x (+ (f 2) (f 3) 2))`
`(define x (+ (f 5) (f 2) (f 3) 2))`
に更新されたとき、ぱっと見は「`(f 2) (f 3)`の手前に新たに`(f 5)`が挿入された」と考えることができるが、原理的には「`(f 2) (f 3)`をまず`(f 5) (f 2)`へ書き換え、後ろに`(f 3)`を挿入した」と区別することはできない。そうなると新たに挿入された項だけ0で初期化して新たにアロケートする、となった時に、どこを0初期化すべきか決定できない。
きちんと文脈を持ち越すためにはエディタレベルでの編集履歴と突き合わせる連携が必要となる(論文中では[[Emacs]]の拡張として実装しているらしい)
この言語における関数定義と適用はあくまでコンパイル時計算(+や`*`は状態を持たないランタイム時に実行される計算ノード)

View File

@@ -9,7 +9,7 @@ date: "2023-09-12T15:40:18+0900"
JITコンパイラで超高速に動く別の処理系[[LuaJIT]]もある JITコンパイラで超高速に動く別の処理系[[LuaJIT]]もある
Luaでオーディオビジュアルライブコーディングをするための[[LuaAV]]などがある(更新されてないけど) Luaでオーディオビジュアル[[ライブコーディング]]をするための[[LuaAV]]などがある(更新されてないけど)
動的型付けで手続き型っぽいが、関数を第一級オブジェクトとして扱える。そのためクロージャを使用できるが、この実装にupvalueという方式を採用していることで有名 動的型付けで手続き型っぽいが、関数を第一級オブジェクトとして扱える。そのためクロージャを使用できるが、この実装にupvalueという方式を採用していることで有名

View File

@@ -9,7 +9,7 @@ date: "2024-02-06T02:00:06+0900"
言語のフロントエンドは[[Ruby]]、オーディオ合成エンジンは[[SuperCollider]]、イベントスケジューリングには[[Erlang]]のバックエンドになっている[[BEAM VM]]を使ってる。 言語のフロントエンドは[[Ruby]]、オーディオ合成エンジンは[[SuperCollider]]、イベントスケジューリングには[[Erlang]]のバックエンドになっている[[BEAM VM]]を使ってる。
最近新バージョン(というか別プロジェクト)[[Luerl]]というErlang上で実装された[[Lua]]と、独自のDSLであるTau5Langというのをサポート予定らしい。 最近新バージョン(というか別プロジェクト)の[[Tau5]]という言語では、[[Luerl]]というErlang上で実装された[[Lua]]と、独自のDSLであるTau5Langというのをサポート予定らしい。
[GitHub - samaaron/tau5: Code. Music. Live.](https://github.com/samaaron/tau5) [GitHub - samaaron/tau5: Code. Music. Live.](https://github.com/samaaron/tau5)

View File

@@ -3,6 +3,6 @@ date: 2025-06-12 10:32
--- ---
#programming-language #programming-language
[[Max]]上で動作するJSベースのライブコーディング用スクリプティング言語 [[Max]]上で動作するJSベースの[[ライブコーディング]]用スクリプティング言語
[GitHub - nnirror/facet: Live coding and synthesis with NodeJS and a browser](https://github.com/nnirror/facet) [GitHub - nnirror/facet: Live coding and synthesis with NodeJS and a browser](https://github.com/nnirror/facet)

View File

@@ -3,6 +3,8 @@ date: 2025-06-27 16:54
--- ---
#mimium #livecoding #mimium #livecoding
mimiumでも[[ライブコーディング]]がやりたいよね
一般化するとこういうモデルにならんだろうか 一般化するとこういうモデルにならんだろうか
![[img/general-livecoding-model.png]] ![[img/general-livecoding-model.png]]
@@ -22,3 +24,60 @@ ChucKではエフェクトのテールが更新時にぶちぎれる問題があ
...これ、結局[[SuperCollider]]のJITLibと同じことかもな ...これ、結局[[SuperCollider]]のJITLibと同じことかもな
[jitlib\_basic\_concepts\_01 \| SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/JITLib/jitlib_basic_concepts_01.html) [jitlib\_basic\_concepts\_01 \| SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/JITLib/jitlib_basic_concepts_01.html)
## 信号処理の状態持ち越し
[[Incremental Functional Reactive Programming]]の仕組みを用いることはできるだろうか
```rust
//これが
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)
```
に更新される
```rust
enum StateLeaf{
Nested(Box<StateTree>),
Delay(usize),
Feedback(usize),
}
struct StateTree{
children: Vec<StateLeaf>
}
```
クロージャの呼び出しの時は?
コンパイル時ではなく、Closure命令でクロージャが作られる際にアロケートとIDの振り分けが起きる
クロージャ

View File

@@ -1,7 +1,7 @@
--- ---
date: 2025-04-22 15:39 date: 2025-04-22 15:39
--- ---
#reseach #dssc #semiconductor #research #dssc #semiconductor
## 陰極の作成 ## 陰極の作成