[obsidian] vault backup: 2025-09-20 13:42:31[

content/Ad-Astra.md

@@ -0,0 +1,8 @@
+---
+date: 2025-09-20 11:59
+---
+#programming-language 
+
+[[Lady Deirdre]]を作ってる人のスクリプティングプログラミング言語。[[Rust]]で実装されてる
+
+[Introduction - The Ad Astra Book](https://ad-astra.lakhin.com/)

content/Critical Engineering Manifesto.md

@@ -0,0 +1,8 @@
+---
+date: 2025-09-16 16:36
+---
+#aesthetics 
+
+日本語訳は[[牛込陽介]]さんが書いている
+
+[The Critical Engineering Manifesto \| jp](https://criticalengineering.org/jp)

content/DAWのプロジェクトというデータ構造.md

@@ -0,0 +1,64 @@
+---
+date: 2025-09-05 11:37
+---
+#memo 
+
+[[DAW]]について
+
+[[otopoiesis]]に行き詰まったので
+
+## プロジェクトデータ
+
+- 複数のトラックを含む
+- グローバルなパラメーター（テンポとか）
+
+## トラック
+
+[[Temporal Type Constructor]]で表現されうる時間軸に沿って変化するデータ
+
+データを持つトラック
+
+ - 入出力を持つ
+	 - MIDI
+	 - OSC
+	 - オーディオ
+ - 入出力の型が一致すれば、他のトラックが別のトラックの入力になることもある
+ - 大きく分けて以下のタイプ
+	 - プロトタイプ：時間に紐付けされたイベントの集合`[Event<a>]`
+	 - ストリーム： 一定間隔で表現されるデータ列
+		 - この際Control/Audioの2タイプでもいい
+	
+`時間に紐付けされたイベントの集合Event<a>`に関しては、トラックの出力に接続する際にストリームに変換される必要がある
+
+- オーディオクリップも広い意味では`[Event<AudioClip>]`的なデータ
+	- だが、レコーディング、再生の際のストリームデータへの変換は暗黙的に行われている
+
+```
+struct Clip<a>{
+	dur:Number
+	data:a
+}
+type MonoAudioClip = Event<Clip<Vec<Number>>>
+
+type AudioTrackProto = [MonoAudioClip]
+
+```
+
+MIDIトラックの場合はもっと複雑。タイムスタンプが一つ一つに付属したデータの集合になるけど、記録時にはそれをさらにタイムスタンプ付きClipとしてグループ化、クリップスタートの相対時間として記録している
+
+入出力のデータ型がジェネリックになるとすると、その読み書きはなんかジェネリックなシリアライズ・デシリアライズができる必要あり
+
+## エフェクター的なもの
+
+- あるトラックの出力を受け取って、値->値変換をするだけ
+- ただしパラメーターはグループ化されていて欲しい
+
+
+
+## どうやってジェネラティブ性を組み込むか
+
+- 録音の代わりに、クリップデータの生成
+- クリップ→クリップのノンリニアな変換
+- 
+
+

content/Dick Raaijmakers.md

@@ -0,0 +1,12 @@
+---
+date: 2025-08-29 10:29
+---
+#person 
+
+オランダの電子音楽の作曲家で、[[STEIM]]創設者の一人。
+
+Drie Ideophonenシリーズ好き
+
+[p. 20 Drie Ideofonen by Dick Raaijmakers - Between Air and Electricity](https://microphonesandloudspeakers.com/2017/01/31/p-20-drie-ideofonen-dick-raaijmakers/)
+
+

content/JavaScript.md

@@ -0,0 +1,4 @@
+---
+date: 2025-09-17 09:55
+---
+#stub

content/Lady Deirdre.md

@@ -0,0 +1,10 @@
+---
+date: 2025-09-17 09:51
+---
+#programming 
+
+インクリメンタル、並列対応の[[パーサジェネレータ]]。[[Rust]]のマクロで型安全に文法の定義をできる。
+
+[Introduction - The Lady Deirdre Guide](https://lady-deirdre.lakhin.com/)
+
+ただ、オープンソースだがプロプライエタリなライセンス

content/PAW.md

@@ -11,3 +11,21 @@ date: 2025-08-21 15:04
 [[Sketch-n-Sketch]]や、[[Hazel]]の[[Live Literal]]、[[Typed Hole]]という編集機能から影響を受けている。
 
 [\[LIVE23\] PAW: a programmable and visual audio workstation - YouTube](https://www.youtube.com/watch?v=X6m3NoPNzy4)
+
+
+ソースコード https://codeberg.org/xlambein/futile/src/branch/main/paw/src
+
+
+
+## Macで ビルドしてみる
+Homebrewインストールしたものを使うなら
+
+`LLVM_SYS_170_PREFIX=$(llvm-config--prefix) cargo run`で走らせる。
+
+ビルドには[[LLVM]]と[[ripgrep]]、[[JACK]]のインストールが必要
+
+`build.rs`で`ld`に`--dynamic-list=xxx.txt`というのを渡しているのだが（futileのJITコンパイルされたシンボル？）、macOS標準の(XCode CLI toolsの)ldはこれを受け取らない。
+
+そもそもELFでないとあんまり意味のないオプションらしいので、build.rsのmainを全部コメントアウトしてみたらビルドはできた。
+
+が、最初のjackのdlopenに失敗している、、、

content/Rust.md

@@ -11,5 +11,6 @@ date: "2023-09-01T19:08:25+0900"
 - [[Rhai]]
 - [[Moonbit]]
 - [[Gream]]
+- [[Ad-Astra]]
 
 [[RustでGUIを作る選択肢]]

content/Tree-Sitter.md

@@ -0,0 +1,29 @@
+---
+date: 2025-09-17 09:53
+---
+#programming-language 
+
+[Introduction - Tree-sitter](https://tree-sitter.github.io/tree-sitter/)
+
+モダンな[[パーサジェネレータ]]。
+
+[[Rust]]で実装されているが、Cライブラリを経由して様々な言語のバインディングが用意されている。
+
+ただ、言語の文法定義は[[JavaScript]]で行うなどちょっと複雑な作りをしている。
+
+インクリメンタルな構文解析に対応していることが特徴。
+
+---
+
+### 実際に使おうとしてみての感想
+
+カスタムの構文解析エラーメッセージの定義とかが難しい。これは長年問題になっているみたい
+
+[Helpful parser error messages · Issue #255 · tree-sitter/tree-sitter · GitHub](https://github.com/tree-sitter/tree-sitter/issues/255)
+
+---
+
+Rustのバインディングの問題。
+
+`kind_id`など多くのAPIがu16でのIDを返す
+

content/f3.js.md

@@ -0,0 +1,10 @@
+---
+date: 2025-09-05 12:23
+---
+#research 
+
+[[加藤淳]]による研究。
+
+[f3.js \| IoTコンテンツを作ろう！ \| f3js.org](https://f3js.org/)
+
+Node.jsでIoTデバイスの動作設計コードと筐体設計用のビジュアルデザインを並行して一緒に作れる

content/mimiumの配列実装.md

@@ -77,3 +77,46 @@ impl Machine{
 }
 
 ```
+
+
+## 用途
+
+例えばcatさんに作ってもらったこの辺の再帰を用いたコードがあるとする
+
+```rust
+fn gen_metalic_rec(times,freq,oscproto){
+  if(times>0){
+    let next = gen_metalic_rec(times-1,freq*1.176,oscproto)
+    let osc = oscproto();
+    | | { osc(freq) + next() }
+  }else{
+    | | 0.0
+  }
+}
+fn gen_metalic(times,freq){
+  let gen = gen_metalic_rec(times,freq,| | square_0);
+  | | gen() / times
+}
+let lowest_freq = 200.0
+let myoscbank = gen_metalic(6,lowest_freq)
+```
+
+こういう組み込み関数を与えて、
+
+```rust
+extern enumerate_by: (times,init:float,(x:float,acc:float)->float)->[float]
+```
+
+```rust
+
+fn metalic(times,lowest_freq){
+  let freqs =  enumerate_by(times,lowest_freq, |_x,acc| acc*1.167)
+  let res = map(freqs,|f| `square_0(liftf(f)))
+	        |> foldl(_, |x,acc| `{ $x + $acc } )
+  `{$res / liftf(times)}
+}
+fn dsp(){
+  metalic!(6,200)
+}
+
+```

content/otopoiesis.md

@@ -64,8 +64,8 @@ type Generator<T> = iVec<T>
 
 ```
 //Freq440Hz,Gain1.0,Phase0.0
-let Track1 = Generator::SineWave(Constant(440),Constant(1.0),Constant(0.0));
+let t1 = Track(Generator::SineWave(Constant(440),Constant(1.0),Constant(0.0)));
-let Track2 = Generator::SineWave(Track1,Constant(1.0),Constant(0.0));
+let t2 = Track(Generator::SineWave(t1,Constant(1.0),Constant(0.0)));
 ```
 これをあんまり動的ディスパッチじゃない感じで実装したい。そしてこの辺までは別にMaxとかと同じレベルの話
 
@@ -76,39 +76,210 @@ CubaseにおけるインストゥルメントトラックとかはMIDIトラッ
 
 ## 考えうるユースケース
 
+```rust
+type Region = {
+ start:float,
+ dur:float,
+ content: [float],
+} 
+
+fn region(start,dur,content:(({start,dur})->float))->Region{
+	let wave = render_mono(||content(start,dur)) |> probe_array 
+	{
+		start = start_p,
+		dur = dur_p,
+		content = wave
+	}
+}
+
+```
+
+### 一般的なリージョンエフェクト
+
+```rust
+type alias FX = ({s:float,start:float,dur:float})->float
+fn region_transformer(origin:Region,fx:FX) -> 'Region{
+	let start = origin.start
+	let dur = origin.dur
+	 `region({
+		start:$start,
+		dur:$dur,
+		content: |start,dur| {s:$origin.content(),start:$start,dur:$dur} |> $fx
+	})
+}
+```
+
 ### リージョンに対するFadeInOut
 
 ```rust
-fn fade_inout(origin:Region)->Region{
+fn apply_fadeinout(s,start,tin,dur,tout){
-	let time_in = Param(0.0,"fade_in",0..=f64::MAX);
+	let end = start+dur
-	let time_out = Param(0.0,"fade_out",0..=f64::MAX);
+	if now < start | now > end | tin<=0 | tout <= 0{
-	//クロージャとして値を閉じ込める
+		0
-	let new_generator = |s| apply_fadeinout(s,time_in,time_out);
+	}else{
-	Region{
+		let gain_s = min(max(now - start,0)/tin ,1)
-		start:origin.start,
+		let gain_e = min(max(end - now,0)/tout,1)
-		dur:origin.dur,
+		s*gain_s*gain_e // gain_sとgain_eはどちらから0~1の区間もう片方が1
-		content: compose(origin.content,new_generator)//この辺がよくわからん
 	}
 }
+fn finout_generator(s,start,dur){
+	//パラメーターはステージ１では単なる変数参照になる
+	let time_in = Param!(0.0,"fade_in",0..=f64::MAX);
+	let time_out = Param!(0.0,"fade_out",0..=f64::MAX);
+	apply_fadeinout(s,start,time_in,dur, time_out)
+}
+fn fade_inout(origin:Region)-> 'Region{
+	region_transformer(origin,finout_generator)
+}
+...
+fade_inout!(some_region)
 ```
 
 ### リージョンに対するリバース
 
 ```rust
 fn reverse(origin:Region)->Region{
-	//クロージャとして値を閉じ込める
+	let new_cache = origin |> render
-	let mut new_cache = vec![0;origin.get_dur_in_samples()*origin.channeks];
+	//クロージャとして値new_cacheを閉じ込める
-	origin.render(new_cache);
+	let new_generator = |s,start,dur| {//実際にはsは使わない
-	let new_generator = |s| ;
+	//s is not used
-	Region{
+		let index =  dur - start - now
-		start:origin.start,
+		new_cache[index]
-		dur:origin.dur,
+	}
-		content: compose(origin.content,new_generator)//この辺がよくわからん
+	region_transformer(origin,new_generator)
+}
+...
+some_region |> reverse!(_) |> fade_inout!(_)
+```
+
+## トラックの中で別のトラックの信号を参照する
+
+```rust
+fn phasor(freq){
+  self+freq/samplerate % 1.0
+}
+fn sinosc(freq,amp){
+  phase*TWOPI |> sin
+}
+// --ここから上はstage 1 value
+
+//track_1はstage0として参照する
+let track1:`()->float = Track(|| phasor(1.0)|> scale(_,0.0,1.0,100,4000))
+
+//track1をfrequencyとして参照することにする
+
+let r1 = LiveRegion({
+   start: 100ms,
+   dur: 1000ms,
+   content: || sinosc($track1(), 1.0)
+})
+
+let regions = [r1,r2,...]//regionの列はstage0のvalue
+
+let track3 = track_regions(regions)
+
+```
+
+- リージョンの移動に応じて生成される波形が変わるみたいなこともできるようになる
+- ただ実行時のトラックのサンプルに依存すると、
+	- サムネイルの生成のために全てのトラックを一度走査するみたいな必要は出てくる
+	- これに対するリバースとか定義できなくない？
+- リージョンの書き込み＝ステージ0評価ということにするならば、ステージ0でもselfなど状態関数使える必要あり
+- リージョンを、他のトラックを参照するLiveRegionとそうでないものに分けるとか？
+- あるステージ0関数を評価するとステージ1配列を返すrender_lift関数のようなものを考える
+
+```rust
+fn render_lift(content:()->float,time:float)->`[float]{
+	...
+}
+```
+
+
+## トラックのランタイム構造
+
+```rust
+let content = `{ phasor(Param!("freq",20,20000)) } 
+
+
+fn Track(name:string, content:()->`float)->`float{
+	`{
+		//stack is cleared and new track ui is placed on top of the stack	
+		 $content() |> probe_to_track!(name,_)
 	 }
 }
 
+fn master(tracks:[`float])->`float{
+	Track!("master", `{  lift_array(map(tracks,|t| $t ) ) |> sum })
+}
+let dsp = master([t1,t2,t3...])
+
 ```
 
+Trackの中でSliderとかが呼び出されると、そのスライダーはトラック内のパラメーターに属していて欲しいが、引数は内側から評価されてしまう=sliderの評価の方が先に来てしまう
+
+UIツリー系の評価は、
+
+- 個別のパラメーターを評価時Stackに積むような処理
+- TrackやリージョンではStackを消費しグループ化して自分のデータを構築(data::Trackの方)、トラックのUIを配置してStackに積む
+- トップレベルでスタックを全て消費しUIをプロジェクト全体のUI構築
+
+UI系の関数は全てサンク（レベル0）を受けて遅延評価するようなものでないとNG
+
+
+## 最低限必要になるUI類
+
+```
+Project
+Track
+Clip
+Slider
+Checkbox
+```
+
+Trackの直下でTrackが呼ばれた場合、フォルダトラックとしてネストされることになる、、、とか
+
+これ、たとえばClipはTrackの下かClipの下かのいずれかでしか使えないっつーことになるのでなんか新たに型システムで縛れる気がしてきたなあ
+
+Sliderが呼び出された時、初期値を変数参照にするのはあんまり意味がないことになる（リテラルで固定して、それを双方向プログラムしたい）
+
+一個ずつ順番に考えていこう
+
+```rust
+`{
+let phasor = | | (self+1.0)% 44100 
+let dsp:()->float = Project!("test project ",`| | {
+        let gain = Slider!("gain",`0.5,0.0,1.0)
+        sin(440*3.1415 * 2*phasor() /samplerate) *gain
+    })
+}
+```
+
+これがコンパイル通るところまではいける
+
+ExprNodeIdをオーディオスレッドで直接参照してはいけない（session_globalsがスレッドローカルなので参照ができない）
+
+リテラルの値を`Arc<atomic::F64>`でパースして、それを引き回す
+
+Sliderの値はProbeIdのようにインデックス参照したいので、そのストレージを何処で保持するか問題
+
+SystemPluginは本来スレッドを超えて共有できない状態を共有できてしまう（vmが走っているオーディオスレッドからメインスレッドの値にアクセスしてしまっている）
+
+そうすると状態共有でArcを使用する意味があんまりない
+
+
+
+## トラックの追加やリージョンの追加のアクション
+
+要するにUndo可能なアクション
+
+- 最悪、テキストに関してはdiff取って保存しておけば良いんでは
+- 「新規トラックの追加」みたいなアクションをどうするか
+- GUIのViewモデルからシンタックスツリーに戻すことはできない（マクロ展開後の結果だから）
+- Projectに与える配列に対してNodeの参照を持っていればなんとかなるか？
+- 
+
+
+
 ### 他
 
 - ドラッグしてるオブジェクトのスナップ対象は例えばCubaseなら固定のグリッドor既存のイベントorその両方とかだけど、例えばグリッドをジェネラティブに生成できる
@@ -123,6 +294,7 @@ fn reverse(origin:Region)->Region{
 	- 再生前（prepareToPlay)
 	- 信号再生時（process）
 
+
 ## 多段階計算と組み合わせる
 
 [[mimiumの多段階計算]]で、それなりに多段階計算の実装が間に合ってきた。
@@ -207,3 +379,14 @@ id_arenaのIDが128bitである限りちょっと厳しそう
 
 コンパイラのContextをアプリ中で引き回さなくちゃいけなくなるのがやだなー
 少なくともこれやるとマルチスレッドはめっちゃ難しくなるな
+
+名前があんまり気に入ってない
+
+mimeme(MInimal Musical Environment for Manual Editing)
+
+---
+
+[[PureData]]なみのミニマルな部分からの作り込みというのができない（静的型付けだからか？）
+
+
+

content/コードとデザイン 授業設計の覚書.md

@@ -0,0 +1,89 @@
+#writings 
+
+※この文章は、AMC JOURNAL（東京藝術大学芸術情報センター紀要）2025への掲載を目的として執筆する草稿である。
+
+## Abstract
+
+本稿は、2023年度から2025にかけて実施されたAMC開設授業「コードとデザイン」（前期金曜4・5限）の授業設計および実施記録である。本授業は、美術・音楽を専門とする学生を対象とした電子工作とプログラミングの知識習得を中心とした演習授業である。本授業ではその知識習得過程自体をパーソナル・パーソナルコンピューティング：誰もがコンピューターをただ使うだけでなく、自分（たち）のための計算機を自らの手で作れる技術環境づくりのひとつと位置づけ、電子計算機の原理や歴史的発展にも時間を割いている。
+本稿では、その授業設計の背景や、カリキュラムの具体的な内容を記述した上で、改善しうる点について述べる。
+
+## はじめに
+
+本稿では、2023年度から2025年度にかけて筆者が担当したAMC開設授業「コードとデザイン」の授業設計とその反省について記述する。
+
+本稿の第一の目的は、近しい領域における授業の実施を検討している教員への参照点を示すことだ。
+
+本授業の設計でも大きな参考とした"Code as Creative Medium"においても、デザイナーやアーティストがプログラミングやコンピューティングを学ぶためのリソースはあっても、それを教える人のための指針やドキュメントは多くない。
+
+- 授業の設計の参考資料が存在しないこと
+	- アメリカとかでは人文系、芸術系でも教員個人のWebサイトにシラバスや参考資料がまとめてあることが少なくない
+
+## 背景
+
+2022年度以前から芸術情報センターで「コードとデザイン」はデザイン科共催授業を基にして継続的に実施されてきた。内容としてはArduinoの使用方法やレーザーカッターを用いた造形のような、アーティストとして役に立つプログラミング、電子工作、デジタルファブリケーションの知識の習得を目指すものであった。2022年度後半に、それ以前授業を担当していたデザイン科の鈴木太朗教授との相談の上、基本的な目的は維持したうえで新たにゼロから授業を設計することになった。
+
+授業設計上の制約としては、まずあらかじめ決まっている時間の長さ（90分×2コマx15回）がある。また、他のAMC開設授業の中には映像表現、音楽等を取り扱う授業はあるものの、電子工作のようなハードウェア要素の強い授業は他にないため、全体のバランスとしてハードウェアの取り扱いを中心に据える必要もある。
+
+さらに特徴的な制約としては、想定される対象履修者の幅広さがある。芸術情報センターには直接学生が所属せず、美術、音楽、映像問わず全学科の学生が任意で芸術情報センター開設授業を履修できる。学部1年生から大学院博士課程まで履修する可能性がある。それゆえ全くプログラミングをしたこともない学生、Arduinoだけは軽く触ったことのある人、既にモーターなどを使用した工作の経験まである人など、前提知識には例年大きなばらつきがある。また技術的な知識の差ほかにも、芸術学科、楽理科や音楽環境創造科の学生のように、必ずしも作品制作を主軸に置かない学生も存在するため、それぞれの目的意識にも広がりがある。
+
+### 授業設計の指針
+
+授業全体の副題を「パーソナル・パーソナルコンピューターをつくる」と設定した。
+
+授業を設計するにあたって意識的に行ったことの一つが、既存の授業資料やワークショップを積極的に活用することである。特に、前半の授業は筆者が2018年に参加したニューヨークのアーティスト・ラン・スクールであるSchool for Poetic Computation（SFPC）のカリキュラムである。
+
+
+## 到達目標の設定
+
+パーソナル・パーソナルコンピューターをつくる
+
+最終課題の自由度
+
+- 完全自由制作
+	- 他の授業における前期の課題制作に、授業で学んだ要素が生かされているならば重複してもよい
+- 授業内小課題（後述）の発展
+
+全員が作品制作を最終ゴールとしていないこと。作品そのものではなく自分の製作に役に立つツールを制作する
+
+AMC解説の演習授業は必ずしも卒業要件に関わらない自由科目として選択されることも少なくないため、最終課題制作期間に自分の専攻の課題制作が重なることで忙しくなり、履修を継続できなくなることが往々にしてあることへの配慮である。
+
+
+## カリキュラム
+
+シラバスより転用
+
+1. Conditional Design Workshop
+2. Victorian Synthesizer/ Tympanic Alley
+3. インバーターの製作
+4. 2進数カードゲーム（浦川通）
+5. NAND回路と全加算器
+6. Arduino基礎
+7. 秋葉原に買い物
+8. 雑マウス
+9. Processingとの連携/ピンポンゲーム
+10. サウンド
+11. モーター
+12. 課題制作打ち合わせ
+13. デジタルファブリケーション（手作り電子部品）
+14. 課題制作打ち合わせ2
+15. 最終課題発表
+
+## 前半
+
+デザインとは？：Conditional Design Workshop
+
+脱電子工作入門：Victorian Synthesizer/ Tympanic Alley
+
+Handmade Computer(3,5回)
+
+バイナリーカードゲーム
+
+## 後半：Arduinoの実用
+
+Arduinoの選定
+
+Leronardoか、Arduino Uno R4
+
+これらだとUSB HIDエミュレートができる
+
+ただし、ADCToucｈなど普通のライブラリで使えるものが使えなくなる

content/パーサジェネレータ.md

@@ -0,0 +1,4 @@
+---
+date: 2025-09-17 09:55
+---
+#stub

content/加藤淳.md

@@ -0,0 +1,4 @@
+---
+date: 2025-09-05 12:23
+---
+#stub

content/太陽電池ピックアップ.md

@@ -0,0 +1,11 @@
+---
+date: 2025-08-29 10:33
+---
+#memo 
+
+[[關於]]のYoutubeのチュートリアルより。
+
+[DIY Electronic Sounds｜Ep.5 – 化光為聲：太陽能板拾音器 - YouTube](https://www.youtube.com/watch?v=Q3qb_d3XKNI)
+
+
+[[色素増感太陽電池]]でもできるかな？

content/文脈様相型理論.md

@@ -0,0 +1,10 @@
+---
+date: 2025-09-09 17:08
+---
+#programming 
+
+[[Contextural Modal Type Theory]]
+
+[[メタプログラミング]]や[[多段階計算]]に近しいやつ（らしい）
+
+[tocl07.pdf](https://www.cs.cmu.edu/~fp/papers/tocl07.pdf)

content/關於.md

@@ -0,0 +1,5 @@
+---
+date: 2025-08-29 10:32
+---
+#person 
+