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

content/.obsidian/core-plugins.json

@@ -27,5 +27,7 @@
   "publish": false,
   "sync": false,
   "properties": true,
-  "webviewer": false
+  "webviewer": false,
+  "footnotes": false,
+  "bases": true
 }

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/Caddy.md

@@ -0,0 +1,4 @@
+---
+date: 2025-08-20 18:45
+---
+#stub

content/ChucK.md

@@ -9,13 +9,16 @@ Strongly-Timedというコンセプトの音楽プログラミング言語。[[G
 
 C言語っぽいシンタックスでサンプル単位での正確なスケジューリングができるのが特徴。
 
-命令型＋クラスを作ったりのオブジェクト指向（継承もあり）。
+命令型＋クラスを作ったりのオブジェクト指向（継承もあり）。`=>`でUGenの接続を表したり、代入したりと複数の機能を持つChucK演算子が存在するのがユニーク。
+
+`now`に対してChucK演算子で`1::second => now;`みたいな命令をすることが、1秒スリープするという動作に相当する、独特の時間操作を持つ。
+
 
 shredという論理時間ベースの計量スレッドみたいなものを言語内からスポーン、もしくはコマンドから立ち上げることができる。1つのファイルをスレッド単位で立ち上げたり殺したりをリアルタイムで切り替えることで、[[ライブコーディング]]を実現している（ただし更新のタイミングでディレイやリバーブのテールは切れる）。
 
 最近も活発に更新が進んでいて、モジュール機能などが導入された。
 
-もともとはオーディオビジュアル的なライブコーディング環境Audicleというのがあり、それを簡略化したminiAudicleというのがメインのIDEとして使われている。
+もともとはオーディオビジュアル的なライブコーディング環境Audicleというのがあり、それを簡略化した[[miniAudicle]]というのがメインのIDEとして使われている。
 
 最近は[[Emscripten]]でWeb経由でも動くようになってきた。
 
@@ -24,3 +27,5 @@ shredという論理時間ベースの計量スレッドみたいなものを言
 また、Chugin(チャグイン)というC++で書かれたネイティブな拡張を読み込むこともでき、[[Faust]]や[[TouchDesigner]]、[[Unity]]のような他の環境との連携も多く実現しているほか、AI系などのプラグインも開発されている。
 
 Chugenという独自[[Unit Generator|UGen]]をChucK言語上で定義するための機能もある（[[Csound]]におけるUser-Defined OpCode）。
+
+パッケージマネージャが2025年ぐらいになって導入された。

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/Dioxus.md

@@ -0,0 +1,17 @@
+
+
+
+まだ開発中だけど[[Blitz]]というRustで書かれた独自のネイティブHTMLレンダラの統合予定もあり
+
+アニメーションライブラリ
+
+[GitHub - wheregmis/dioxus-motion: A lightweight, cross-platform animation library for Dioxus, designed to bring smooth, flexible animations to your Rust web, desktop, and mobile applications.](https://github.com/wheregmis/dioxus-motion?tab=readme-ov-file)
+
+グラフ描画ライブラリ（愚直にSVG生成で実装されてる）
+
+[GitHub - dioxus-community/dioxus-charts: A simple chart components library for Dioxus](https://github.com/dioxus-community/dioxus-charts)
+
+
+Rustで書かれたUIでも高速ホットリロードができるとか（どうやってるんだ）
+
+[\[media\] Dioxus Subsecond Rust Hotpatch Engine + Ratatui ❤️ : r/rust](https://www.reddit.com/r/rust/comments/1j8z3yb/media_dioxus_subsecond_rust_hotpatch_engine/)

content/Dynamic Macro.md

@@ -0,0 +1,33 @@
+---
+date: 2025-08-21 11:55
+---
+[[増井俊之]]が考案した、キーボード入力の履歴の中から繰り返し動作を自動で検出して再実行できるようにする仕組み
+
+[Dynamic Macro - 増井俊之](https://scrapbox.io/masui/Dynamic_Macro)
+
+実装が非常にシンプル。[[Atom]]用拡張機能の実装がわかりやすい
+
+[atom-dynamic-macro/lib/atom-dynamic-macro.coffee at f050cac0d19eaac20ef2e5ff8092a9f5242cf481 · masui/atom-dynamic-macro · GitHub](https://github.com/masui/atom-dynamic-macro/blob/f050cac0d19eaac20ef2e5ff8092a9f5242cf481/lib/atom-dynamic-macro.coffee#L30C1-L47C8)
+
+```coffeescript
+  #
+  # Detect repeated elements at the end of an array
+  #
+  # findRep [1,2,3]                     # => []
+  # findRep [1,2,3,3]                   # => [3]
+  # findRep [1,2,3,1,2,3]               # => [1,2,3]
+  # findRep [1,2,3,3,1,2,3,3]           # => [1,2,3,3]
+  # findRep [1,2,3], (x,y) -> x+1 == y  # => [3]
+  #
+  findRep: (a,compare) ->
+    compare = compare ? (x,y) -> x == y
+    len = a.length
+    res = []
+    for i in [0...len/2]
+      for j in [0..i]
+        break unless compare(a[len-2-i-j], a[len-1-j])
+      res = a[len-j..len-1] if i == j-1
+    res
+```
+
+配列を二分探索して、一番長い要素を検出？

content/Elm.md

@@ -0,0 +1 @@
+#programming-language 

content/Erlang.md

@@ -0,0 +1,2 @@
+#programming-language 
+

content/Gitea Actionsとrsync、Caddyで静的サイトをホストする.md

@@ -3,11 +3,13 @@ date: "2024-02-05T12:26:59+0900"
 ---
 #self-hosted #server #tips
 
-Giteaは最近Actionが使えるようになった。Dockerで別にランナーマシンを立ち上げる必要があるほか、GitHub Actionsと比べると、Concurrencyなどちゃんと効かなかったり色々まだ機能が足りてない所はある。
+[[Gitea]]は最近Actionが使えるようになった。Dockerで別にランナーマシンを立ち上げる必要があるほか、GitHub Actionsと比べると、Concurrencyなどちゃんと効かなかったり色々まだ機能が足りてない所はある。
 
 ただ、公開されてるGithubs Actionはそのままuseできるのが強い。`actions/cache@v3`の代わりに`https://github.com/actions/cache@v3`のようにURLで指定できる。よく使うアクションはgitea側にもミラーされていることもあるが、なんか放置されてるやつも多々あるので注意。
 
-Pagesの機能がないため、別途サーバーを立ち上げてrsyncで同期するくらいしか方法がない。そこそこ設定は面倒くさいが、nginxよりさらに簡易的に動かせるgo製のWebサーバーCaddyを使ってなんとかすることにした。
+Pagesの機能がないため、別途サーバーを立ち上げてrsyncで同期するくらいしか方法がない。そこそこ設定は面倒くさいが、nginxよりさらに簡易的に動かせるgo製のWebサーバー[[Caddy]]を使ってなんとかすることにした。
+
+[[Cloudflare Pages]]でいいならそっちの方がBranch Previewもできるので多分圧倒的に楽。
 
 ## 下準備
 
@@ -20,7 +22,6 @@ ssh-keygen -t ed25519
 ファイル名は`rsync_webserver`と`rsync_webserver.pub`とかにしておく
 
 
-
 ## Caddyサーバー側の構成
 
 [tomoyanonymous/Caddy\_rsync\_webserver - Caddy\_rsync\_webserver - Tomoya Matsuura Gitea](https://git.matsuuratomoya.com/tomoyanonymous/Caddy_rsync_webserver)
@@ -120,7 +121,10 @@ Action RunnerつきでGiteaを立ち上げるところまでは省略。
 - WEBSERVER_PORT （Caddyが立ち上がっているサーバーのSSH用ポート、上の例では25222）
 - WEBSERVER_USER ：root（これあんまり良くないのかな）
 
-で、リポジトリに`/.gitea/workflows/ci.yaml`を作る。[Gitea Actionsの`ubuntu-latest`ラベルのランナーはデフォルトでDebianベースの`node:16-bullseye`のDockerイメージのエイリアス](https://docs.gitea.com/usage/actions/act-runner#labels)で（これまじでややこしい）、QuartzはNode18以降でないと動かない。またGoも入ってないので入れる。
+で、リポジトリに`/.gitea/workflows/ci.yaml`を作る。[Gitea Actionsの`ubuntu-latest`ラベルのランナーはデフォルトでDebianベースの`node:16-bullseye`のDockerイメージのエイリアス](https://docs.gitea.com/usage/actions/act-runner#labels)で（これまじでややこしい）、QuartzはNode18以降でないと動かない。
+
+GIteaの難点として、Github Actionsではデフォルトで使える`hashFiles()`関数が使えない。代わりに、`go-hashfiles`というアクションを使う必要がある。QuartzはGo非依存になったのだが、これがあるのでビルド側でもまだgoをインストールする必要がある。
+
 
 ```yml
 name: Build

content/Gitea.md

@@ -0,0 +1,4 @@
+---
+date: 2025-08-20 18:36
+---
+#software

content/Gream.md

@@ -0,0 +1,28 @@
+#programming-language 
+
+[[Rust]]っぽいシンタックスだが、[[Erlang]]の[[BEAM VM]]もしくは[[JavaScript]]をターゲットとして　コンパイルされるスクリプティング言語。
+
+
+Use構文が面白い。ちょっと[[Computation Expression]]でSeqを使った時とか、[[Koka]]のWith構文と似た仕組みと見える
+[Use - The Gleam Language Tour](https://tour.gleam.run/advanced-features/use/)
+
+```rust
+pub fn with_use() -> Result(String, Nil) {
+  use username <- result.try(get_username())
+  use password <- result.try(get_password())
+  use greeting <- result.map(log_in(username, password))
+  greeting <> ", " <> username
+}
+
+pub fn without_use() -> Result(String, Nil) {
+  result.try(get_username(), fn(username) {
+    result.try(get_password(), fn(password) {
+      result.map(log_in(username, password), fn(greeting) {
+        greeting <> ", " <> username
+      })
+    })
+  })
+}
+```
+
+ 

content/Gwion.md

@@ -3,7 +3,7 @@ date: 2025-01-15 15:30
 ---
 #programming-language #computermusic 
 
-[[ChucK]]に影響を受けた言語。サンプル精度のスケジューリングに加えてtagged unionとかテンプレートとかラムダ式とか使える
+[[ChucK]]に影響を受けた[[音楽プログラミング言語]]。サンプル精度のスケジューリングに加えてtagged unionとかテンプレートとかラムダ式とか使える。ChucKオペレータも健在
 
 [Welcome to Gwion - Gwion](https://gwion.github.io/Gwion/)
 

content/JavaScript.md

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

content/Koka.md

@@ -0,0 +1,19 @@
+#programming-language 
+
+[The Koka Programming Language](https://koka-lang.github.io/koka/doc/index.html)
+
+[[MicroSoft]]のチームが研究しているプログラミング言語。
+
+名前（KOKA＝効果）のとおり、[[代数的エフェクト]]が明示的な組み込みシンタックスで扱える。
+
+中括弧の囲みをインデントで代用できて、JSっぽくもPythonっぽくも書ける。シンタックス的に推測できれば無名関数を省略して書けたりと、かなり構文糖衣が積極的に使われている。
+
+
+With構文が面白い。[[Haskell]]のIOモナドで`<-`をチェーンしていくようなやつが、単に高階関数を受け取る関数の順番を入れ替える構文として実装されてるので、ネストが深くなっていくのを避けられる。
+
+```koka
+with x <- f(e1,...,eN)
+<body>
+//equal to 
+f(e1,...,eN, fn(){ <body> })
+```

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/Moonbit.md

@@ -0,0 +1,18 @@
+#programming-language 
+
+[[Rust]]っぽい構文とシステムから、メモリ管理だけはGCに任せて[[WebAssembly]]ファーストな言語を設計してみましたみたいなやつ
+
+[MoonBit](https://www.moonbitlang.com/)
+
+
+現状のコンパイラは[[OCaml]]で書かれてるっぽい。
+
+[GitHub - moonbitlang/moonbit-compiler](https://github.com/moonbitlang/moonbit-compiler)
+
+
+> 元 Meta で BuckleScript | [[ReScript]] を開発していた [[Hongbo Zhang]] 氏がチーフアーキテクト。
+
+[自分が Moonbit 言語について知っていること](https://zenn.dev/mizchi/articles/practical-moonbit)
+
+あ、そうなんだ
+

content/PAW.md

@@ -0,0 +1,31 @@
+---
+date: 2025-08-21 15:04
+---
+#software 
+
+[[Xavier Lambein]]による、[[双方向プログラミング]]の考え方を[[DAW]]に導入したソフトウェア。
+
+[PAW: a programmable and visual audio workstation (submission to LIVE  2023) — Xavier Lambein's website](https://lambein.xyz/paw-live2023/)
+
+
+[[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/Quartz.md

@@ -55,4 +55,5 @@ https://quartz.jzhao.xyz/migrating-from-Quartz-3
 beforeBody: [Component.ArticleTitle(), Component.ContentMeta(),/*Component.TagList()*/],
 ```
 
-このレイアウトの仕組みよくできてんなー
+- v4.5でOGPイメージの自動生成機能がついた。
+	- 今はデフォルトでオンになっているが、[[Satori]]というJSでHTMLをSVGに変換しWebPまで変換してくれるモジュールを使うみたい。これがまだキャッシングの仕組みなどないみたいで結構重い。

content/Rhai.md

@@ -0,0 +1,6 @@
+#programming-language 
+
+[[Rust]]で、かつRust言語のいいところを取り込んだ[[Lua]]みたいな埋め込みやすい言語を作ってみたらこうなる、みたいなやつ
+
+
+[Rhai – Embedded Scripting for Rust](https://rhai.rs/)

content/Rust.md

@@ -2,3 +2,15 @@
 date: "2023-09-01T19:08:25+0900"
 ---
 #tools #software 
+
+
+## Rustから影響受けたっぽいスクリプティング言語
+
+- [[Gluon]]
+- [[Rune]]
+- [[Rhai]]
+- [[Moonbit]]
+- [[Gream]]
+- [[Ad-Astra]]
+
+[[RustでGUIを作る選択肢]]

content/RustでGUIを作る選択肢.md

@@ -0,0 +1,26 @@
+
+## [[egui]]
+
+[[otopoiesis]]で使ってる。[[ImGui]]から影響を受けたimmediate GUI。WebAssemblyでもきちんと動作する（全部を一つのcanvasにレンダリングする。DOMの扱いは無理）
+
+
+## [[iced]]
+
+[[Elm]] のアーキテクチャに影響を受けたライブラリ。
+
+マルチバイト文字非対応
+
+
+## [[Tauri]]
+
+Webviewベースで、フロントエンドはJSやTypeScriptで書くという、[[Electron]]のような構成のデスクトップアプリを作れるフレームワーク
+
+生のCanvasを触ることもできる
+
+## [[Dioxus]]
+
+フロントエンドも含めてRustで完結するWebviewベースのライブラリ。
+
+こちらは生Canvas触れないのがつらい
+
+Dioxusでつくっていって、サムネイルとか必要ならWeb-sysでCanvas動かせばそれでいいのかな

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

@@ -10,7 +10,12 @@
 - 操作的意味論的にもある程度一貫性がある
 - モジュール内ではシンボルの相互参照が可能（後から定義されるシンボルでも参照可能）
 
-で、デザインチョイスのトレードオフとしては意味論を楽にしようと思うと分割コンパイルがめんどくさくなる
+分割コンパイルができるということは、依存するファイルを毎回コンパイルしないでも、型情報のキャッシュが残ってれば再利用できるということ
+
+バラバラのMIRとしてコンパイルできて、関数や定数はmonomorphizeされたユニークな名前：値の対応関係が1:1で付く
+
+
+デザインチョイスのトレードオフとしては意味論を楽にしようと思うと分割コンパイルがめんどくさくなる
 
 複数のコードを合体させるときに、流用されるコードの複製が増える問題
 
@@ -42,7 +47,8 @@ mod modname{//ソースファイルと同じ宣言
 ```
 
 ```rust
-mod(stage-1){//ステージの変更
+mod modname{//ステージの変更
+@stage = macro
    //
 }
 ```

content/mimiumのレコード型.md

@@ -13,7 +13,7 @@ date: 2025-07-02 11:40
 
 ## 基本構文
 
-構文のベースは [Elm](https://elm-lang.org/docs/records) である。この部分だけは Rust 風にはしない。
+構文のベースは [[Elm]] である。この部分だけは Rust 風にはしない。
 
 匿名レコード型を正の文脈で使う。
 

content/mimiumの多段階計算.md

@@ -121,6 +121,7 @@ ${
 
 この、最後に閉じ括弧が溜まっていく形にしない限り、yはxを参照できなくなってしまう
 
+→ステージは[[mimiumのモジュールシステム|モジュール]]単位で変更していくほうが都合がよさそう。
+
 
-ステージ表記は相対表記がいいのかしら
 

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,4 @@
+---
+date: 2025-08-21 15:05
+---
+#stub

content/増井俊之.md

@@ -0,0 +1,4 @@
+---
+date: 2025-08-21 11:55
+---
+#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 
+