[obsidian] vault backup: 2025-08-01 13:05:00[

content/.obsidian/graph.json

@@ -60,6 +60,6 @@
   "repelStrength": 15.1642583672965,
   "linkStrength": 0.975453871804372,
   "linkDistance": 42,
-  "scale": 0.7322130672951164,
+  "scale": 0.31674920955833996,
   "close": true
 }

content/.obsidian/plugins/obsidian-git/manifest.json

@@ -6,5 +6,5 @@
     "description": "Integrate Git version control with automatic backup and other advanced features.",
     "isDesktopOnly": false,
     "fundingUrl": "https://ko-fi.com/vinzent",
-    "version": "2.25.0"
+    "version": "2.33.0"
 }

content/.obsidian/plugins/obsidian-git/styles.css

@@ -39,6 +39,10 @@
     margin-right: auto;
 }
 
+.obsidian-git-disabled {
+    opacity: 0.5;
+}
+
 .obsidian-git-center-button {
     display: block;
     margin: 20px auto;
@@ -560,3 +564,42 @@
         display: none;
     }
 }
+
+.git-unified-diff-view,
+.git-split-diff-view .cm-deletedLine .cm-changedText {
+    background-color: #ee443330;
+}
+
+.git-unified-diff-view,
+.git-split-diff-view .cm-insertedLine .cm-changedText {
+    background-color: #22bb2230;
+}
+
+/* Limits the scrollbar to the view body */
+.git-view {
+    display: flex;
+    flex-direction: column;
+    position: relative;
+    height: 100%;
+}
+
+.git-obscure-prompt[git-is-obscured="true"] #git-show-password:after {
+    -webkit-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="svg-icon lucide-eye"><path d="M2.062 12.348a1 1 0 0 1 0-.696 10.75 10.75 0 0 1 19.876 0 1 1 0 0 1 0 .696 10.75 10.75 0 0 1-19.876 0"></path><circle cx="12" cy="12" r="3"></circle></svg>');
+}
+
+.git-obscure-prompt[git-is-obscured="false"] #git-show-password:after {
+    -webkit-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="svg-icon lucide-eye-off"><path d="M10.733 5.076a10.744 10.744 0 0 1 11.205 6.575 1 1 0 0 1 0 .696 10.747 10.747 0 0 1-1.444 2.49"></path><path d="M14.084 14.158a3 3 0 0 1-4.242-4.242"></path><path d="M17.479 17.499a10.75 10.75 0 0 1-15.417-5.151 1 1 0 0 1 0-.696 10.75 10.75 0 0 1 4.446-5.143"></path><path d="m2 2 20 20"></path></svg>');
+}
+
+/* Override styling of Codemirror merge view "collapsed lines" indicator */
+.git-split-diff-view .ͼ2 .cm-collapsedLines {
+    background: var(--interactive-normal);
+    border-radius: var(--radius-m);
+    color: var(--text-accent);
+    font-size: var(--font-small);
+    padding: var(--size-4-1) var(--size-4-1);
+}
+.git-split-diff-view .ͼ2 .cm-collapsedLines:hover {
+    background: var(--interactive-hover);
+    color: var(--text-accent-hover);
+}

content/Andrew McPherson.md

@@ -0,0 +1,10 @@
+---
+date: 2025-06-14 09:40
+---
+#person
+
+Augmented Instrument Lab
+
+https://instrumentslab.org/
+
+

content/Arco.md

@@ -0,0 +1,33 @@
+---
+date: 2025-06-12 09:29
+---
+#computermusic #programming-language 
+
+[[Nyquist]]を作った[[Roger Dannenberg]]が開発している音楽プログラミング向けの中間表現。
+
+[GitHub - rbdannenberg/arco](https://github.com/rbdannenberg/arco)
+
+[[SuperCollider]]のようにクライアント-サーバーモデルで動作し、scsynthに相当する部分がArco。sclangに相当する部分として、[[Serpent]]というPythonっぽいフロントエンド言語も用意されている。
+
+内部通信はOSCではなくO2というまた別のUDPの上に乗った汎用プロトコル。
+
+## メモ
+
+オーディオレートの処理でも、サンプルごとの処理のパターンと、ブロックレベルの処理の2種類がある。
+
+ブロックレベルの処理の場合は入力もブロック
+
+UGenは基本的に[[参照カウント]]GC
+
+ここが重要そう
+
+> ポイントは、入力信号の種類が非常に多様である点です。constant、block、audioレート入力に加え、単一チャンネルとマルチチャンネル信号の組み合わせにより、潜在的に6種類の入力タイプが存在します。入力数がNの場合、`real_run`のバリエーションは6^Nに及ぶ可能性があり、自動コード生成であっても管理が困難になります。
+> この問題を解決するために、2つの主要な戦略を採用しています。まず、入力と出力信号の複数チャンネルを反復処理するコードは、単一の`real_run`メソッドに実装されます。ただし、異なる種類の入力の処理は、`run_channel`メソッドを介した間接的なメソッド呼び出しにより個別化されています。run_channelは、対応するメソッドを指すメソッドです。例えば、`mult`では、2つのオーディオレートチャンネル（各々32浮動小数点数のベクトル）を乗算してオーディオレートチャンネルを生成する`chan_aa_a`メソッドと、オーディオレートチャンネルとブロックレートチャンネル（単一の浮動小数点数）を乗算する`chan_ab_a`メソッドがあります。変数`run_channel`は入力が変更されるたびに適切なメソッドに設定され、正しい個別化されたDSP計算が実行されます。
+
+> 2 番目の戦略では、入力チャンネルを反復処理するロジックを、`run_channel` を呼び出す前に各入力に対して 1 つの加算命令に削減します。したがって、オーバーヘッドは出力チャンネルの数 x 入力信号の数になります。これは、アクセスおよび計算されるデータの総量に比べて非常に小さいです。
+
+> 各 `run_channel` メソッドは、入力が入力ごとのサンプルポインタのアドレスから開始することを期待しています。ポインタは `run_channel`によって変更されることはありませんが、戻ると、サンプルポインタは入力ごとのストライド量だけインクリメントされます。シングルチャンネル入力の場合、各チャンネルで同じ入力を再利用したいので、ストライドは 0 です。マルチチャンネルオーディオ入力の場合、入力の次のチャンネルに進みたいので、ストライドは 2 です。入力と出力はメモリ内で連続しているため、ストライドはブロック長 (BL = 32) になります。マルチチャンネルのブロックレート入力の場合、1 ブロックにつき 1 サンプルしかないので、ストライドは 1 になります。最後に、定数入力 (メッセージによって更新できる値) は、ブロックレート信号と同じように扱われます。定数は、ストライドが 0 または 1 のシングルチャンネルまたはマルチチャンネルにすることができます。
+
+> これらの戦略により、オーディオレート入力とブロックレート入力に異なるコードが必要であるため、組み合わせは 6^N バージョンの内部計算ループから 2^N バージョンに減少します。一部の入力をオーディオレートに制限することで、これをさらに制限することができます。たとえば、ブロックレート信号にオーディオローパスフィルターを適用することはあまり意味がありません。
+
+[arco/doc/design.md at main · rbdannenberg/arco · GitHub](https://github.com/rbdannenberg/arco/blob/main/doc/design.md)

content/BibLaTeX.md

@@ -0,0 +1,26 @@
+---
+date: "2025-06-18T12:10:00+0900"
+---
+#research #tools
+
+学術論文や書籍の引用・参考文献を管理するためのLaTeX用パッケージ。従来のBibTeXの後継として開発された。
+
+## 特徴
+
+- Unicode対応
+- 多言語サポート
+- より柔軟な引用スタイル
+- より豊富なエントリータイプとフィールド
+- バックエンド処理にBiberを使用
+
+## 使用方法
+
+```latex
+\usepackage[style=authoryear]{biblatex}
+\addbibresource{references.bib}
+```
+
+## 関連ツール
+
+- [[Zotero]]：BibLaTeXフォーマットでの書誌情報エクスポートが可能
+- [[Pandoc]]：Markdownから引用情報を含めたLaTeX/PDF変換に対応

content/CERN Open Hardware License.md

@@ -0,0 +1,7 @@
+---
+date: 2025-06-12 10:02
+---
+#stub 
+
+[Home | CERN Open Hardware Licence](https://cern-ohl.web.cern.ch/home)
+

content/Coq.md

@@ -1,6 +1,12 @@
 ---
 date: "2023-08-22T23:39:29+0900"
 ---
-#tools #software 
+#tools #software #programming-language #logic
 
-定理証明支援システム
+[[依存型]]に基づいた定理証明支援システム。フランス[[INRIA]]で開発され、プログラムの正当性証明に使用される。
+
+[[Coqの勉強]]で学習リソースを整理している。
+
+### 関連研究者
+
+- [[Emilio Jesús Gallego Arias]] - [[Faust]]の形式的証明プロジェクトに関わっている

content/DIPS.md

@@ -0,0 +1,16 @@
+---
+date: 2025-06-14 10:27
+---
+#programming 
+
+[[莱孝之]] [[松田周]] らによって作成
+
+[DIPS for Max](https://dips.kcm-sd.ac.jp/)
+
+[[Max]]のビジュアライズ関連のパッケージ
+
+[Digital Image Processing with Sound - Wikipedia](https://en.wikipedia.org/wiki/Digital_Image_Processing_with_Sound)
+
+[[Jitter]]が出る前にOpenGLとダイレクトに繋ぐパッケージだったのかな
+
+[Max/MSP/DIPS – Akihiko Matsumoto Blog](https://akihikomatsumoto.com/blog/?p=442)

content/Entity Component System.md

@@ -0,0 +1,23 @@
+#programming 
+
+
+主にゲームエンジンなどで採用されるプログラミングのパラダイム。
+
+最近のUnityでも内部的に採用されている。
+
+[[Rust]]だと[[Bevy]]が有名。
+
+[[オブジェクト指向]]と比べると、データのメモリ分布が、オブジェクトごとに並ぶのではなく個別のメンバー変数ごとに並ぶことになり、CPUのメモリキャッシュに乗りやすいなどの利点がある。
+
+[\[Rust\] ECSアーキテクチャ \[bevy\_ecs\] | DevelopersIO](https://dev.classmethod.jp/articles/ecs-rust-bevy/)
+
+[Intro to ECS - Unofficial Bevy Cheat Book](https://bevy-cheatbook.github.io/programming/ecs-intro.html)
+
+## データのモデリング方法としてなにがうれしいのか
+
+オブジェクト指向と比べた時の利点が基本的にさっきのような、パフォーマンス面での利点が強調されることが多い。ただ、何かパフォーマンスのためにせっかくプログラミング言語が用意してくれたデータのモデリング技法を犠牲にしているような気がしてならず、あんまり旨味がよくわからなかった。
+
+ただ、Bevyの設計をいろいろ読んでいると、モデリングとしての核心は、「集合の中から特定の要素を持つもの部分集合を指定して挙動を個別に操作する（依存性がない操作同士はどういう順番で実行してもいい）」ということかなと思った。
+
+
+

content/Eric Lyon.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-11 14:05
+---
+#person #stub

content/Exidiophone.md

@@ -0,0 +1,15 @@
+---
+date: 2025-06-14 19:46
+---
+#instrument 
+
+https://matsuuratomoya.com/works/exidiophone
+
+
+止まっているバージョン4の構想を続けたい
+
+マイクを耳、光る部分を目だとして、2つのペアを同時に使って架空の生物みたいな見た目にしたら面白そう
+
+羽のある脊椎動物（宮崎アニメの何かの生物とかみたいな）
+
+

content/Faust.md

@@ -1,13 +1,13 @@
 ---
 date: "2023-08-22T23:39:29+0900"
 ---
-#software #programming-language #sound 
+#software #programming-language #sound #computermusic
 
 https://faust.grame.fr
 
-ブロックダイアグラム代数（Block-Diagram-Algebra:BDA）という独自の体系を基礎に置く信号処理記述に特化した言語。
+[[音楽プログラミング言語の形式化]]のプロジェクトで研究対象となっている言語の一つ。ブロックダイアグラム代数（Block-Diagram-Algebra:BDA）という独自の体系を基礎に置く信号処理記述に特化した言語。
 
-パターンマッチングによる項書きかえマクロを使うことでかなり複雑な信号処理を表現できる。
+パターンマッチングによる項書きかえマクロを使うことでかなり複雑な信号処理を表現できる。[[PureData]]や[[Max]]のようなビジュアルプログラミング言語とは異なり、テキストベースで記述する。
 
 文法が独特なのでかなり学習が難しい。
 

content/Francesco Cameli.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-20 12:51
+---
+#person 
+
+[vitreo12 (Francesco Cameli) · GitHub](https://github.com/vitreo12)
+
+[Embark Studios Open Source | embark.dev](https://embark.dev/)

content/Garnet Hertz.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-12 14:24
+---
+#person

content/Generative Justice.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-12 14:25
+---
+#notion 
+
+[The Center for Generative Justice](https://generativejustice.org/)
+
+

content/Gluon.md

@@ -0,0 +1,7 @@
+#programming-language 
+
+[[Rust]]で書かれた、[[Lua]]のような埋め込みを想定しつつ静的型付けの言語。
+
+モジュールの読み込みの文法とか複雑な型情報をRustと相互でやり取りする時のやりかたとか、参考になる
+
+[Gluon](https://gluon-lang.org/)

content/HackMD.md

@@ -0,0 +1,25 @@
+---
+date: "2025-06-18T12:35:00+0900"
+---
+#software #tools #note
+
+HackMDはMarkdownベースのコラボレーション文書作成プラットフォーム。
+
+https://hackmd.io/
+
+## 特徴
+
+- リアルタイム共同編集
+- 完全なMarkdown対応
+- 数式、図表、コードブロックなどの拡張記法
+- プレゼンテーションモード
+- 簡単な共有とアクセス管理
+
+## 使用例
+
+- 技術文書作成
+- 会議記録
+- 研究ノート
+- 講義資料
+
+[[この研究ノートについて]]の初期段階でも検討された選択肢の一つ。

content/Hackett.md

@@ -0,0 +1,9 @@
+#programming-language 
+
+[[Racket]]上で実装された、静的型付けなうえで、型安全なマクロシステムを搭載したプログラミング言語
+
+[1 The Hackett Guide](https://lexi-lambda.github.io/hackett/guide.html)
+
+["Hackett: a metaprogrammable Haskell" by Alexis King - YouTube](https://www.youtube.com/watch?v=5QQdI3P7MdY)
+
+

content/ICMC2025 ペーパーセッション聴講メモ.md

@@ -190,5 +190,376 @@ Chronotechnics
 
 全然AI関係なさそう、、なんで選ばれた？
 
+Netronomia
+
+[NetronomiaII by Ken Fields](https://rdmc.nottingham.ac.uk/handle/internal/11989)
+
+---
+
+## Then and now – Musical needs and Intelligent Tools
+
+[[Miriam Akkermann]]
+
+[[Research in music and artificial intelligence]] -- [[Curtis Roads]]
+
+More than imitation
+
+how should we evaluate the creativity of human-like and superhuman?
+
+how do we evaluate what is accomplished by the specific tools?
+
+need for new classification systems
+
+
+---
+
+## Anger at the Asteroid: From Exhibition to Ensemble Performance
+
+
+[[Courtney Brown]]
+
+恐竜の鳴き声をいろんな形で作り続けているっぽい
+
+[Rawr! A Study in Sonic Skulls: Embodied Natural History](https://www.nime.org/proc/cbrown2015/index.html)(2015のNIME)
+
+初期は人口声帯で作ってたけど途中でDSPに変えたのかな？
+
+[About – Dinosaur Choir](https://dino.courtney-brown.net/about/)
+
+Raspberrypi単品だとレイテンシーが微妙だった
+
+
+## Dynamic Generalized Parametric Control of Digital Music Instruments
+
+[[Eric Lyon]] Virginia University
+
+VSTのパラメーター補完（プリセット同士のinterpolation?）
+
+"preset is just one data point in the set of all possible sonic configurations"
+
+2つのプリセットだったらスライダーで変えればいいよね
+
+どんなVSTでも使える
+
+[[Max]]の`vst~`を使う
+
+補完はJSで実装
+
+それ以上ならlatent spaceの探索みたいな話？そうっぽい
+
+
+- Int.lib([[Oli Larkin]])
+- j74 Morph [f a b r i z i o p o c e | J 7 4](https://www.fabriziopoce.com/morph.html)
+- Arturia Polybruteにもそういう機能がある
+
+
+## Women’s Labor: Weaving it all Together
+
+[[Margaret Schedel]]
+
+domestic tools as musical instruments
+
+[[Bag theory]] : first human cultural product
+
+これまでやったこと：色をwekinatorで画像認識/重さセンサー
+
+Woven Scores
+
+phryamework 布と導電布でスピーカー作る
+
+create new community through workshop
+
+質問：アクティビズムでもあり、ハイテックでもある不思議な位置付けだけどどこが先に来たのか：そのまんま、コミッションのオーダーとしてNIMEとフェミニズムのテーマでなんかやるというのがあった
+
+
+## CAFFEINE: Collaborative Affordable Framework For Experiments in Interactive Networked Electronics
+
+[[Scott Petersen]] Yale University
+
+学部生の合同プロジェクトっぽい [[ソニフィケーション]]のためのシステム？
+
+ハード＋ソフトのフレームワーク
+
+caffeine pods 無線、バッテリー駆動
+
+many-pods one-broker many clients
+
+[[esp32-s3]]  devkit C 超音波距離センサー、Groveサウンドセンサー、光センサー
+
+ブローカーはPython、ソニフィケーションは[[SuperCollider]]
+
+
+## A Real-Time Gesture-Based Control Framework
+
+MaxとPythonの相性悪い問題（とはいえここでもPythonとOSCで連携してるらしい）
+
+ジェスチャー認識をMaxでもやりたい
+
+- Rapidmax
+- MuBu
+- Gimlet
+- Gestural Sound Tolkit
+
+[[MediaPipe]]使ったらしい
+
+リアルタイム・フルボディ
+
+[[Wekinator]]みたくオンライン学習できるのが強み
+
+## Arco : A Flexible Audio Processing Framework
+
+[[Roger Dannenberg]]
+
+ブロックサイズをあげていった時に、オールオーディオレートで処理した時の処理負荷の谷が8サンプルの時に来る
+
+[[O2]]メッセージのフォーマットだとこれで、
+
+```
+/arco/fmosc/new ID chans input1 input2 ...
+/arco/free ID
+```
+
+ハイレベルのAPIだとこう
+
+```
+sine1 = sine(440,0.01).play()
+sine1=nil
+```
+
+
+リアルタイムのUGen増やす、減らすもできる
+
+[[Nick Collins]]からの質問SuperColliderとの違い
+
+SCはコンパイルされたUGenどの順番で実行されるかが一列にソートされて順番に実行されていくけど、Arcoは必ずしもそうじゃない（部分的には並列化もできるのかな）
+
+遅いレートのイベントストリームの取り扱いをどうすればいいんだろう - [probe](https://github.com/rbdannenberg/arco/blob/main/doc/ugens.md#probe)命令があるのか
+
+うーん、こう見ると、[[UGenの生成をスクリプトから命令列に変換する]]のが重要なのかな
+
+## Functional Iterative Swing: An Open Framework for Exploring Warped Ramps, Exponential Rhythm, and Euclidean Shuffle
+
+スイングを数学的に考えよう
+
+リズムのグリッドを切るための直線的なライン（`y=x`）があったとして、それを`y = n^x`で捻じ曲げていくとスイングに近いものが作れるのではないか
+
+## A Bidirectionally Stacking Loudspeaker Enclosure Design for Wave Field Synthesis
+
+[[Rhode Island School of Design]]
+
+[GitHub - risdsound/wfs: An open-source, modular loudspeaker enclosure system for Wave Field Synthesis (WFS), developed at the Studio for Research in Sound and Technology (SRST) at Rhode Island School of Design (RISD).](https://github.com/risdsound/wfs)
+
+## Composing for AI Voice Model Choir
+
+[[Nick Collins]]
+
+人の声を出すモデルに、全然関係ないソースをぶち込む
+
+メルツバウの音楽でテイラースイフトの声のモデルを駆動するとか
+
+[Music for Celebrity AI Voice Model Choir | Nick Collins | sick lincoln](https://sicklincoln.bandcamp.com/album/music-for-celebrity-ai-voice-model-choir)
+
+Danger of Revisionism
+
+## Explorations In Augmented String Instrument Design: A Conversation With Mentors Of Musical Innovation
+
+後藤さんて電気バイオリン作ってたんだ
+
+[Project MUSE - The Aesthetics and Technological Aspects of Virtual Musical Instruments: The Case of the SuperPolm MIDI Violin](https://muse.jhu.edu/article/585450)
+
+DMIとかAugumented Instrumentのデザインプロセスをどう語るかに参考になりそうな感じはする
+
+## Acoustic Wave Modeling with 2D FDTD: Applications in Unreal Engine for Dynamic Sound Rendering
+
+[[Bilkent Samsurya]]
+
+ゲームメーカーで働いてるけど研究者としてはインデペンデントらしい
+
+レイトレベースのリバーブだと低域厳しいですよね
+
+[[時間領域有限要素法|FDTD]] 使いましょう
+
+- Unreal上でプリプロセスして、
+- PythonでFDTDシミュレーション
+- クアドラマイクでスイープ録音したのをIRに逆畳み込み
+- Unrealに戻ってIRに反映
+
+聴取点が動いたらどうなるのかな
+
+低域の改善は実際のとこどうなんでしょう
+
+---
+
+## Wax: Flow-based Audio Programming in the Web Browser
+
+[[Wax]] にまとめて書いた
+
+[[Michael Cella]] [[Anıl Çamcı]]
+
+---
+
+## An Approach to Creating Unalienated Music Technology
+
+[[David Minnix]] [[Anıl Çamcı]]
+
+Unalianatedねえ
+
+Problem of High-Tech
+
+Climate impact of computing
+
+[[サーキットベンディング]]とサスティナビリティ [Circuit Bending and Environmental Sustainability: Current Situation and Steps Forward · NIME 2022](https://nime.pubpub.org/pub/025d4cv1/release/1)
+
+[[ゾンビ・メディア]]の話でもあるね
+
+[[PermaComputing]]
+
+[[Generative Justice]]　なるほど
+
+disused mobile devices で動く楽器を作る
+
+ライブラリ[[Algae]]を作って、アプリ[[Firedot]]を作った
+
+Algae:まあよくある信号処理C++ライブラリな気がする
+
+なぜこのライブラリを作る必要があったんだろうか（なるべく依存性を減らすというのはわかるけど）
+
+AndroidとSDL2.0 /
+
+パーマコンピューティングならuxnエコシステムの方が上手くいってるようにも見えるな
+
+高校生向けワークショップ
+
+質問：高校生にやる時にこういうエシカルな側面をどうやってWSに含めるよ？
+
+## Fractional Fourier Sound Synthesis
+
+[[Rodrigo F. Cadiz]]
+
+[\[2506.09189\] Fractional Fourier Sound Synthesis](https://www.arxiv.org/abs/2506.09189)
+
+https://cordutie.github.io/frft_sound_synthesis/
+
+[[分数次フーリエ変換]]
+
+そんなのあるのか、、、、
+
+![{\displaystyle {\mathcal {F}}_{\alpha }(f)(\omega )={\sqrt {\frac {1-i\cot(\alpha )}{2\pi }}}e^{i\cot(\alpha )\omega ^{2}/2}\int _{-\infty }^{\infty }e^{-i\csc(\alpha )\omega t+i\cot(\alpha )t^{2}/2}f(t)\,dt~.}](https://wikimedia.org/api/rest_v1/media/math/render/svg/b3bd8c85bf549680c0dd243b2ff9a5c32f273e2a)
+
+時間（0）→周波数(1)ドメインの中間地点というものを考えてみれば良い（x軸に時間軸をとり、y軸に周波数をとり、その回転を考える）
+
+単位に相当するものが存在しない
+
+ノイズ除去とか圧縮には使われてたけど、合成には特に使われていない
+
+まあ単純に聴感上面白くはあるなというか、この遠回りな方向でなければ出なさそうな音がする
+
+変換した空間でフィルターをかける
+
+STFTみたいにウィンドウかけて処理するからなんともいえないなー、非リアルタイムの方が色々遊べそうな気がする
+
+入力音源がある場合、パーカッシブな音にはあんまり効き目がない
+
+音源分離とかに使う余地があるので
+
+---
+## Tone Generation with Polyphonic Cycles and Spline Modeling
+  
+[[Matthew Klassen]]
+
+[Research, Development and Collaboration](https://azrael.digipen.edu/research/)
+
+SplineKlangという作品とセットになっているよ
+
+[377 Greg Dixon & Matt Klassen | ICMC 2025 Boston - International Computer Music Conference](https://icmc2025.sites.northeastern.edu/online-listening-room/377-greg-dixon-matt-klassen/)
+
+波形のスプラインモデリング
+
+ダウンサンプルしてスプラインで補完するってことかな
+
+音色のブレンディング
+
+---
+## Hierarchisation algorithm for MORFOS : a music analysis software
+
+[Hierarchisation algorithm for MORFOS : a music analysis software  - Collegium Musicæ : collection « Musique et Sciences »](https://hal.science/MUSCI/hal-05066154v1#:~:text=MORFOS%20is%20a%20music%20analysis,to%20the%20definition%20of%20structure.)
+
+Multi-Scale formal diagram
+
+[Visualisation of Multi-scale Formal Diagrams for Music Analysis  - Archive ouverte HAL](https://hal.science/hal-04632212)
+
+Cognitive musicology by [[Otto Laske]]
+
+[[Variable Marcov Oracle]]をマルチスケールに拡張したもの
+
+---
+
+## Deep Drawing
+
+audio to drawing
+
+絵を描いている時の音を録音して、その音から何を描いているのかコンピューターに予測させる
+
+
+---
+
+## dit dah delta token: Statistical Models of Music and Language Interfering via Morse Code
+
+  
+[[Victor Shepardson]] [[Thor Magnusson]]
+
+Morse music for LoftSkevtaStodin
+
+[[Notochord]]
+
+[[モールス信号]]
+
+リズム・アンド・ランゲージモデル
+
+LLMのトークンツリーの代わりにモールスツリーみたいなものを作る
+
+---
+
+## Cloud Conversations Virtually Recreating the Musical Resonances of Costa Rican Outdoor Performance Spaces
+
+[[Omar Shabbar]]
+
+[[Barry Blesser]]  Proto and Meta Instruments
+
+[Spaces Speak, Are You Listening?: Experiencing Aural Architecture | Books Gateway | MIT Press](https://direct.mit.edu/books/book/2407/Spaces-Speak-Are-You-Listening-Experiencing-Aural)
+
+
+## Frescobaldi^2: applying historical split-key keyboard models to modern electronic organs
+
+[Organon - Frescobaldi^2: enharmonic keyboard enhancement - YouTube](https://www.youtube.com/watch?v=4jnMXSNvYh8)
+
+キーボードに追加できる鍵盤
+
+磁石とホールセンサーでやってるらしい
+
+[[Andrew McPherson]]の[[TouchKey]]とかと似てるのは
+
+---
+## Noise and Buttons
+
+[[Michael Gaspari]]
+
+Neurodiverityな人のための音楽教育アプリ
+
+何が一番アクセシブルなインターフェースだろうか→ボタン
+
+4つのボタンだけで、行ける限り複雑なシンセサイザーのコントロールを得る
+
+- 赤：テンポ
+- 黄：リズム
+- 緑：音色
+- 青：ハーモニー
+
+## Developing Max Objects for Mocopi: New Motion Capture System
+
+[[莱孝之]]
+
+[[DIPS]](Digital Image Proceing with Sound)元々jMax用に作られて、Maxで使えるビジュアライゼーションシステムがある
+
 
 

content/ILY不採択コメント2025.md

@@ -0,0 +1,14 @@
+---
+date: 2025-06-18 12:50
+---
+#stub
+
+石川さん
+
+鋳造とデジタル3Dモデリング/スキャンといった分野の掛け合わせは、過去のILYプロジェクトでも支援しており、研究領域としての重要性は高く評価されました。その一方で、企画書の内容からは最終的なアウトプットの形態が見えにくいことや、検証プロセスのより詳細な記述が欲しいといった指摘が審査ではなされました。具体的な作品の制作よりも基礎的な造形技術の比較検証に重きを置くのであれば、その研究を誰に向けて行うのか（鋳金作家/デジタル3D造形を行う作家や技術者/一般的な聴衆）のフォーカスを絞ることでアウトプットの方向性も自ずと定まるように思います。以上の理由から今回は不採択という結果になりましたが、3Dプリントやスキャンなどの技術的な相談についてはAMCの方で積極的に受けられればと思いますので、お気軽にご連絡ください。
+
+木村さん
+
+脳波を用いたインタラクティブなアニメーションという着眼点そのものは挑戦的なものとして評価できる企画でした。ただ、企画書の内容から現時点でどの程度技術的検証を行なっているか（例え行なっていなかったとしても）、また検証や制作のスケジュールや開発体制の具体性に掛けており、実現可能性を懸念する点が多く挙げられました。加えてこれまでの制作の内容から、なぜ今回脳波というインターフェースを選択したのかのプレゼンテーションをもう少ししてもらえると良かったです。また、自身の感覚変化をアニメーションの変化を通じて気づくケア的な領域へのアプローチに関しては、そのアニメーション自体が脳波に影響を及ぼしてフィードバックループを引き起こす点に意識的であるかどうかも重要な点になります（例えば、脳波を使った作品の最も古い例の一つであるAlvin Lucierの「Music for Solo Performer」にはその点が作品を構成する要素にあらかじめ組み込まれています）。
+以上のような点から今回は不採択という結果になりました。
+

content/James McCartney.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-26 17:45
+---
+#stub #person

content/Jonathan Sterne.md

@@ -1,5 +1,12 @@
 ---
 date: "2024-01-19T12:19:41+0900"
 ---
-#person
+#person #studies
+
+[[メディア考古学]]および[[フォーマット理論]]に関する研究で知られる研究者。マギル大学の教授。2025年3月に亡くなる。
+
+## 主な著作
+
+- [[MP3 - the meaning of a format]] - MP3形式の歴史と文化的意味を探求した著作
+- [[Diminished Faculties - Jonathan Sterne]] - 聴覚障害とメディアに関する著作
 

content/Magnetic Resonator Piano.md

@@ -0,0 +1,6 @@
+---
+date: 2025-07-01 12:52
+---
+#survey #instrument 
+
+[Magnetic Resonator Piano](https://instrumentslab.org/research/mrp.html)

content/Michael Cella.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-12 10:32
+---
+#person 
+
+[nnirror (Michael Cella) · GitHub](https://github.com/nnirror)
+
+[[Wax]]とか[[facet]]とか作ってる

content/Michael Krzyzaniak.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-27 16:26
+---
+#stub

content/Moog Guitar.md

@@ -0,0 +1,22 @@
+---
+date: 2025-07-01 16:24
+---
+#instrument 
+
+[[Paul Vo]]が開発した特殊な[[サスティナー]]を内蔵したエレキギター.　ドライバーコイルとピックアップコイルが兼用されているのが特徴。サスティナーの逆で強制ミュートみたいなこともできるというのが面白い。
+
+
+
+[Licensing: \| Paul Vo](https://web.archive.org/web/20240902205915/https://voinventions.com/licensing/)
+
+特許
+
+(2019年で切れた)
+
+[US6216059B1 - Unitary transducer control system         - Google Patents](https://patents.google.com/patent/US6216059B1)
+
+（2025年に切れる予定）
+
+[US7667131B2 - Player technique control system for a stringed instrument and method of playing the instrument         - Google Patents](https://patents.google.com/patent/US7667131B2/)
+
+シャント抵抗で読み取ってるかと思いきや時間重畳なのかな

content/Nim.md

@@ -0,0 +1,14 @@
+---
+date: 2025-06-20 12:57
+---
+#programming-language 
+
+[Nim Programming Language](https://nim-lang.org/)
+
+ランタイムレスなコンパイル言語。カスタムのメモリアロケーターとかも定義できる。
+
+コンパイラもセルフホスティングされているし、STLもNim自身で書かれている。
+
+
+
+CやC++との連携がしやすい。

content/Notochord.md

@@ -0,0 +1,12 @@
+---
+date: 2025-06-13 09:56
+---
+#software 
+
+[[Victor Shepardson]]
+
+[GitHub - Intelligent-Instruments-Lab/notochord: Notochord is a real-time neural network model for MIDI performances.](https://github.com/Intelligent-Instruments-Lab/notochord)
+
+[Notochord | Intelligent Instruments Lab](https://iil.is/research/notochord)
+
+

content/Nyquist.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-26 17:51
+---
+#programming-language #computermusic 
+
+[[Roger Dannenberg]]が90年代に開発した言語。
+
+ユースケースとしては[[Audacity]]の中にエフェクトをかける機能として搭載されている

content/Olia Lialina.md

@@ -4,3 +4,9 @@ date: 2024-10-04 13:31
 #person 
 
 [[Not Art&Tech - On the role of Media Theory at Universities of Applied Art, Technology and Art and Technology.]]
+
+---
+
+[Turing Complete User](https://contemporary-home-computing.org/turing-complete-user/)
+
+[[橋本麦]]さんによる試訳 [『チューリング完全ユーザー』試訳 - baku](https://scrapbox.io/glisp/%E3%80%8E%E3%83%81%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E5%AE%8C%E5%85%A8%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%80%8F%E8%A9%A6%E8%A8%B3)

content/Omni.md

@@ -0,0 +1,12 @@
+---
+date: 2025-06-20 12:47
+---
+#programming-language  #music 
+
+[omni – DSL for low-level audio programming](https://vitreo12.github.io/omni/)
+
+作者：[[Francesco Cameli]]
+
+[[Nim]]で書かれた低レベルDSP記述言語。[[SuperCollider]]や[[Max]]の[[UGen]]としてエクスポートできるらしい。
+
+

content/Otto Laske.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-13 09:03
+---
+#person
+
+[Otto Laske – Music… and more](https://ottolaske.com/)
+
+

content/Pandoc.md

@@ -0,0 +1,25 @@
+---
+date: "2025-06-18T12:00:00+0900"
+---
+#tools #software
+
+[Pandoc](https://pandoc.org/)はオープンソースのドキュメント変換ツールで、Markdown、HTML、LaTeX、Word、PDFなど様々なフォーマット間の変換ができる。
+
+## 主な特徴
+
+- MarkdownからLaTeXやPDFへの変換が可能
+- [[Zotero]]と連携して学術論文の引用を管理できる
+- 様々なMarkdownの拡張記法をサポート
+- [[論文の管理]]で重要なcitekeyの処理が可能
+
+## インストール
+
+MacでのインストールはHomebrewを使うのが簡単：
+
+```bash
+brew install pandoc
+```
+
+## 関連ツール
+
+[[Obsidian]]の[[obsidian-pandoc-reference-list]]プラグインと組み合わせて使われる。

content/PureData.md

@@ -1,6 +1,6 @@
 ---
 date: "2024-01-05T17:15:38+0900"
 ---
-#sound #programming-language 
+#sound #programming-language #computermusic
 
-[[Miller Puckette]]が公開しているオープンソースのサウンドプログラミング環境。
+[[Miller Puckette]]が公開しているオープンソースの[[サウンドプログラミング環境]]。[[Max]]に影響を与えた。

content/Red Green Syntax Tree.md

@@ -0,0 +1,13 @@
+#compiler-design 
+
+[Red-Green Trees: an Overview. Six months ago I dug into Roslyn’s… | by Bayastan | Jun, 2025 | Medium](https://medium.com/@krendelia2021/red-green-trees-an-overview-17bae2d84e8c)
+
+[[抽象構文木]]というか[[具象構文木]]の実装方法の一つ。
+
+構文の途中で差し込まれたコメントなどのトリビアなどを保持して、完全なソースコードに戻せるけど実行効率などをよくしたままにできるやり方。
+
+部分的に構文木を書き換えたりするとソースコードのロケーション情報がずれたりするので、文字幅とオフセットを別々に持たせるというやり方をしている
+
+ながいけどこれがわかりやすい
+
+[Ruby Parser開発日誌 (19) - 最高の構文木の設計 2024年版 - かねこにっき](https://yui-knk.hatenablog.com/entry/2024/08/23/113543)

content/Research in music and artificial intelligence.md

@@ -0,0 +1,60 @@
+---
+cssclass: research-note
+type: "journalArticle"
+author: "Roads, Curtis"
+title: "Research in music and artificial intelligence"
+publication: "ACM Comput. Surv."
+date: 1985-06-01
+citekey: roads_research_1985
+tags:
+- research
+- journalArticle
+---
+
+> [!Cite]
+> Roads, Curtis. 1985. 「Research in music and artificial intelligence」. _ACM Comput. Surv._ 17 (2): 163–90. [https://doi.org/10.1145/4468.4469](https://doi.org/10.1145/4468.4469).
+
+>[!Synth]
+>**Contribution**:: 
+>
+>**Related**:: 
+>
+
+[online](http://zotero.org/users/12014264/items/VXISTY3A) [local](zotero://select/library/items/VXISTY3A) [pdf](file:///Users/tomoya/Zotero/storage/FUU5IL8Q/Roads%20-%201985%20-%20Research%20in%20music%20and%20artificial%20intelligence.pdf)
+ 
+
+ 
+>[!md]
+> **FirstAuthor**:: Roads, Curtis  
+~    
+> **Title**:: Research in music and artificial intelligence  
+> **Year**:: 1985   
+> **Citekey**:: roads_research_1985  
+> **itemType**:: journalArticle  
+> **Journal**:: *ACM Comput. Surv.*  
+> **Volume**:: 17  
+> **Issue**:: 2   
+> **Pages**:: 163–190  
+> **DOI**:: 10.1145/4468.4469    
+
+> [!LINK] 
+>
+>  [Full Text PDF](file:///Users/tomoya/Zotero/storage/FUU5IL8Q/Roads%20-%201985%20-%20Research%20in%20music%20and%20artificial%20intelligence.pdf).
+
+> [!Abstract]
+>
+> Although the boundaries of artificial intelligence (AI) remain elusive, computers can now perform musical tasks that were formerly associated exclusively with naturally intelligent musicians. After a historical note, this paper sermonizes on the need for AI techniques in four areas of musical research: composition, performance, music theory, and digital sound processing. The next part surveys recent work involving AI and music. The discussion concentrates on applications in the four areas of research just mentioned. The final part examines how AI techniques of planning and learning could be used to expand the knowledge base and enrich the behavior of musically intelligent systems.
+>.
+> 
+# Notes
+
+>.
+
+
+# Annotations%% begin annotations %%
+
+
+%% end annotations %%
+
+
+%% Import Date: 2025-06-11T10:19:43.341-04:00 %%

content/Roger Dannenberg.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-12 09:28
+---
+#person #stub
+
+[[Nyquist]]
+
+[[Arco]]

content/Rune.md

@@ -0,0 +1,9 @@
+#programming-language 
+
+[The Rune Programming Language](https://rune-rs.github.io/)
+
+[[Rust]]で書かれた埋め込みプログラミング言語。
+
+Rustの文法ほぼそのままに動的型付けの言語をつくるとこうなる、みたいな感じ
+
+[[Moonbit]]とか[[Rhai]]も近い感じ（Rhaiは直接影響を受けたとのこと）

content/Scheme for Max.md

@@ -0,0 +1,16 @@
+---
+date: 2025-06-14 09:38
+---
+#computermusic 
+
+[[Max]]で[[Scheme]]を使ってアルゴリズミックコンポジションをするためのパッケージ
+
+[GitHub - iainctduncan/scheme-for-max: Max/MSP external for scripting and live coding Max with s7 Scheme Lisp](https://github.com/iainctduncan/scheme-for-max)
+
+[Learn Scheme For Max — Learn Scheme For Max and s7 Scheme 0.1 documentation](https://iainctduncan.github.io/learn-scheme-for-max/index.html)
+
+[Scheme For Max - Documentation — Scheme For Max 0.1 documentation](https://iainctduncan.github.io/scheme-for-max-docs/)
+
+[Scheme for Max Sequencing Toolkit — Scheme for Max Sequencing Toolkit 1.0 documentation](https://iainctduncan.github.io/s4m-stk/)
+
+

content/Scheme.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-14 09:38
+---
+#programming-language 

content/Scrapbox.md

@@ -0,0 +1,24 @@
+---
+date: "2025-06-18T12:30:00+0900"
+---
+#software #tools #note
+
+Scrapboxは、リンクベースのノート取りツール。URLをコピーするだけで簡単に参照できる段落を作れる。
+
+https://scrapbox.io/
+
+## 特徴
+
+- Wikiリンク記法でページ間をシームレスに接続
+- 箇条書きベースのシンプルな記法
+- ページの存在に関わらず自由にリンク作成が可能
+- 2ホップリンクによる関連情報の発見
+- 非同期のリアルタイム編集
+
+## 活用例
+
+- チーム内のナレッジベース
+- 個人的な研究ノート
+- アイデア整理
+
+[[この研究ノートについて]]でも触れているように、[[Obsidian]]と比較検討されることもある知識管理ツール。

content/Somax2.md

@@ -4,9 +4,10 @@ date: 2025-06-09 09:03
 #computermusic
 
 [Somax2 | STMS Lab](https://www.stms-lab.fr/projects/pages/somax2/)
+
 [somax2    \[Music Representations Team\]](http://repmus.ircam.fr/somax2)
 
-Voyagerというシステムの後継
+OMaxや Voyagerというシステムの後継
 
 Real-Time Instrumental Playing Technique(IPT) Recognition
 

content/Style Transfer.md

@@ -0,0 +1,10 @@
+---
+date: 2025-06-13 09:23
+---
+#research #machinelearning
+
+音楽分野でも結構あるのかな
+
+[Groove2Groove – One-shot music style transfer](https://groove2groove.telecom-paris.fr/)
+
+[MUSIC MIXING STYLE TRANSFER](https://jhtonykoo.github.io/MixingStyleTransfer/)

content/SuperCollider.md

@@ -3,7 +3,7 @@ date: "2024-02-06T02:00:06+0900"
 ---
 #programming-language #software #tools #sound
 
-James McCartneyが開発、その後OSS化された音楽プログラミング言語。
+[[James McCartney]]が開発、その後OSS化された音楽プログラミング言語。
 
 [index | SuperCollider](https://supercollider.github.io/)
 

content/Thor Magnusson.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-13 09:55
+---
+#person

content/TouchKey.md

@@ -0,0 +1,11 @@
+---
+date: 2025-06-14 09:42
+---
+#instrument #computermusic 
+
+[TouchKeys](https://instrumentslab.org/research/touchkeys.html) 
+
+by [[Andrew McPherson]]
+
+
+

content/UGenの生成をスクリプトから命令列に変換する.md

@@ -0,0 +1,38 @@
+---
+date: 2025-06-12 09:24
+---
+#memo #programming-language  #sound 
+
+[[Arco]]で行われているメッセージング
+
+```
+/arco/fmosc/new ID chans input1 input2 ...
+/arco/free ID
+```
+
+ハイレベルのAPIだとこう
+
+```
+sine1 = sine(440,0.01).play()
+sine1 = nil
+```
+
+
+[[SuperCollider]]でも似たような話だけど、ライブコーディング的なシステムを作ろうと思うとこういう制御構造→命令列への変換を定式化するのが重要なのでは
+
+ジェネラティブUGenネットワークグラフの生成もここに含まれる
+
+すでに作られたC++のシンセとの統合というのが魅力ではある
+
+ここがうまく定式化すれば、必要な部分だけダイナミックインタラクションできて、他はJITコンパイルで効率化できるのではないか
+
+まーでも、どのみち`sine1=nil`みたいな命令型の構造がハイレベルにまで入り込まないと無理なんだよな（グローバルだけ再代入を許せばそれでいいのかも）
+
+[[mimium]]に生かそうと思うと、UGenに相当するものをダイナミックに作る・消去する工程を命令型でうまく表現できればいいんだけどなあ
+
+実際には使われてない（アウトプットされてない）UGenもインスタンス化されてしまうので、これを遅延実行するみたいな仕組みがあればいいのかな
+
+インスタンス化/IOやり取りするメモリマネジメントのタイミング制御だけが重要
+
+[[Kronos]]におけるコンパイラ-インタプリタを繋げる役割としての[[継時再帰]]
+

content/Variable Marcov Oracle.md

@@ -0,0 +1,6 @@
+---
+date: 2025-06-13 09:06
+---
+#notion 
+
+[Variable Markov Oracle. A variable Markov oracle is a type of… | by Mehmet Akif Cifci | Medium](https://themanoftalent.medium.com/variable-markov-oracle-e796fd534264)

content/Victor Shepardson.md

@@ -0,0 +1,6 @@
+---
+date: 2025-06-13 09:57
+---
+#person 
+
+[jroose · GitHub](https://github.com/jroose)

content/Wax.md

@@ -0,0 +1,45 @@
+---
+date: 2025-06-12 10:31
+---
+#computermusic #visual-language #programming-language 
+
+[GitHub - nnirror/wax: Web-based audio patching environment](https://github.com/nnirror/wax)
+
+WebAudioベースのグラフィカルデータフロープログラミング環境
+
+[[Michael Cella]]
+
+[wax](https://wax.bz)
+
+---
+
+ICMC2025のトーク
+
+- ビジュアル言語だと一定以上の複雑さを扱えない
+- ライブコードだと自分が今何やってるのかを把握できなくなってくる
+
+[[facet]]を同梱しているので、Webベースで両方やれる！
+
+[[RNBO]]のパッチからWaxのデバイス（オブジェクト）にできる！なるほどね
+
+アプリケーション
+
+- モバイル
+- マルチチャンネル
+- 教育
+
+スマホを[[ES9]]に繋いでマルチチャンネルか
+
+真面目にユーザーフィードバックをとった 7人
+
+ざっくりとした制作の指示をして、フィードバックを募った
+
+メタオペレーション
+
+サブパッチがWebAudioだと難しいという問題
+
+---
+
+
+
+

content/Wekinator.md

@@ -0,0 +1,9 @@
+---
+date: 2025-06-11 15:15
+---
+#software #computervision
+
+
+[Wekinator | Software for real-time, interactive machine learning](http://www.wekinator.org/)
+
+[GitHub - fiebrink1/wekinator: The current version of the Wekinator. It used to be mini, now it's not, but it still lives here.](https://github.com/fiebrink1/wekinator)

content/Zotero.md

@@ -1,12 +1,16 @@
 ---
 date: "2023-08-10T18:40:08+0900"
 ---
-#tools #software 
+#tools #software #research
+
+オープンソースの文献管理ソフトウェア。[[論文の管理]]に活用。
 
 https://zotero.org/
 
 - アカウント作ればDBは無料で同期化、PDFとか添付ファイルは有料
 - WebDAVサーバーがあればファイルも含めて同期可能
 	- 今の所[[自宅サーバー#NAS]]でWebDAV立ち上がってるので、VPNに入ってればどこでも読める
-- まとめてBiblatexにエクスポートしようと思うとこれしか選択肢がない
-	- どちらかというと、[[Mendeley]]が重すぎて無理
+- まとめて[[BibLaTeX]]にエクスポートしようと思うとこれしか選択肢がない
+	- どちらかというと、[[Mendeley]]が重すぎて無理
+- [[Obsidian]]との連携には[[obsidian-zotero-integration]]プラグインを使用
+- [[Pandoc]]との連携で引用管理が便利

content/facet.md

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

content/index.md

@@ -15,7 +15,7 @@ https://matsuuratomoya.com
 - [[音楽プログラミング言語]]
 	- [[mimium]]
 - [[プログラミングの良いチュートリアル]]
-- [[電子管楽器]]
+- [[フィードバック電子管楽器]]
 	- [[DIY可能なトランペット]]
 - [[DIY半導体]]
 - [[オルタナティブ電子基板]]

content/mimium.md

@@ -18,6 +18,11 @@ https://github.com/mimium-org/mimium-rs
 
 ## 開発メモ
 
+### 理論
+
+- [[mimiumの部分的DSP更新とFaustのondemand]]
+- [[mimiumでのIOパラメーター]]
+
 ### 中間表現について
 
 - [[mimium新内部表現の構想]]
@@ -25,13 +30,48 @@ https://github.com/mimium-org/mimium-rs
 - [[mimiumのMIRコンパイル過程を真面目に考える]]
 - [[lambda-mmm(実用版)]]
 - [[mimiumグローバル環境評価について]]
-- [[多段階計算を命令型VMインストラクションで表現したい]]
+
+
+## マクロ
+
+- [[mimiumと多段階計算]]
+	
 
 ### ランタイム周りについて
 
-- [[mimiumの配列のGC]]
-- [[mimiumのファイルIO]]
+- [[mimiumにおけるIO制御]]
+	- [[mimiumでMIDIインプットを実装]]
+	- [[mimiumのファイルIO]]
 - [[mimiumのプラグインシステム]]
-- [[mimiumでMIDIインプットを実装]]
 - [[WASIでmimiumをビルド＆デバッグしてみる]]
+- [[mimiumの配列実装]]
+- [[mimiumのREPLをVMで実装]]
 
+## 応用先について
+
+ふと思ったけど、[[SuperCollider]]や[[PureData]]と比べると、これらの言語は組み込みに使おうと思うとLinuxが動く環境を想定することになる（[[Heavy]]はそれを全く別の処理系作ることで対応してたけど）。シーケンサとかスケジューラーがあるような、[[Faust]]だと難しいタイプのプログラムを[[Arduino]]とかに持っていくには向いているのではないか([[Extempore]]だって仕組み的に言えばそうかもしれないけど)
+
+- できれば教育用途とかに持ち込めるのが一番いい
+- ブートストラップできるといい
+	- いろいろな人がmimiumで拡張やライブラリを書けるようになってからが本当の本番
+	- 言語自体の拡張機能をその言語上でたくさん作れるとよい
+	- しかし、極端に自由度が高いとそれはそれで参入障壁が高い
+
+
+[[mimiumでのシーケンサ]]
+
+[[mimiumでのライブコーディングエンジン]]
+
+---
+
+開発ロードマップ
+
+
+[mimium-rs/Roadmap.md at dev · mimium-org/mimium-rs · GitHub](https://github.com/mimium-org/mimium-rs/blob/dev/Roadmap.md)
+
+- 多段階計算:大変そう。コンパイラドライバをユーザーコードから叩けるようにするのが先か。
+- [[mimiumのレコード型|レコード型]]：要件定義はほぼできたし、他の機能への依存も特になし。デフォルト引数の実装を無視すればとりあえず進められそう
+- [[mimiumでのバリアント]]：やっぱり必要、だが分割コンパイルを先にやらないとダメかも
+- モジュールシステム：名前空間のCライブラリレベルでのマングリングとか考える必要ありそう。
+- 配列型の実装：GC問題片付けばなんとか？固定長と可変長の切り替えをどうするかを考えたい。
+- OSCの実装

content/mimiumでのIOパラメーター.md

@@ -0,0 +1,128 @@
+---
+date: 2025-07-01 18:43
+---
+#mimium 
+
+マルチスレッド前提の場合、Shared State全般がRwLockとかで包まれることになってしまう
+
+しかし、大概の場合グローバルな状態共有はAtomicな単一パラメーターで済む
+
+あくまで、普通のグローバル変数宣言はスレッドローカルな扱いにして、メインスレッドと協調しないといけない場合は"shared"みたいなキーワードをつけるようにするとか（構文増やしたくないけど）
+
+だし、これだと結局OSC送るサーバークライアント構成と実質的に変わらないかも
+
+```rust
+let hoge = 100;
+```
+
+みたいなのの代わりに、別のキーワードを持たせる
+
+```rust
+global hoge = 100
+```
+
+プリミティブな型であれば、Atomicな書き換えでOK。hogeへの書き込みをオーディオコンテキストの中でやると毎サンプル実行される保証がない、みたいな仕様？
+
+タプルとか合成型だと、マルチスレッドで書き換えたときに片方のパラメーターが更新されてない時に読み取られる可能性が厳密にはある
+
+グローバルに宣言された配列型とか、合成型をどうやって扱う？
+
+単に、グローバルな値への書き込みがいつ行われるか保証はされませんよ、という仕様にするならそれでも十分か
+
+もしくは、
+
+```rust
+let hoge = param(100)
+```
+
+みたいなラップの仕方を考える。hogeは`Param<Number>`型をもち、Number型に自動キャストできる。
+
+パラメトリックフィルタ複製で、個々の周波数を外側からコントロールしたいとするとどうなるか
+
+```rust
+fn replicate(n,gen){
+    let g = gen(n, n*100)
+    if (n>0.0){    
+	let c = replicate(n - 1.0,gen)
+        | | g() + c()
+    }else{
+        | | g()
+    }
+}
+fn mygen(freq){
+  osc(freq)
+}
+fn gen(n,init_f){
+   let channel = param("freq_%n",init_f);
+   | | mygen(channel)
+}
+let myfilter = replicate(5,gen)
+fn dsp(){
+	myfilter()
+}
+```
+
+まあこうなるか 自動グループ化みたいなのできるか？実行してる関数の深さ的に`global::replicate::gen::(args)`で自動ネーミング自体は不可能ではなさそうだが/自動グループをやりたければ、`Param<T>`の中身をレコード型にすればいいのか
+
+paramがジェネリックな関数`T->Param<T>`であることが重要になってくる。範囲の制限とかはRanged型みたいなのをmimium側で定義すればよくなる・・・はずまあIO周りは結局命令型になるのかなあ
+
+
+
+```rust
+let channel = param("freq_%n",init_f);
+set_param("freq_%n",1000.0)
+channel = 1000;//
+```
+
+最後の行のように、普通にAssign書き込むのもできるようにしておきたい。これできるようにするには、Assignをオーバーロードできるような型システムが必要なのかな`param(コンストラクタ)`と`get_param_name`、`get_param`、`set_param`の4種類があれば十分か
+
+
+
+[[mimiumのレコード型]]のデフォルト実装、関数のデフォルト引数の組み合わせに対して自動でパラメーターが作られるようにしたい
+
+```rust
+fn gen_synthesizer(){
+	let s = |gate = 0,freq=1000,gain = 1.0|{
+		...
+	}
+	s({..})
+}
+let mysynth = gen_synthesizer();
+
+fn dsp(){
+	mysynth()
+}
+
+```
+
+これを実行すると、隠れレコード構造体定義とグローバルなデフォルト引数が作られる
+
+```rust
+...
+type defaultarg = {
+ "gate":number = 0,
+ "freq":number = 1000,
+ "gain":number = 1.0
+}
+let default_arg_for_mysynth = param("mysynth",defaultarg::default());
+fn dsp(){
+	mysynth()
+}
+```
+
+dsp内で`mysynth({..})`と実行してしまうと、これがグローバルなコンテキストで作られない可能性がある・・のか？いや、でも基本的に書き換えられる心配はないからいいのかな
+
+デフォルト引数構造体のインスタンスは必ずグローバル評価で行う、だとパラメトリックな生成はできないし問題起きそう
+
+```rust
+//自動キャストとジェネリクスの組み合わせさえうまくいけばこのくらいのことはできそう
+let p = param({..});
+fn dsp(){
+	p |>
+	|gate = 0,freq = 1000,gain = 1.0|{
+		...//do something
+	}
+}
+```
+
+ということは、とりあえず雑にParamを実装して

content/mimiumでのシーケンサ.md

@@ -0,0 +1,42 @@
+
+#memo #mimium 
+
+[[SuperCollider]]のPatternに相当するものを作ってみたい。
+
+Pattern自体は基本的にはシンプルな遅延リスト。だが値の種類を、ピッチと長さとかグループ化できてジェネリックなので、静的型付け言語だとジェネリクスがいる（`next`メソッドを持つ型クラスとかインターフェース的なものが欲しくなる）
+
+重要ポイント
+
+- あるパターンを先に構築して、それにあとから適当なシンセを当てはめることもできる
+- 数値リテラルが定数（不変）パターンに自動キャストされていることで、パターンのリストの要素にさらに別のパターンを埋め込むことができる
+
+`Pbind`は実際には遅延リストを実行してイベント（キーバリューの辞書ペア集合）のリストを得ている
+
+[Pattern Guide 03: What Is Pbind | SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/A-Practical-Guide/PG_03_What_Is_Pbind.html)
+
+`.play`を実行すると、`EventStreamPlayer`クラスがいろいろ頑張ってくれるらしい
+
+`instrument`の指定なしにPbindすると、デフォのシンセが鳴る
+
+```smalltalk
+SynthDef(\default, { arg out=0, freq=440, amp=0.1, pan=0, gate=1;
+    var z;
+    z = LPF.ar(
+            Mix.new(VarSaw.ar(freq + [0, Rand(-0.4,0.0), Rand(0.0,0.4)], 0, 0.3)),
+            XLine.kr(Rand(4000,5000), Rand(2500,3200), 1)
+        ) * Linen.kr(gate, 0.01, 0.7, 0.3, 2);
+    OffsetOut.ar(out, Pan2.ar(z, pan, amp));
+}, [\ir]);
+```
+
+durとかdegreeみたいなのをいい感じに解釈するのはEventStreamPlayerの役割ってことか？
+
+[supercollider/SCClassLibrary/Common/Streams/Stream.sc at d4b6f8d5e6c9e419c86b3c44d899b63b4610893b · supercollider/supercollider · GitHub](https://github.com/supercollider/supercollider/blob/d4b6f8d5e6c9e419c86b3c44d899b63b4610893b/SCClassLibrary/Common/Streams/Stream.sc#L491)
+
+ここでもなさそうだな、謎・・・。
+
+まあでも,degreeとfreqの自動変換とかは[[単位変換のための型システム]]で解決すべき問題かも
+
+
+
+

content/mimiumでのバリアント.md

@@ -0,0 +1,38 @@
+---
+date: 2025-07-03 18:34
+---
+#memo
+
+幽霊型含む、カスタムのコンストラクターを書こうとすると名前空間の問題が出てくる
+
+二重インクルードの問題とかもあるので、先に分割コンパイルの仕組みを整える方がいい？
+
+型の環境の中に変数解決が必要になってくる
+
+内部的には幽霊、Opaque、バリアントで分かれててもいいかもな
+
+```rust
+enum Variant{
+	Phantom(Symbol),
+	Opaque(Symbol,TypeNodeId),
+	Union(Box<Self>,Box<Self>)
+}
+enum Type{
+	...
+	
+	Variant(Variant)
+}
+```
+
+Foldでネストするくらいなら`Vec<Box<Self>>`に収められるかな？
+
+パーサーとASTとしてはmatch節も加えないと意味ない
+
+で、型推論に加えなきゃいけないコードは、
+
+- 型コンストラクタを関数として使えるように型→値環境に追加し、App式の評価で使えるように
+- match式の型推論
+
+matchのコード生成がジャンプテーブルとか出てくるとめんどくさいんだよなあ
+
+

content/mimiumでのライブコーディングエンジン.md

@@ -0,0 +1,24 @@
+---
+date: 2025-06-27 16:54
+---
+#mimium #livecoding 
+
+一般化するとこういうモデルにならんだろうか
+
+![[img/general-livecoding-model.png]]
+
+Tracksの部分の抜き差しだけできるのが[[ChucK]]のShredシステム。
+
+とりあえずはこれをRust実装してもいいけど、最終的にはこのモデル自体をmimium上で実装することもできそう
+
+（不要なトラックの削除と空きスロット再利用を実現するためには、普通の配列とは別に単方向リストかSlotmap的なものを作る必要がありそう）
+
+Reducerは基本的には全てのチャンネルの加算だけでいいので滅多にいじる必要ないけど、いじりたいケースが出てくるかも
+
+ChucKではエフェクトのテールが更新時にぶちぎれる問題があったので、それを防ぐためのPostFX Chain
+
+各トラックごとのエフェクトのライブ切り替えとかも実現しようと思えばできるかな
+
+...これ、結局[[SuperCollider]]のJITLibと同じことかもな
+
+[jitlib\_basic\_concepts\_01 \| SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/JITLib/jitlib_basic_concepts_01.html)

content/mimiumと多段階計算.md

@@ -0,0 +1,71 @@
+#memo #mimium 
+
+
+
+- [[多段階計算を命令型VMインストラクションで表現したい]]
+	- 一時期考えていたが、あんまり筋が良くないのでやめた
+
+
+[Implement multi-stage computation intepreter by tomoyanonymous · Pull Request #136 · mimium-org/mimium-rs · GitHub](https://github.com/mimium-org/mimium-rs/pull/136)
+
+シンプルに構文木レベルでのインタプリタを別途作ることで実現できそう。
+
+
+## 課題
+
+- 組み込みの関数の型情報がマクロ用（レベル0）とVM用（レベル1）で分かれているので、両方にあることを別々に宣言しなければならない
+	- 逆に、ベクターのappend・removeや文字列操作など、メモリを確保する操作はレベル0でのみ利用できる組み込み関数として制限すると、便利かもしれない
+	- 逆に、`self`や`delay`はレベル1でのみ利用できる関数とする
+	- レベル0，1両方で利用できるpersistentなモジュールは、上記2種類のいずれも使わず、かつescapeとBracketも利用しないものであればよい、ということになる
+- もともとディレイの最大サイズはリテラルで指定しなければいけないという問題があったが、これを`make_delay(size:float)-> <(float,float)->float>`（レベル0で最大時間を指定すると、入力と遅延時間をとる関数のコードを返すという関数）にできるかも
+	- ただ、これやるとディレイが絡む関数はすべてレベル0定義になるのかな
+	- なんかそれよりは、[[数値プリミティブ型に常に範囲をつける]]とかのほうが筋がいいかも
+
+```rust
+fn fbdelay(max_time){
+  `|input,time,fb| {
+    (input + self*fb, time) |> make_delay!(max_time)
+   }
+}
+```
+
+- こういうfbdelayを2個以上つかうときのコードはどうなるのかな
+	- というか、fbdelayで生成されたコードをMIRに持ってくときにどうなるのか？
+	- Value型を単なるCodeじゃなくてDelayとして特別な値にリダクションすればいいのかな
+
+[[otopoiesis]]でパラメーターを生成するのにも使える？
+
+```rust
+fn synth(freq,gate){
+  osc(freq)*gate
+}
+
+fn synth_module(freq:()->float,gate:()->float){
+ `||{ synth(freq(),gate()) }
+}
+```
+
+これのモジュールを評価すると、freq,gateがUIに現れるという感じでできるのかな（そして、ここでUIの範囲制限をするためにも数値型が範囲を持っていた方がいいということになりそう）
+
+うーん、サンクを手動で使わず表現できるような何かが欲しいなあ
+
+```rust
+fn wrap_module(param:Param, synth:(Param)->float ){
+  `{ | | synth(param |> invoke) }
+}
+```
+Param型はinvokeでuiからの値を取れる、サンクをアンラップするようなメソッドを持つ型クラスに属している、という感じで、ジェネリクスが実装出来たらいけそうね
+
+
+## マクロを提供するプラグイン
+
+プラグインも、各関数が返す型と同時にどのレベルでその関数が使えるかをコンパイラに渡す必要がある
+
+
+### ファイル読み込みはどうなる？
+
+[[mimiumのファイルIO]]の話。マクロの展開より先に型の評価が行われるので、例えばファイルを読み込んでからチャンネル数が分かる、みたいな場合型情報を読み込む段階でファイルを読みこまなければならない、がその評価のためにはマクロを実行して文字列の値を受け取らなければならない、、、ということで、結局[[依存型]]がないと多段階計算でも対応できない。
+
+結局、読み込んで返す値として次元数の値を持つ配列を返すしかないのかも
+
+

content/mimiumにおけるIO制御.md

@@ -0,0 +1,23 @@
+---
+date: 2025-06-18 15:42
+---
+#mimium 
+
+この辺に応用する用。
+
+[[mimiumでMIDIインプットを実装]]
+
+[[mimiumのファイルIO]]
+
+---
+
+[[Kronos]] Meta-Sequencerに近い仕組みを、IOモナドなしで実装する（正格評価なのでそこまでやらんでいいはず）
+
+組み込みのコンパイラドライバを制御する関数をいくつか用意する
+
+```
+start()->int
+stop(id:int)
+
+
+```

content/mimiumのREPLをVMで実装.md

@@ -0,0 +1,63 @@
+---
+date: 2025-06-27 17:10
+---
+#mimium #memo 
+
+今の所の問題点として
+
+- マシンが一つの結合されたコンパイル済みバイトコードしか受け付けていない
+	- これを配列として複数保持する必要あり
+- 外部関数の参照インデックスのテーブルはVM上に載っているが、内部関数は一つのプログラム上の絶対位置しか参照できない
+- プログラム上で定義した内部関数を、他のプログラムでも参照できるようにする、シンボルテーブルがいる
+- またグローバル環境の評価も同様に、シンボル-(GlobalPos,型)変換のテーブルをコンパイラが持っていないとだめ
+
+- マシンをオーディオドライバ立ち上げとともにオーディオスレッドにMoveしてしまっているので、メインスレッドで新たにコンパイルしたプログラムを何かの方法でオーディオスレッドに送ってやらないといけない
+	- しかもできればロックフリーで
+		- [GitHub - hawkw/sharded-slab: a lock-free concurrent slab (experimental)](https://github.com/hawkw/sharded-slab)　これかな
+		- それか普通にDashMapか
+- シンボルテーブルもDashMapで作ってればなんとかなるのかな
+- VMの中にControllerみたいなDashMap系をArcで包んだものを用意しておいて、メインのマシンはオーディオスレッドに送ってしまい、Arcでコントローラーだけをメインスレッドに残しておく
+
+- ExecContextはRepl起動から終了まで次の情報を持ち続ける
+	- グローバル変数のシンボルテーブル（型情報含む）
+	- 内部関数のシンボルテーブル（型情報含む）
+	- 外部関数のシンボルテーブル（型情報含む）
+
+
+ExecContextは、起動時VMのインスタンスを作る。この時VMConrollerのArc参照がVM内に渡される。
+
+ExecContextは、ソースコードを受け取るたびにコンパイラのインスタンスを作ってはプログラムを出力し、終了する。
+
+出力されたプログラムはVMControllerのPrograms(DashMap)に非同期でインサートされ、シンボルテーブルも更新される
+
+Replで送られた新しいプログラム（一行だけ）のプログラムをどのスレッドで、いつ実行するかが問題
+
+DSPの頭でReplで溜まった処理(無名関数のキュー)を順番に消化する？あるいは、
+
+```rust
+dsp = |l,r| ->(float,float){ ( new_process )}
+```
+
+こんな感じでREPLに送ると、実際には
+
+```rust
+fn repl_001(){
+	| | {
+		dsp = |l,r| ->(float,float){ (　new_process )}
+	}@now
+}
+```
+
+みたいなのを実行したことになるとか
+
+これだとスケジューラープラグイン実装されてることが前提にはなるし、スケジューラーにタスクを登録するのをController越しに行える必要がある
+
+というか、メインスレッドに相当するものを別途作る方がやっぱり良さそう
+
+結局、今VMに乗ってるだいたいのものはShared Stateとして共有されて、スタック、ベースポインタ、StateStorageだけが独立する形になりそう
+
+---
+
+シングルスレッドの場合、REPLで実行されたものは必ずオーディオドライバのブロック頭で消化
+
+[[mimiumでのIOパラメーター]]

content/mimiumのレコード型.md

@@ -0,0 +1,223 @@
+---
+date: 2025-07-02 11:40
+---
+#memo 
+
+[Proposal: Record Syntax · Issue #99 · mimium-org/mimium-rs · GitHub](https://github.com/mimium-org/mimium-rs/issues/99)
+
+古い v0.4.0 では実験的なレコード（struct）型があったが、新たなレコード型の構文を実装する。
+
+新構文のデザインは、名前ごとにデータをグルーピングすることで、プログラマの意図をより直接的にコードに反映できるようにするとともに、デフォルト値を設定することで記述量を減らすことを目指す。
+
+また、タプル型で考案されているパラメータパックとデフォルト値付きレコード型を組み合わせることで、「UGen as 関数」という概念を型安全性を保ちながら直接表現でき、かつデフォルト引数付き関数にありがちな引数の数に関する混乱を回避できそう。
+
+## 基本構文
+
+構文のベースは [Elm](https://elm-lang.org/docs/records) である。小竹は Rust 風にはしない。
+
+匿名レコード型を正の文脈で使う。
+
+
+```rust
+let myadsr_param = {     attack = 100.0,    decay = 200.0,    sustain:float = 0.6, // let 式同様に型注釈は省略可能だ    release = 2000.0,     // 末尾のカンマも許可されるべきだ } let singlerecord = {   value = 100, // フィールドが1つだけのレコードは、ブロックや代入構文と区別するために末尾カンマが必須だ }
+```
+
+後で実装予定だが、型エイリアス／新規型宣言の中でもデフォルト値を設定できる。宣言内のデフォルト値はリテラルである必要がある。
+
+
+```rust
+type alias ADSR = { attack:float  = 100.0, 
+					decay:float   = 200.0,
+					sustain:float = 0.6,
+					release:float = 2000.0, }
+```
+
+各要素へはドット演算子でアクセスするか、let パターンで展開できる。
+
+```rust
+let myattack = myadsr_param.attack  let { attack .. } = myadsr_param  // 変数名はレコード型宣言に依存する
+```
+
+アンダースコアを使った部分適用の構文糖衣を使えば、こんなコードでもたぶん動作する。
+
+
+```rust
+let myattack = myadsr_param |> _.attack  // 型は正しく推論される
+```
+
+
+Elm 由来の「update」構文も加える。ただし区切りにはパイプではなく左アローを使う。
+
+
+```rust
+let newadsr = { myadsr_param <- attack = 4000.0, decay = 2000.0 }  // attack フィールドのみ上書きして新しいレコードを生成
+```
+
+これは以下のような構文糖衣として実装できる。
+
+```rust
+let newadsr = { attack  = 4000.0,
+                decay   = myadsr_param.decay,
+                sustain = myadsr_param.sustain,
+                release = myadsr_param.release, }
+```
+
+
+この展開は型推論後にのみ行える。実装は mirgen 側で行えばいいはず。
+
+## 関数宣言での引数デフォルト値
+
+
+```rust
+fn adsr(attack = 100, decay = 200, sustain:float = 0.7, release = 1000.0) -> float {   
+// 実装…
+}
+// もちろんこれは動作する 
+adsr(200,400,0.5,200)  
+// 以下は許可しない。次のパラメータパックの説明参照 
+adsr() 
+adsr(attack = 200)
+adsr(200)
+```
+
+## レコード型を使った自動パラメータパック
+
+引数が 2 つを超える関数呼び出しでは、
+
+1. 宣言と同じ数の引数
+2. 型の統一ルールに合致する単一のレコード引数
+
+のいずれも許可される。というか、多パラメーター関数は実質的に単一レコード引数関数のエイリアスになる。
+
+
+```rust
+// もちろんOK
+adsr(myadsr_param)  
+// デフォルト引数ですべて評価する
+adsr({ .. }) 
+// オールデフォルトの場合はこれも許して良さそう
+adsr(..)
+```
+
+
+デフォルトパラメーターに対する部分更新構文も許したい。デフォルト値付きと未設定引数を混在させた関数の場合とか。
+
+
+```rust
+fn myugen(freq, phase = 0.0, amp = 1.0) {   // freq は必須 
+	//実装… 
+} 
+myugen({ freq = 200.0 .. })  // これは許可されるはず 
+myugen({ phase = 0.05 .. })  // freq がないのでエラー
+```
+
+右辺値で使う `{ key = val .. }` 構文は、`let` パターン展開と同様に `IncompleteRecord` AST ノードを生成し、その型は `IncompleteRecord` となる。この `IncompleteRecord` 式は、部分適用のアンダースコア同様、引数としてのみ使える想定。
+
+型システムレベルでは、`Record` 型は各フィールドにデフォルト値があるかどうかの情報だけを持ち、値自体は持たない。
+
+型推論では以下のように `Record` と `IncompleteRecord` が統一（unify）される。
+
+
+```rust
+// 疑似コード 
+Record{    [(key:"freq",  type:float, default_v:false),
+			(key:"phase", type:float, default_v:true),
+		    (key:"amp",   type:float, default_v:true)]
+} 
+IncompleteRecord{ [(key:"freq", type:float)] }
+=== unify ===> 
+Record{    [(key:"freq",  type:float, default_v:true),
+			(key:"phase", type:float, default_v:true),
+		    (key:"amp",   type:float, default_v:true)] }
+```
+
+
+型推論の最後まで `IncompleteRecord` が残っているとコンパイルエラーとする?。
+
+そして、単一の `IncompleteRecord` 引数が与えられた場合（ケース2）、mirgen 前の構文糖衣アンラップフェーズで、以下のように更新構文を用いた AST 展開を行う。
+
+```rust
+let default_v = { freq = 0.0, phase = 0.0, amp = 1.0 }   
+// "myugen" の型情報をもとに生成。freq は上書きされるので何でもよい。
+myugen({ default_v <- freq = 200.0 })
+```
+
+
+デフォルト値生成のロジックは、Rust の `Default` トレイトのような制限付き型クラス（インターフェース）を模したものになると思われる。
+
+---
+
+## 部分型と[[型クラス]]
+
+[[構造的部分型]]を採用するつもり。
+
+つまり、
+
+```rust
+fn mysynth(freq,amp,gate){
+	...
+}
+```
+
+みたいな関数に対して
+
+```rust
+let param = {
+   freq:1000,
+   amp:1.0,
+   gate: 1.0,
+   phase: 0.0, //余計なパラメーター
+}
+param |> mysynth //でも、部分型になるのでOK
+```
+
+ということができる。
+
+そして、レコード型のメンバーに関数型を許せば、結局これは型クラスを作ってるのに等しいことになるはず
+
+例えばデフォルト値が次の型クラスの実装となっているとすると
+
+```
+type ADSR = {
+	attack:float,
+	decay: float,
+	sustain: float,
+	release: float
+}
+trait Default{
+	fn default()->Self
+}
+impl Default for ADSR{
+	fn default()->Self{
+		{
+			attack:100,
+			decay: 100,
+			sustain: 0.7,
+			release: 100
+		}
+	}
+}
+```
+
+```
+type alias Default<T>{
+	default: ()->T
+}
+
+let adsr:ADSR = {..}//これが
+let adsr = Default<ADSR>::default() //こうなる
+
+```
+
+隠れ引数として実装されれば、定数畳み込みはできそう
+
+```
+fn default(typeid, parama,paramb)->T{
+	match typeid{
+	...
+	}
+}
+
+
+```
+

content/mimiumの部分的DSP更新とFaustのondemand.md

@@ -0,0 +1,30 @@
+---
+date: 2025-06-18 16:39
+---
+#mimium #memo
+
+[Conditional stateful function call will not handle shiftstate position properly · Issue #71 · mimium-org/mimium-rs · GitHub](https://github.com/mimium-org/mimium-rs/issues/71)
+
+[[mimium]]のif文は選択的にブランチを実行するので、例えば
+
+```rust
+fn dsp(){
+	 if (random()){
+	   gen_a() 
+	 }else{
+	   gen_b()
+	}
+}
+```
+
+のようなコードを書くと、`gen_a`と`gen_b`はそれぞれランダムなサンプルレートで内部を更新するという形になってしまう。
+
+[[Faust]]の`select`プリミティブが両方のブランチを常に評価する戦略を取っている理由はこれを避けるため。
+
+ただ、そういう意味では[[Ondemand primitive for Faust]]をmimiumのif文で再現できるとも言える。
+
+つまり、アップサンプルやダウンサンプルを組み込み関数を新たに定義することなく、ライブラリで定義できる。（サンプルレートの動的な変化とかにどう対応するんだよという問題はあるけど）
+
+内部状態のimplicitな更新は意味論的に結構曖昧なところなのでなんとかしたいなあ
+
+

content/mimiumの配列実装.md

@@ -2,6 +2,20 @@
 date: 2024-09-22 21:15
 ---
 
+## 基本方針
+
+- ヒープに確保する。
+- MIRでリテラル、setarrayelement、getarrayelementみたいな専用命令を作る。
+	- [[LLVM]]みたいにgetelementptrの実装は難しい
+	- なぜなら、VMでのMOV命令がスタックの位置を直接指す実装だから
+- ので、VMにも同じように専用命令を生やす
+	- get/setarrayelementの命令フォーマット
+	- destination,heap上のarray番号,indexの値を指すレジスタ番号
+	- ArrayのワードサイズはVMで確保されたヒープ上に書き込まれていて、インデックス\*ワードサイズの計算はランタイムに行うということでいいかなあ
+
+
+## GCについて
+
 Reference Countにする場合、Dropをどう実装するか
 
 drop_array()、drop_closure()をプリミティブ命令として用意する？

content/obsidian-zotero-integration.md

@@ -0,0 +1,26 @@
+---
+date: "2025-06-18T12:15:00+0900"
+---
+#obsidian #plugin #tools
+
+[GitHub - mgmeyers/obsidian-zotero-integration](https://github.com/mgmeyers/obsidian-zotero-integration)
+
+[[Obsidian]]と[[Zotero]]を連携させるためのプラグイン。以下の機能がある：
+
+- Zoteroデータベースから引用情報を[[Obsidian]]のノートに挿入
+- PDFの注釈をノートに取り込み
+- 文献情報の自動インポート
+- カスタムテンプレートでのノート生成
+- Pandoc citekeysによる引用サポート
+
+## セットアップ
+
+1. Obsidianのプラグイン設定からインストール
+2. Zoteroにはあらかじめ[[BibLaTeX]]プラグインをインストールしておく
+3. テンプレートファイル（例：[[templates/zotero_template]]）を設定
+
+## 使い方
+
+1. コマンドパレットから`Import from Zotero`を実行
+2. 必要な文献を選択してインポート
+3. [[論文の管理]]のワークフローに組み込む

content/otopoiesis.md

@@ -123,6 +123,26 @@ fn reverse(origin:Region)->Region{
 	- 再生前（prepareToPlay)
 	- 信号再生時（process）
 
+## 多段階計算と組み合わせる
+
+[[mimiumと多段階計算]]で、それなりに多段階計算の実装が間に合ってきた。
+
+FadeinOutのようなリージョン→リージョンの関数はステージ0の計算と考えることができる。
+
+また、Generator系も、基本的には周波数や音量といったUIパラメーターは、ステージ0での評価時にUIを生成して値を受け取るチャンネルを作り、ステージ1＝再生中にそのUIからの値を受け取るという方式で捉えられる
+
+```rust
+fn audiofx(param1=100,param2=200){
+	`|input|{... }
+}
+
+fn gen_component(){
+ Param{..} |> sinosc
+}
+```
+`Param`はジェネリックな
+
+
 ---
 以下は昔に考えていたこと
 

content/sapf.md

@@ -0,0 +1,36 @@
+---
+date: 2025-06-26 17:44
+---
+#programming-language 
+
+sapf:Sound as Pure Form
+
+[GitHub - lfnoise/sapf: Sound As Pure Form - a Forth-like language for audio synthesis using lazy lists and APL-like auto-mapping.](https://github.com/lfnoise/sapf)
+
+[[SuperCollider]]を作った[[James McCartney]]が新しく作っている言語。
+
+[[Forth]]や[[APL]]から影響を受けた[[逆ポーランド記法]]が特徴的な言語。[[uiua]]とも近いかも。
+
+
+```sclang
+15 .0 sinosc 200 * 300 + .0 sinosc .1 * play
+```
+
+記法をシンプル（人による）にしたけど内容としてはUGenのメタ操作にかなり向いており、SCに近いと思う。言語としては動的型付けで、配列に関数を自動展開する機能とかがSCのパターン操作とかと同じ感じでよくできてる＆存外VMの実装もシンプルそう。
+
+---
+
+
+オリジナルはmacOSオンリーだが、クロスプラットフォーム向けにフォークしてる人がいる
+
+[sapf - pulusound](https://pulusound.fi/blog/sapf/)
+
+[GitHub - ahihi/sapf: Sound As Pure Form, cross-platform edition](https://github.com/ahihi/sapf)
+
+[first look at sapf (Sound As Pure Form) - YouTube](https://www.youtube.com/watch?v=jN5Ij3Cazh8)
+
+---
+
+この動画短くて簡潔でよかた
+
+[sapf: New Music Language Inspired by Supercollider, APL, and Forth (Sound as Pure Form) - YouTube](https://www.youtube.com/watch?v=FY2WYXOdXoM)

content/お菓子くん.md

@@ -0,0 +1,8 @@
+---
+date: 2025-07-05 15:45
+---
+#research 
+
+会議が煮詰まってくると、机にお菓子を投げ込んでくれるデバイス
+
+ https://ipsj.ixsq.nii.ac.jp/records/183464

content/この研究ノートについて.md

@@ -1,16 +1,16 @@
 ---
 date: "2023-08-10T18:30:08+0900"
 ---
-#obsidian
+#obsidian #notes
 
 - 元々のブログもあるけど、あっちは研究用というよりも、公開して読み物として読んでもらうことを前提にしていて、ちょっと気軽に使いづらい
 - 日付でソートされる必要のないノートがいい（項目ごとに随時アップデートされる）
-- セミオープンなScrapboxとか、HackMD的なやつをセルフホストしたい
+- セミオープンな[[Scrapbox]]とか、[[HackMD]]的なやつをセルフホストしたい
 - なるべくファイルベースの管理がいい
 
-- 自分で管理するWebサイト大体全部Hugoでデプロイしてるので結局Hugoが楽
+- 自分で管理するWebサイト大体全部[[Hugo]]でデプロイしてるので結局Hugoが楽
 
-- 現状[[Quartz]]という[[Obsidian]]で書いたものをなるべくそのまま~~[[Hugo]]でビルドして~~(⇨v4でHugoじゃなくなった)Github Pagesに公開できる仕組みを使っている
+- 現状[[Quartz]]という[[Obsidian]]で書いたものをなるべくそのまま~~[[Hugo]]でビルドして~~(⇨v4でHugoじゃなくなった)[[Github Pages]]に公開できる仕組みを使っている
 - ただし公開の方法はブランチからの公開ではなく最近できた[公式のAction](https://docs.github.com/ja/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0-github-actions-%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%81%AB%E3%82%88%E3%82%8B%E5%85%AC%E9%96%8B)を使うよう自力で改造している
 - これのせいか知らんけど最終編集時刻の反映が上手くいってない
     - もしかするとシングルファイルのコミットのみが反映されてたりするのかも?

content/コンパイラを書く時の悩みについて.md

@@ -0,0 +1,10 @@
+#compiler-design 
+
+- ある程度コンパイラのコードベースが大きくなってくると、認知負荷がでかくなってくる
+- かといって、コードをコンパクトに保とうとすると、一箇所の変更がしづらくなっていく
+	- かといって、頑張ってインターフェースを切って分離性を高めていくと、全体の把握はしづらくなる
+- そりゃ全体を把握しなくいても継続的に開発できるようにするのが目的なのでそうなんだけど
+- 例えば、シンタックスツリーに[[Red Green Syntax Tree]]をあとから使おうとすると、さすがに書き換えが大変
+	- だが、Language Serverを作ろうと思ったらいつかは必要
+	- これをインクリメンタルに開発するのは無理だよなあ
+- 

content/コードフォーマッター.md

@@ -0,0 +1,41 @@
+---
+date: 2025-07-22 17:00
+---
+#programming-language 
+
+一般的なコードフォーマッターの実装について。
+
+[How to write a code formatter](https://yorickpeterse.com/articles/how-to-write-a-code-formatter/)
+
+1行当たり最大文字数がこのくらい、としたときに、どういう戦略で折り返すかは結構難しい問題。
+
+文字列→トークン→ASTという順番で変換されるので、この逆順が良いのかとも思ったが、
+
+AST→フォーマッタ用の専用の木構造みたいな中間表現を一度挟んだほうが賢いのかもしれない
+
+[[Rust]]の[pretty](https://docs.rs/pretty/latest/pretty/)クレートがコンビネーターとして定義してあるやつ
+
+[[Tree-sitter]]を使った汎用フォーマッター[Topiary](https://topiary.tweag.io/)とかいうのもある
+
+---
+
+Exprの途中に差し込まれたトリビア（主にコメント）をどうやって抽出するか
+
+ExprNodeIdに対するSecondary MapがSpanに対して作れているのだから、Trailng Triviaとしてコメントを保持するのは一応できるか？
+
+パーサコンビネータでどうにか処理できるもんか？
+
+```rust
+fn parse_expr_top<Output>()->impl Parser<Token,Output,Error>{
+   not(comment()).padded_by(comment().repeated())
+}
+
+```
+
+[Parser in chumsky - Rust](https://docs.rs/chumsky/latest/chumsky/trait.Parser.html#method.map_with)
+
+`map_with`使えばいけるかしら
+
+Stateにトリビアを書き込んでおけばいいのか
+
+

content/サスティナー.md

@@ -0,0 +1,70 @@
+---
+date: 2025-06-23 16:08
+---
+#guitar #instrument #survey 
+
+弦の振動をピックアップで拾って、増幅して磁気ドライバーを駆動することで、無限のサスティンを得られる楽器。
+
+いくつかタイプがあり
+
+- ハンドヘルド型（ピックアップとコイル、増幅器と電池が入っているいわゆる[[E-Bow]]）
+- ドライバー外付け型（スタンドでグースネック型のドライバにギターを近づける）
+- ドライバー埋め込み型（ピックアップの形をしているけど片方をドライバーとして運用、フェルナンデスとかが有名）
+
+などのバリエーションがある。
+
+ドライバーに使うコイルは一般的にピックアップよりも太いゲージで、巻き数を少なくする。ドライバーコイルをピックアップとしても流用したい場合は、間にトランスを噛ませるような回路を切り替えられるようにする。
+
+[[Michael Krzyzaniak]] ("Metal Marshmallow")がオープンハードウェア化して売っている。
+
+[Metal Marshmallow Contact Mics \| MM DIY Sustainer (DIY Guitar Sustainer)](https://metalmarshmallow.com/product.php?product_id=31)
+
+リポジトリ
+
+http://bitbucket.org/metalmarshmallow/mm-diy-sustainer/
+
+- インプットコイル：AWG42(外径0.06334mm) 7100回巻き 1900Ω@120Hz 534mH
+- アウトプットコイル：AWG32(外径0.2032mm) 600巻 15Ω@120Hz 3.7 mH
+
+マグネット 直径6.32mmぐらい。ギターピックアップの一般的なポールピースが5mmくらいっぽいのでこんなもんかな
+
+[1/4 x 1/4 Inch Neodymium Rare Earth Cylinder Magnets N35 (80 Pack) for Sale \| totalElement](https://totalelement.com/collections/disc-magnets/products/1-4-x-1-4-inch-neodymium-rare-earth-cylinder-magnets-n35-80-pack)
+
+日本だと6mmx2mmの3枚重ねで作り直すのがいいかな
+
+## ハーモニックモードについて
+
+アウトプットコイルの極性が反転するので位相が逆転して一次倍音が消えるっていう説明を良くしてるけど、これ本当か？
+
+これ、実質的にはコイルの出力からそのままグランドに落ちるのがレギュラー、キャパシタを挟むのがハーモニックモードって回路に見える。つまり一次のハイパスフィルターを通してるってだけなのではないか。
+
+ある程度低い周波数がカットされるから次に共鳴しやすい二次の倍音が取り出されるってだけでは
+
+簡単に言えばハーモニックモードの時、直流抵抗15Ω、インダクタンス3.7mH、最後に47uFのキャパシタの直列LCR回路になる
+
+インピーダンスの最小ピークは、 `fpeak =　1/ sqrt( 3.7 * 10^-3  ＊ 47*(10^-6) ) `で大体2400Hzとかになるので、納得いく感じ
+
+E-Bowのよくある回路って間違ってませんか？って動画。この辺でなんか言及されてるのかも
+
+[All Of Those Ebow Schematics You've Seen ARE WRONG! (Part I) - YouTube](https://www.youtube.com/watch?v=yt9RelhYdSo)
+
+EBowは回路的に出力を＋にフィードバックしてるからコンパレーターみたいにしてるのかな
+
+## 雑感
+
+これって、インプットコイルとアウトプットコイルを兼用することってできないのかな
+
+→できそう。Back-EMFの検出というらしい [スピーカーの逆起電力「バックＥＭＦ」ってどう扱うの？｜EXCURIO](https://note.com/excurio_8877/n/na7366990c885) [[Moog Guitar]]で実現されている。
+
+原理的にはこのくらいの回路でも良さそうだな
+
+[AB-021: Measuring RPM from Back EMF - Precision Microdrives](https://www.precisionmicrodrives.com/ab-021)
+
+
+
+---
+
+[[Andrew McPherson]]の[[Magnetic Resonator Piano]]だと1個あたり4オームの電磁石を20Wぐらいのパワーで鳴らしてるらしい（トランスコンダクタンスアンプを自分で実装してるっぽかったけど謎）
+
+ギターの弦なら10Wぐらいでもなんとかなるのかな？というか、やっぱりE-Bowが[[LM386]]で0.7Wとかのパワーであれだけ鳴らせるのがやっぱり不思議というか
+

content/サーキットベンディング.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-12 14:23
+---
+#stub

content/ゾンビ・メディア.md

@@ -0,0 +1,6 @@
+---
+date: 2025-06-12 14:24
+---
+#notion 
+
+[[Garnet Hertz]] and [[Jussi Parikka]]

content/ハーモニクス弦楽器.md

@@ -0,0 +1,43 @@
+---
+date: 2025-06-14 19:46
+---
+#memo #music #instrument 
+
+[[Exidiophone]]を弦でやったらどうなるか
+
+棒の両端にベアリングがついてて、その周りを輪っか状のギター弦がテンション掛けて張ってある
+
+ピックアップ＋エキサイター（[[サスティナー]]）のペアが弦の近くを動ける
+
+弦のうち一箇所に錘がついていて、振動のハーモニクスの位置が弦の回転位置で変えられる
+
+
+トレモロ的な仕組みで、弦全体のテンションも7半音ぐらいまで制御できる
+
+移動フレット的なものをどう作るか
+
+普通のモーターフェーダーだと長さが足りない（6~7フレットで200mmのストロークがあれば良さそう）
+
+普通のサーボだと移動速度が足りるか微妙な気がする
+
+普通のブラシDCモーターのPID制御（回転位置は別途ギアつけて200mmストローク1回転分に変換して、可変抵抗でとるなど）
+
+もしくはブラシレスを行う
+
+[[Smartknob]]を参考にすると良さそう
+
+[Smartknob制作の話（１）｜kawashimaken](https://note.com/kawashimaken/n/n7f1fb098c9f2)
+
+ドライバはTMC6300というの使ってて、Arduino-FOCというのをドライバにできるらしい（PWM線が6本もいるけど）
+
+[Home \| Arduino-FOC](https://docs.simplefoc.com/)
+
+
+Dan bauというベトナムとか中国のモノコードがこれっぽいな
+
+[DAN BAU SELF LEARNING-Tu hoc DAN BAU(DVD+Book)獨弦琴 - YouTube](https://www.youtube.com/watch?v=mqWm2_gOq18)
+
+確かに、気合でフレットが移動するよりも弦のテンションを変える方が楽かもな、、、長さが固定の分倍音制御を特定のフレットの位置でやればいいから
+
+
+

content/パッケージマネージャー.md

@@ -0,0 +1,14 @@
+---
+date: 2025-07-09 19:14
+---
+#programming-language 
+
+言語のライブラリなどをリモートリポジトリから取得、管理する仕組み。
+
+バージョンの依存性解決なども機能のうちに含む。
+
+
+[[Suwa Takashi]]さんの記事がパッケージマネージャとは何かをよく解説してくれている
+
+[パッケージマネージャを自作するときに考えること - gfnweb](https://gfngfn.github.io/ja/posts/2023-02-15-on-creating-package-managers/)
+

content/フィードバック電子管楽器.md

@@ -112,3 +112,11 @@ simple VCF(Qux)
 音量制御も含めて3バクトロールも使っていいならありかなー
 
 これは常にvcc/2でバイアス掛けた状態で送ってるのかな、オーディオ側の電源どうしてるんだろ
+
+### リードを電磁石でフィードバック振動させる
+
+[[サスティナー]]の原理で、ベル側にマイクつけて、シングルリードみたいなのの先端に薄い鉄板をつけたものを作る。それを外側に取り付けた電磁石でマイク信号をフィードバック
+
+唇のバンドパスフィルタとして働く部分をリードを挟む位置でコントロール（これ自体はサックスの原理そのまま）
+
+

content/フォーマット理論.md

@@ -3,4 +3,6 @@ date: "2024-01-29T14:46:44+0900"
 ---
 #notion #studies
 
+[[Jonathan Sterne]]によって立ち上げられた理論。[[MP3 - the meaning of a format]]において物質的な基盤を持たないものに対してもメディア研究のアプローチが有効であることを示す試み。[[メディア考古学]]とも関連。
+
 

content/メディア考古学.md

@@ -3,6 +3,9 @@ date: "2024-01-29T14:46:44+0900"
 ---
 #notion #studies
 
-[[Jussi Parikka]]
+メディアの歴史的発展の探求と考古学的アプローチを組み合わせた研究分野。[[フォーマット理論]]と関連が深い。
 
-[[Jonathan Sterne]]
+主要な研究者:
+[[Jussi Parikka]]
+[[Jonathan Sterne]] - [[MP3 - the meaning of a format]]
+[[Lev Manovich]]

content/分数次フーリエ変換.md

@@ -0,0 +1,8 @@
+---
+date: 2025-06-12 14:49
+---
+#mathematics
+
+[分数次フーリエ変換 - Wikipedia](https://ja.wikipedia.org/wiki/%E5%88%86%E6%95%B0%E6%AC%A1%E3%83%95%E3%83%BC%E3%83%AA%E3%82%A8%E5%A4%89%E6%8F%9B)
+
+

content/型クラス.md

@@ -0,0 +1,15 @@
+#programming-language 
+
+[[Rust]]におけるTraitとかに近いもの
+
+あるメソッド群を持つジェネリックな型の分類
+
+パラメトリックなジェネリクスに対して、対象が広すぎるものを、アドホック多相的に制限する
+
+["Hackett: a metaprogrammable Haskell" by Alexis King - YouTube](https://youtu.be/5QQdI3P7MdY)
+
+この動画の説明わかりやすかった（12:10～）
+
+式をもとに型を生成するのが[[型推論]]、型情報をもとに式を生成するのがジェネリクスというループ
+
+[[Hackett]]

content/多段階計算.md

@@ -32,9 +32,18 @@ http://www.cs.tsukuba.ac.jp/~kam/lecture/gairon2-2012/gairon2.pdf
 
 λ○□：両方を統合
 
+[[SATySFi]]：組版言語だが、マクロのシステムとして多段階計算が導入されている。
+
+[多段階計算の型システムの基礎 - gfnweb](https://gfngfn.github.io/ja/posts/2022-05-12-slides-type-system-matsuri-2020/)([[Suwa Takashi]])
 
 [SATySFi の多段階計算入門](https://sankantsu.hatenablog.com/entry/2022/08/19/215024)
 
+## 用語
+
+**Cross-Stage Persistence**：基本的にステージ0/1でのコードはそれぞれステージ0/1の中でしか使えない。何らかの方法で両方のステージで跨いで使える仕組みを作れると便利
+
+**Run**プリミティブ：
+
 ## [[依存型]]との組み合わせ
 
 [A Dependently Typed Multi-Stage Calculus](https://arxiv.org/abs/1908.02035)

content/多段階計算を命令型VMインストラクションで表現したい.md

@@ -18,9 +18,9 @@ VMは最初、マクロ評価時に自分の現在の評価ステージを0と
 
 VMは、命令記録モードと実行モードの2種類で、現在の評価ステージが0のときに実行モードになる
 
-mainプログラムの先頭はマクロ展開のため必ずincl_levelからスタート＝命令記録モードから開始
+mainプログラムの先頭はマクロ展開のため必ずincr_levelからスタート＝命令記録モードから開始
 
-命令記録モードでは、decl_levelがでてくるまでバッファに実行した命令をコピーし続ける
+命令記録モードでは、decr_levelがでてくるまでバッファに実行した命令をコピーし続ける
 decl_levelでレベル0になったら...うーん
 
 ```ocaml
@@ -62,3 +62,7 @@ endescape
 ret 1
 ```
 
+
+VMの構造にメタプログラミングを埋め込むよりも、MIR生成段階でなにかしらのサンクを呼び出すということにして一時的に空にしておく、みたいなやり方のほうが素直かもな
+
+

content/小数から近い分数を求める.md

@@ -0,0 +1,122 @@
+---
+date: 2025-07-24 17:54
+---
+#memo #mathematics 
+
+例えば、[[双方向プログラミング]]的なもので、数値をスライダーで調整できるようになっていた場合、実際のところは5/7とかわかりやすい有理数だったりとか、整数に近い値を表したいのにめちゃくちゃ長い小数点の数値が残ったりする。
+
+これを、適当なグリッドにスナップするUIの一つとして、許容できる誤差範囲と整数の複雑さを指定して分数に変換するのが良いのではないか。
+
+ChatGPTに聞いた。[[連分数展開]]というのを使うと良いらしい。[[Rust]]のコードを書いてもらった。
+
+```rust
+/// 任意の実数 x を近似する収束分数・半収束分数を求める
+///   x: 近似したい実数
+///   eps: 絶対誤差許容値
+///   max_den: 分母の上限
+///   max_num: 分子の上限
+fn rational_approx(
+    x: f64,
+    eps: f64,
+    max_den: u64,
+    max_num: u64,
+) -> Vec<(u64, u64)> {
+    // 連分数展開の a_k リストを構築
+    let mut a: Vec<u64> = Vec::new();
+    let mut r = x;
+    for _ in 0..64 {
+        let ak = r.floor() as u64;
+        a.push(ak);
+        let frac = r - (ak as f64);
+        if frac.abs() < f64::EPSILON {
+            break;
+        }
+        r = 1.0 / frac;
+    }
+
+    let mut candidates: Vec<(u64, u64)> = Vec::with_capacity(a.len());
+    let (mut p_nm2, mut q_nm2) = (0u128, 1u128);
+    let (mut p_nm1, mut q_nm1) = (1u128, 0u128);
+
+    for &ak in &a {
+        // 収束分数
+        let p = ak as u128 * p_nm1 + p_nm2;
+        let q = ak as u128 * q_nm1 + q_nm2;
+        if q > max_den as u128 { break; }
+        let num = p as u64;
+        let den = q as u64;
+        if num <= max_num {
+            let approx = (num as f64) / (den as f64);
+            if (x - approx).abs() <= eps {
+                candidates.push((num, den));
+            }
+        }
+        // 半収束分数
+        for d in 1..=(ak / 2) {
+            let ap = ak - d;
+            let p2 = ap as u128 * p_nm1 + p_nm2;
+            let q2 = ap as u128 * q_nm1 + q_nm2;
+            if q2 <= max_den as u128 && p2 <= max_num as u128 {
+                let num2 = p2 as u64;
+                let den2 = q2 as u64;
+                let approx2 = (num2 as f64) / (den2 as f64);
+                if (x - approx2).abs() <= eps {
+                    candidates.push((num2, den2));
+                }
+            }
+        }
+        p_nm2 = p_nm1;
+        q_nm2 = q_nm1;
+        p_nm1 = p;
+        q_nm1 = q;
+    }
+
+    candidates.sort_by(|&(p1, q1), &(p2, q2)| {
+        let e1 = (x - (p1 as f64)/(q1 as f64)).abs();
+        let e2 = (x - (p2 as f64)/(q2 as f64)).abs();
+        e1.partial_cmp(&e2).unwrap()
+    });
+    candidates.dedup();
+    candidates
+}
+
+/// x を percent% 精度で近似するラッパー
+///   x: 近似したい実数
+///   percent: 相対誤差許容値（%）
+///   max_num: 分母、分子の上限
+fn rational_approx_pct(
+    x: f64,
+    percent: f64,
+    max_num: u64,
+) -> Vec<(u64, u64)> {
+    let eps = (percent / 100.0) * x.abs();
+    rational_approx(x, eps, max_num, max_num)
+}
+
+fn main() {
+    let x = 2.7182818284;
+    let percent = 1.0; // 1%
+    let max_num = 500;
+    let results = rational_approx_pct(x, percent, max_num);
+    println!("近似候補（percent={}%）:", percent);
+    for (p, q) in results {
+        let approx = p as f64 / q as f64;
+        let err = (x - approx).abs();
+        println!("{}/{} = {:.8}, 誤差 {} ({:.4}%差)",
+            p, q, approx, err, err / x.abs() * 100.0);
+    }
+}
+
+```
+
+```
+近似候補（percent=1%）:
+193/71 = 2.71830986, 誤差 0.00002803075492963103 (0.0010%差)
+106/39 = 2.71794872, 誤差 0.00033311045128181505 (0.0123%差)
+87/32 = 2.71875000, 誤差 0.00046817160000012237 (0.0172%差)
+68/25 = 2.72000000, 誤差 0.0017181716000003178 (0.0632%差)
+49/18 = 2.72222222, 誤差 0.003940393822222443 (0.1450%差)
+19/7 = 2.71428571, 誤差 0.003996114114285465 (0.1470%差)
+```
+
+悪くなさそう（ここから5個ぐらいまでを提示するとして、）

content/新工芸.md

@@ -0,0 +1,10 @@
+---
+date: 2025-06-25 19:22
+---
+#notion 
+
+[PHILOSOPHY  \| SHINKOGEISHA](https://www.shinkogeisha.com/philosophy)
+
+> 日々の生活の中にモノは大量に存在し、ありふれているにも関わらず、僕らはその作り方を知らない。量産技術の発展の末に高度に​分業化が進んだ結果、僕らは自分で使う道具さえ、満足に自分で作ることができなくなってしまった。システムに依存するが余り、進んで歯車としての個々の役割に徹するようになり、知識を狭め、肩書きやブランド、組織の名前に価値を置く一方で、自らの手で完結できる仕事、手で生み出せる喜び、自らに備わった感性に無頓着な態度を社会に蔓延させてしまった。
+
+

content/松浦知也.md

@@ -5,7 +5,7 @@ date: "2023-10-13T11:43:40+0900"
 
 松浦 知也（SoundMaker）
 
-音に関わるメディア・インフラストラクチャ技術を実践を交え批評的にデザインする活動を「音楽土木工学」と称して研究。ハウリングだけで音を出す自作電子楽器「Exidiophone」などを用いての演奏活動、音楽プログラミング言語「mimium」の設計と開発のほか、近年はDIY半導体の制作に取り組む。分担執筆に「クリティカル・ワード　ポピュラー音楽」（フィルムアート社、2022年）。1994年生まれ。2022年九州大学 大学院芸術工学府 博士後期課程修了。同年より東京藝術大学 芸術情報センター 特任助教。
+音に関わるメディア・インフラストラクチャ技術を実践を交え批評的にデザインする活動を「音楽土木工学」と称して研究。ハウリングだけで音を出す自作電子楽器「[[Exidiophone]]」などを用いての演奏活動、音楽プログラミング言語「[[mimium]]」の設計と開発のほか、近年はDIY半導体の制作に取り組む。分担執筆に「クリティカル・ワード　ポピュラー音楽」（フィルムアート社、2022年）。1994年生まれ。2022年九州大学 大学院芸術工学府 博士後期課程修了。同年より東京藝術大学 芸術情報センター 特任助教。
 
 Matsuura Tomoya is SoundMaker: who makes a sound, makes instruments to make a sound, and makes environments to make the instruments. He calls his own research area “Civil Engineering of Music”, which designs socio-technical infrastructure around sound and music critically through practices. He develops “mimium” a programming language for music(2019~), and does performances with “Exidiophone”, an electro-acoustic instrument that makes sound with only an audio-feedback. Currently working as Project Assistant Professor at Art Media Center in Tokyo University of the Arts.
 

content/機械学習とピッチ補正.md

@@ -0,0 +1,19 @@
+---
+date: 2025-06-13 09:20
+---
+#research #survey #machinelearning
+
+[[知覚的擬似直接操作]]について考えていることの下調べ
+
+[\[1902.00956\] Deep Autotuner: A Data-Driven Approach to Natural-Sounding Pitch Correction for Singing Voice in Karaoke Performances](https://arxiv.org/abs/1902.00956)
+
+[[Sanna Wager]]
+
+[DIFF-PITCHER: DIFFUSION-BASED SINGING VOICE PITCH CORRECTION](https://engineering.jhu.edu/lcap/data/uploads/pdfs/waspaa2023_hai.pdf)
+
+[NEURAL PITCH-SHIFTING AND TIME-STRETCHING WITH CONTROLLABLE LPCNET](https://www.maxrmorrison.com/pdfs/morrison2022neural.pdf)
+
+音楽における[[Style Transfer]]の特殊系と考えてもいいかも
+
+
+

content/炭酸亜鉛.md

@@ -3,6 +3,7 @@ date: "2023-09-14T22:02:36+0900"
 ---
 #semiconductor #material
 
+前駆体として[[酸化亜鉛]]薄膜を形成する際に使われる材料。[[酢酸亜鉛]]とともに[[DIY半導体-実験ノート1]]で使用。
 
 ##### Bioinspired macromolecular templates for crystallographic orientation control of ZnO thin films through zinc hydroxide carbonate
 

content/知覚的擬似直接操作.md

@@ -0,0 +1,28 @@
+---
+date: 2025-06-12 13:32
+---
+#memo #computermusic #notion
+
+Perceptual (Pseudo-Direct) Manipulation
+
+オーディオの領域においては、厳密な意味での[[Direct Manipulation]]は存在しない。
+
+GUIベースのオーディオ操作ソフトは、イラストレーターの図のように出力される結果を直接操作しているわけではなく、音を生成するシステムのメタファーを直接操作している。
+
+ただ、「直接」と呼ぶに値するワークフローとして、[[Auto-Tune]]のようなインタラクティブなピッチ補正のシステムが挙げられる。
+
+これは、厳密に表現をするのであれば、
+
+- 一度オーディオからピッチを分析して、
+- そのピッチのカーブをGUIで編集し、
+- - ピッチカーブの差分データと元のオーディオデータを組み合わせて、望ましいピッチを出力するようなオーディオデータを逆方向に計算
+
+しているのだと言える。
+
+では、このワークフローをピッチ分析以外にも、リバーブの量であったり、和音の種類だったり、声の明るさのような、より複雑なデータに対しても適用できないだろうか？
+
+幸いにも機械学習分野でのさまざまな研究をもとにして、[[Variational Autoencoder]](VAE)を応用すればこの仕組みに近いことができるはずだ。
+
+
+
+

content/莱孝之.md

@@ -0,0 +1,4 @@
+---
+date: 2025-06-14 10:29
+---
+#stub

content/酸化亜鉛.md

@@ -11,6 +11,8 @@ https://www.amazon.co.jp/dp/B006ZSV13G/
 
 前駆体溶液自体は金属亜鉛よりこっちスタートの方がいいのかな(直接溶かすと時間がかかる上に不純物がいっぱい析出する)
 
+[[炭酸亜鉛]]を経て生成される。[[色素増感太陽電池]]の材料としても使われる。
+
 亜鉛と塩酸の反応速度 : 反応に伴って生成される黒色物質の影響について / 	工藤 貞重  /	研究報告 / 新潟県立教育センター
 
 巻 9, p. 17-24, 発行日 1976-03-30

content/音楽プログラミング言語.md

@@ -19,6 +19,7 @@ date: "2024-01-05T17:15:38+0900"
 	- [[Overtone]]
 	- [[TidalCycles]]
 	- [[FoxDot]]
+- [[sapf]]
 - [[Csound]]
 - [[Extempore]]
 - [[ChucK]]
@@ -27,7 +28,8 @@ date: "2024-01-05T17:15:38+0900"
 - [[Vult]]
 - [[Gwion]]
 - [[Glicol]]
-
+- [[Omni]]
+- [[Arco]](Serpent)
 
 ---