Merge remote-tracking branch 'origin/v4' into v4
All checks were successful
Build / build (push) Successful in 24m17s
All checks were successful
Build / build (push) Successful in 24m17s
This commit is contained in:
10
content/.obsidian/graph.json
vendored
10
content/.obsidian/graph.json
vendored
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"collapse-filter": false,
|
||||
"search": "",
|
||||
"showTags": true,
|
||||
"showTags": false,
|
||||
"showAttachments": false,
|
||||
"hideUnresolved": false,
|
||||
"hideUnresolved": true,
|
||||
"showOrphans": true,
|
||||
"collapse-color-groups": false,
|
||||
"colorGroups": [
|
||||
@@ -53,13 +53,13 @@
|
||||
"collapse-display": false,
|
||||
"showArrow": true,
|
||||
"textFadeMultiplier": 0,
|
||||
"nodeSizeMultiplier": 1.19899088541667,
|
||||
"lineSizeMultiplier": 1,
|
||||
"nodeSizeMultiplier": 1.276,
|
||||
"lineSizeMultiplier": 1.13454545454545,
|
||||
"collapse-forces": false,
|
||||
"centerStrength": 0.468912760416667,
|
||||
"repelStrength": 15.1642583672965,
|
||||
"linkStrength": 0.975453871804372,
|
||||
"linkDistance": 42,
|
||||
"scale": 0.25087828132711953,
|
||||
"scale": 0.518331174460362,
|
||||
"close": true
|
||||
}
|
||||
8
content/AMY.md
Normal file
8
content/AMY.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
date: 2026-01-16 09:26
|
||||
---
|
||||
組み込み環境での動作を目指したソフトウェアシンセサイザー。
|
||||
|
||||
Python、MicroPythonが動く環境なら動くし、[[Arduino]]でも動くらしい。
|
||||
|
||||
[GitHub - shorepine/amy](https://github.com/shorepine/amy)
|
||||
7
content/ChuMP.md
Normal file
7
content/ChuMP.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
date: 2026-01-12 09:20
|
||||
---
|
||||
[[ChucK]]言語のパッケージマネージャ。
|
||||
|
||||
[ChuMP: The ChucK Manager of Packages](https://chuck.stanford.edu/chump)
|
||||
|
||||
@@ -28,4 +28,4 @@ shredという論理時間ベースの計量スレッドみたいなものを言
|
||||
|
||||
Chugenという独自[[Unit Generator|UGen]]をChucK言語上で定義するための機能もある（[[Csound]]におけるUser-Defined OpCode）。
|
||||
|
||||
パッケージマネージャが2025年ぐらいになって導入された。
|
||||
[[パッケージマネージャー]]が2025年ぐらいになって導入された。
|
||||
|
||||
@@ -91,7 +91,7 @@ Maxのようなビジュアルプログラミング環境はポピュラーで
|
||||
|
||||
> "As opposed to the acoustic instrument maker, the designer of the composed digital instrument frames affordances through symbolic design, thereby creating a snapshot of musical theory, freezing musical culture in time." ("Of Epistemic Tools: musical instruments as cognitive extensions", Thor Magnusson, Organized Sound 14-2, p173 (2009))
|
||||
|
||||
コンピューター音楽の研究者[[Thor Magunusson]]は、コンピューターで作る楽器のことをEpistemic Toolと呼びました。
|
||||
コンピューター音楽の研究者[[Thor Magnusson]]は、コンピューターで作る楽器のことをEpistemic Toolと呼びました。
|
||||
|
||||
これは、コンピューターを使った楽器のデザインやそれの使用が常にシンボルを通じた操作となるため、根本的にその時代の音楽文化を埋め込んだシンボルを経由することを指しています。よりシンプルに言えば、アコースティックな楽器と比べると、コンピューターを使う楽器や音楽作成システムは誤用に基づくオルタナティブな表現の追求が困難である、と言えます。
|
||||
|
||||
|
||||
12
content/DynGen.md
Normal file
12
content/DynGen.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: 2026-01-14 14:52
|
||||
---
|
||||
#computermusic #programming
|
||||
|
||||
[[SuperCollider]]で[[EEL2]]([[Cockos]]の作っている、[[Reaper]]で使える[[JSFX]]の内部言語)を使えるようにした拡張機能。
|
||||
|
||||
[GitHub - capital-G/DynGen: Run dynamic scripts on a SuperCollider server](https://github.com/capital-G/DynGen)
|
||||
|
||||
[DynGen - Dynamic UGen - jamshark70 の #9 - Libraries and Quarks - scsynth](https://scsynth.org/t/dyngen-dynamic-ugen/12518/9)
|
||||
|
||||
|
||||
10
content/EEL2.md
Normal file
10
content/EEL2.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
date: 2026-01-14 14:54
|
||||
---
|
||||
#computermusic
|
||||
|
||||
[[Reaper]]で使える内部スクリプティング言語、[[JSFX]]のコア言語。
|
||||
|
||||
[WDL/WDL/eel2 at main · justinfrankel/WDL · GitHub](https://github.com/justinfrankel/WDL/tree/main/WDL/eel2)
|
||||
|
||||
|
||||
4
content/ESP.md
Normal file
4
content/ESP.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
date: 2026-01-16 09:25
|
||||
---
|
||||
#stub
|
||||
@@ -3,7 +3,7 @@ date: "2024-02-05T13:10:19+0900"
|
||||
---
|
||||
#software
|
||||
|
||||
Mac（と最近はLinux）用のCLIパッケージマネージャー。
|
||||
Mac（と最近はLinux）用のCLI[[パッケージマネージャー]]。
|
||||
|
||||
自分でインストール用のスクリプト(ruby)を書いて野良リポジトリをホストすることもできる。
|
||||
|
||||
|
||||
4
content/JSFX.md
Normal file
4
content/JSFX.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
date: 2026-01-14 14:54
|
||||
---
|
||||
#stub
|
||||
12
content/MTRと録音の民主化.md
Normal file
12
content/MTRと録音の民主化.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
date: 2026-01-15 13:32
|
||||
---
|
||||
[[民主化]]
|
||||
|
||||
[ミュージシャンたちが愛した、歴史に残るギターの名器20選 \| Rolling Stone Japan(ローリングストーン ジャパン）](https://rollingstonejapan.com/articles/detail/32556?n=2&e=34124)
|
||||
|
||||
メイド・イン・ジャパンは誰をエンパワーしたのか？ 日本の楽器メーカーがもっと誇るべき話 [[若林恵]]
|
||||
|
||||
> MTRと録音の民主化ということで言えば、US版『WIRED』の元編集長の[[クリス・アンダーソン]]も同じような話をしていて、彼は『MAKERS―21世紀の産業革命が始まる』という本のなかで3Dプリンターなどの[[デジタルファブリケーション]]ツールを用いた「製造の民主化」を謳ったんですが、彼自身がそのDIY精神をどこで培ったか、というとバンド活動を通じてだったと証言しています。
|
||||
|
||||
> ところが、[[椎野秀聰|椎野]]さんが想定していたような「創造性の解放」は実は日本ではなかなか起きなかった、というのが椎野さんの見立てで、本当はみんなが楽器を手にするようになったら、みんなが誰も聴いたことのないような新しい音楽をつくり始めるんじゃないかと期待してたら、案外多くの人が「コピーバンド」に走ってしまったわけです（笑）。
|
||||
@@ -9,10 +9,17 @@
|
||||
|
||||
[GitHub - moonbitlang/moonbit-compiler](https://github.com/moonbitlang/moonbit-compiler)
|
||||
|
||||
日本だと[[mizchi]]さんが全力で使っている
|
||||
|
||||
> 元 Meta で BuckleScript | [[ReScript]] を開発していた [[Hongbo Zhang]] 氏がチーフアーキテクト。
|
||||
|
||||
[自分が Moonbit 言語について知っていること](https://zenn.dev/mizchi/articles/practical-moonbit)
|
||||
|
||||
あ、そうなんだ
|
||||
> 元 Meta で BuckleScript | [[ReScript]] を開発していた [[Hongbo Zhang]] 氏がチーフアーキテクト。
|
||||
|
||||
そうなんだ
|
||||
|
||||
[MoonBit 最高 2025](https://zenn.dev/mizchi/articles/moonbit-is-good-2025)
|
||||
|
||||
[MoonBit が WebAssembly 時代の理想(の原型)だった](https://zenn.dev/mizchi/articles/introduce-moonbit)
|
||||
|
||||
|
||||
|
||||
4
content/Python.md
Normal file
4
content/Python.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
date: 2026-01-12 08:24
|
||||
---
|
||||
#stub
|
||||
@@ -11,5 +11,5 @@ date: 2024-10-29 14:08
|
||||
|
||||
> ### メンテナンスから生活へ
|
||||
>
|
||||
> 従来のソフトウェア開発プロセスでは、_開発_ と _保守_ を厳密に分離していました。 これは、常に進化するシステム (たとえば、常に進化する Twitter のようなシステム) について話す場合はそうではありませんが、その場合でも、そのようなシステムはプログラマが保守されるとみなすコンポーネントで構成されています。 上記で示唆したように、アレクサンダーの考え方は（従来のアーキテクトの考え方とは対照的に）、この2つを別個のフェーズと見なさない考え方により適していると思う。
|
||||
> 従来のソフトウェア開発プロセスでは、_開発_ と _保守_ を厳密に分離していました。 これは、常に進化するシステム (たとえば、常に進化する Twitter のようなシステム) について話す場合はそうではありませんが、その場合でも、そのようなシステムはプログラマが保守されるとみなすコンポーネントで構成されています。 上記で示唆したように、[[Christopher Alexander|アレクサンダー]]の考え方は（従来のアーキテクトの考え方とは対照的に）、この2つを別個のフェーズと見なさない考え方により適していると思う。
|
||||
> _成長_ という観点から、より有機的な思考に移行することは、明らかに技術的な問題だけでなく、社会的な問題でもある。 社会的な側面は、最近出版された[イノベーションの妄想](https://amzn.to/3CKtmfL "The Innovation Delusion: How Our Obsession with the New Has Disrupted the Work That Matters Most - Lee Vinsel, Andrew L. Russell")という本の主題である。 この本では、「『進歩』を『イノベーション』に置き換えることで、目新しさが改善であるかどうかという問題を回避することができる」という事実など、いくつかの素晴らしい指摘がなされている。 この本の重要なポイントは、[オープンソースソフトウェア](https://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/)だけでなく、家事労働などの分野でも、社会がイノベーションとメンテナンスをどのように評価するかの不均衡が大きな問題につながっているということだ。
|
||||
@@ -2,3 +2,5 @@
|
||||
date: 2025-06-13 09:55
|
||||
---
|
||||
#person
|
||||
|
||||
[[Epistemic Tools]]
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
date: 2025-01-29 14:35
|
||||
---
|
||||
#person
|
||||
|
||||
[[Epistemic Tools]]
|
||||
8
content/Tulip.md
Normal file
8
content/Tulip.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
date: 2026-01-16 09:24
|
||||
---
|
||||
[[MicroPython]]で動く[[AMY]]というシンセサイザーを搭載したポータブルコンピューター。[[ESP32]]ベースらしい。
|
||||
|
||||
[Tulip Creative Computer. Now available](https://tulip.computer/)
|
||||
|
||||
|
||||
14
content/Zooko Triangle.md
Normal file
14
content/Zooko Triangle.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
date: 2026-01-12 08:53
|
||||
---
|
||||
#notion
|
||||
|
||||
[[パッケージマネージャー]]を分散型設計にするときに問題になること。
|
||||
|
||||
> - **Human-meaningful**: short, memorable names like `express` or `rails`
|
||||
> - **Decentralized**: no central authority controls who gets what name
|
||||
> - **Secure**: when you ask for `express`, you get the real one, not a malicious package that happens to share the name
|
||||
|
||||
これら3つを全て同時に達成することは不可能であるというジレンマ。
|
||||
|
||||
[Federated Package Management and the Zooko Triangle | Andrew Nesbitt](https://nesbitt.io/2025/12/21/federated-package-management.html)
|
||||
@@ -7,7 +7,7 @@ date: 2024-12-02 16:21
|
||||
|
||||
東工大（科学大）で研究されている、組み込みシステム向けの[[Functional Reactive Programming]]を想定した言語
|
||||
|
||||
`x@last`という演算子でxの直前の時刻の計算結果を利用できる（[[mimium]]の`self`に近しい機能）
|
||||
`x@last`という演算子でxの直前の時刻の計算結果を利用できる（[[mimium]]の`mem`と`self`に近しい機能）
|
||||
|
||||
もともとは再帰データ型を許さない、高階関数を許さないことで有限なメモリサイズを保証していたが、最大サイズを型として指定することでリストのような再帰データ構造を部分的に許す拡張などが行われている
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#memo #mimium
|
||||
|
||||
|
||||
(v3で導入済み。)
|
||||
|
||||
- [[多段階計算を命令型VMインストラクションで表現したい]]
|
||||
- 一時期考えていたが、あんまり筋が良くないのでやめた
|
||||
@@ -29,16 +29,18 @@ $$
|
||||
|
||||
$$
|
||||
\begin{align}
|
||||
e ::=
|
||||
&\quad R & R \in \mathbb{R} [number]&\\
|
||||
|&\quad e \ e \quad& [app]&\\
|
||||
e ::= &\quad R & R \in \mathbb{R} [number]&\\
|
||||
|&\quad \lambda x.e& [abs]&\\
|
||||
|&\quad let\; x\; =\; e\; in\; e& [let]&\\
|
||||
|&\quad fix\; x.e & [fixpoint]&\\
|
||||
|&\quad e \ e \quad& [app]&\\
|
||||
|&\quad if\; (e_c) \; e_t\; else\; e_e & [if] &\\
|
||||
|&\quad delay(x,e_{time},v_{bound})&[delay]&\\
|
||||
|&\quad mem(e) &[mem]&\\
|
||||
|&\quad feed\ x.e &[feed]&\\
|
||||
|&\quad `(e) &[quote]&\\
|
||||
|&\quad $(e) &[splice]&
|
||||
|&\quad $(e) &[splice]&\\\
|
||||
|& \ ...
|
||||
\end{align}
|
||||
$$
|
||||
|
||||
|
||||
Submodule content/private updated: 5e000b1417...9ffef16b9c
@@ -1,9 +1,10 @@
|
||||
---
|
||||
date: 2025-01-07 15:45
|
||||
---
|
||||
|
||||
#DTP
|
||||
#DTP #software
|
||||
|
||||
Texに代わる？モダンな組版システム。[[Rust]]で書かれている。
|
||||
|
||||
[Typst: Compose papers faster](https://typst.app/)
|
||||
[Typst: Compose papers faster](https://typst.app/)
|
||||
|
||||
オープンソースだが、共同編集機能などを備えたWebアプリは一部機能プロプライエタリ。
|
||||
5
content/uv.md
Normal file
5
content/uv.md
Normal file
@@ -0,0 +1,5 @@
|
||||
|
||||
[[Rust]]で書かれた[[Python]]向けパッケージマネージャ
|
||||
|
||||
[uv: Unified Python packaging](https://astral.sh/blog/uv-unified-python-packaging)
|
||||
|
||||
@@ -3,4 +3,7 @@ date: 2025-01-15 16:10
|
||||
---
|
||||
#book
|
||||
|
||||
> 一八世紀の暖炉からレンガ一辺が落ちても、家族のだれかがモルタルを練ってレンガを埋める方法を知っていたであろう。これに比較して、二〇世紀の電気オーブンの電熱線がゆるんだら、家族のだれかがどうしたらよいか知っていたり、適当な修理用品を持っていることはありえないであろう。この意味で、家事労働をする人は自分が使う道具から疎外されているのであり、工場の組み立てラインや溶鉱炉で働く人の労働が疎外されているのと同様である。（p5）
|
||||
|
||||
[[ルース・シュウォーツ・コーワン]]
|
||||
|
||||
> 一八世紀の暖炉からレンガ一辺が落ちても、家族のだれかがモルタルを練ってレンガを埋める方法を知っていたであろう。これに比較して、二〇世紀の電気オーブンの電熱線がゆるんだら、家族のだれかがどうしたらよいか知っていたり、適当な修理用品を持っていることはありえないであろう。この意味で、家事労働をする人は自分が使う道具から[[疎外]]されているのであり、工場の組み立てラインや溶鉱炉で働く人の労働が疎外されているのと同様である。（p5）
|
||||
15
content/なぜ働いていると本が読めなくなるのか - 三宅香帆.md
Normal file
15
content/なぜ働いていると本が読めなくなるのか - 三宅香帆.md
Normal file
@@ -0,0 +1,15 @@
|
||||
#book
|
||||
|
||||
[[三宅香帆]]著
|
||||
|
||||
思っていた以上に「○○は××である」ではなく、「○○していきましょう/するべき」方の本であった。
|
||||
|
||||
とはいえ、読んでいくとこの本自体が自己啓発本の歴史研究のまとめといった側面もあり、自己変革を常に要求する自己啓発本のフォーマットを借りながら、結論は「こういう社会に変えていきましょう」というストレートな社会運動啓発にひっくり返すというフォーマットを取っている。それゆえにフェミニズムの本でもある（「半身社会」という言葉は[[上野千鶴子]]の発言から引かれている）。
|
||||
|
||||
一方で悩ましいのは、答えを著者がストレートに出してくれるという点ではストレートな自己啓発本と同じという点でもある（これ言い出すとすべてのアクティビズムな本がそうではあるんだが）。
|
||||
|
||||
あと、これ「疲れ」についての本でもあるよな（[[Diminished Faculties - Jonathan Sterne]]を思い出した）。
|
||||
|
||||
単なる肉体的な労働に基づく肉体的な疲れ以外の「何かが/に疲れている」がすなわち[[燃え尽き症候群]]ということになるのだろうし、燃え尽き症候群を社会モデル的な障害として捉えてみましょう、というのがこの本の内容と言えるのかもしれない。
|
||||
|
||||
というときに、この本で語られる燃え尽き症候群の先にあるのがうつ病である、というお話がそこで止まってしまっているのはちょっとナイーブすぎるようにも思えた。精神病や発達障害はどこまで社会モデルでとらえられるのだろうか？というお話に繋がってくる部分だと思うので。
|
||||
11
content/なぜ社会は変わるのか 初めての社会運動論 - 富永京子.md
Normal file
11
content/なぜ社会は変わるのか 初めての社会運動論 - 富永京子.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
date: 2026-01-16 14:21
|
||||
---
|
||||
#book
|
||||
|
||||
[[富永京子]]
|
||||
|
||||
研究としてのアクティビズムの分析ってどこから入ればいいのかずっと分からなかったので非常に良い本。
|
||||
|
||||
社会運動を眺める側が社会運動を作り出している一部なのかもしれない、という話として読んだ。
|
||||
|
||||
@@ -25,7 +25,7 @@ date: 2025-12-25 15:43
|
||||
|
||||
自分が楽器（ソフト込み）を作ったり、演奏するときに使う楽器で好きなものは、中身の構造がわかっているのにそのコントロールができない、先の挙動の完全な予測ができない、というタイプのものだ。これは特にフィードバック構造を持つものに顕著に現れるのでよくオーディオフィードバック＝ハウリングをよく使う理由でもある。
|
||||
|
||||
楽器は一種の道具だ。道具はよく身体を延長、拡張するものだと言われるが、これがある程度自律的に動く、またコントロール不可能になるにつれて自分の身体の延長から新たな身体とのコミュニケーションに近いようなところが出てくる。わかりやすいところでいえば、Siriのような音声コントロールがそうだし、コントロール不可能性というところを含めるとキャラクターがインターフェースのメールソフトPostpetはメールを時々誤配する。
|
||||
楽器は一種の道具だ。道具はよく身体を延長、拡張するものだと言われるが、これがある程度自律的に動く、またコントロール不可能になるにつれて自分の身体の延長から新たな身体とのコミュニケーションに近いようなところが出てくる。わかりやすいところでいえば、Siriのような音声コントロールがそうだし、コントロール不可能性というところを含めるとキャラクターがインターフェースのメールソフト[[Postpet]]はメールを時々誤配する。
|
||||
|
||||
|
||||
要するに自分の場合のプレイヤーモードというのはこの（ディス）コミュニケーションみたいなものに向き合うことだと思っている。
|
||||
@@ -36,7 +36,7 @@ date: 2025-12-25 15:43
|
||||
ところで「プレイヤーモード」のまま聴くこともできるなら改めて「リスナーモード」を音楽制作や演奏にもきちんと取り入れられるのではないだろうか、と思って1年前ぐらいから時々音楽のようなものを作るようになった。自分の「リスナーモード」の方を噛み砕くと、「製作者にまつわるパーソナルななにか」と「音楽における構造的ななにか」という2つの要素がポップミュージックを形作っていると考えている。
|
||||
|
||||
|
||||
とりあえず前者については一旦置いておくにして、後者はつまり、時々言われる気がするけどポップミュージックとは建築的なものだと思う。全体の骨組みがあって、それを更に細かな構造が覆っていくようなもの。というかこの考えは自分のものでもなくてブライアン・イーノが生成的音楽に対して建築からガーデニング的なものへ変わっていくという例えそのまんまである。 https://wired.jp/2018/03/01/brian-eno-ar-installation/
|
||||
とりあえず前者については一旦置いておくにして、後者はつまり、時々言われる気がするけどポップミュージックとは建築的なものだと思う。全体の骨組みがあって、それを更に細かな構造が覆っていくようなもの。というかこの考えは自分のものでもなくて[[Brian Eno|ブライアン・イーノ]]が生成的音楽に対して建築からガーデニング的なものへ変わっていくという例えそのまんまである。 https://wired.jp/2018/03/01/brian-eno-ar-installation/
|
||||
|
||||
|
||||
しかしこれを自分のプレイヤーモードに納めようと思うとうまくいかない。全体の骨組みを作るにも大きな木を削って大黒柱を作るようなやり方ではなく勝手にわさわさ成長していく木を剪定して頑張って形を整える。まさにガーデニングの例えというか、盆栽とかそういう感じに近いのだろうか。
|
||||
@@ -52,7 +52,7 @@ date: 2025-12-25 15:43
|
||||
|
||||
もうちょっと具体的なことを書くと、クリスマスツリーのもみの木にあたる部分はディレイ（音を遅らせるエフェクト）をちょっと複雑にしたもので、音を5個ぐらいに分岐させて、それぞれ基準を1秒だとして1/2,2,3,5(正確な数字は忘れたが)など整数倍に遅れ時間を設定している。遅れた音はそれぞれいい感じにミックスされてまた5個に分配される。のでただのループともちょっと違うリズムのようなものが生まれる。
|
||||
|
||||
ここに入力したのは物理モデリングのギターシンセ（AAS String Studio）を一音だけ弾いたもので、妙にアタックが強調された音が作れるのでよく使う。途中からそれぞれ遅れ時間を0.01%とかだけランダムにずらしていて、遅れ方がそれぞれちょっとだけずれて重なっていき、だんだんアタックがぼやけてくる。このぼやけた状態の音がギターを弾いてる音からバイオリンを弓で擦ってるような音に、最後にはドローンのようなボワーっとした音にときれいにモーフィングするのを偶然発見したのでこの音を使うことにした。後半では遅れ時間を少しずつ短くすることでドローンのピッチを上げていっている。これは録音を回しておいてMaxをリアルタイムで操作して録音したので実質再現不可能。
|
||||
ここに入力したのは物理モデリングのギターシンセ（AAS String Studio）を一音だけ弾いたもので、妙にアタックが強調された音が作れるのでよく使う。途中からそれぞれ遅れ時間を0.01%とかだけランダムにずらしていて、遅れ方がそれぞれちょっとだけずれて重なっていき、だんだんアタックがぼやけてくる。このぼやけた状態の音がギターを弾いてる音からバイオリンを弓で擦ってるような音に、最後にはドローンのようなボワーっとした音にときれいにモーフィングするのを偶然発見したのでこの音を使うことにした。後半では遅れ時間を少しずつ短くすることでドローンのピッチを上げていっている。これは録音を回しておいて[[Max]]をリアルタイムで操作して録音したので実質再現不可能。
|
||||
|
||||
|
||||
このモーフィングから始めたので、他のところもモーフィングとか、（硬派なタイプの）ミニマル的なじわっと変化するやり方をたくさん使うことにした。のでDAW上でオートメーションをひたすら書く作業が曲作りという感じになっている。
|
||||
|
||||
@@ -39,23 +39,6 @@
|
||||
|
||||
カリキュラムは全体として、コンピューティングの概念と基礎理論を理解するためのパート、Arduinoのチュートリアルパート、最終課題制作のパートと3つに分かれており、最終課題以外は概ね1コマごとに1WSを実施するような構成になっている。
|
||||
|
||||
|
||||
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
|
||||
@@ -97,11 +80,23 @@
|
||||
|
||||
前半のまとめ
|
||||
|
||||
## 後半：Arduinoの実用
|
||||
## 後半：実用的電子工作
|
||||
|
||||
後半は、Arduinoを使ったプログラミングを用いての電子制御
|
||||
### Arduinoの基礎
|
||||
|
||||
後半の初回では、芸術家・デザイナー向けのマイクロコントローラー環境Arduinoの入門を行う。本授業では、大学で用意したArduino、ブレッドボード、ACアダプタ、ジャンパワイヤセット、FET、LED、抵抗、タクトスイッチ、赤外線距離センサー、12cmファン等をまとめたオリジナルのキットを使用する（これは、以前のコードとデザインから使われていたものである）。
|
||||
|
||||
学生はこの回で初めてテキストベースのプログラミング環境に触れるので、改行やスペースの扱い、行末のセミコロン、全角と半角などプログラミングの基礎的な知識についても注意して教える必要がある。
|
||||
|
||||
教える内容としては例えば、赤外線反射式のアナログ距離センサーを用いて、アナログ入力をシリアルプロッタに出力する例から初め、それをFETのスイッチングを経由して、PWMでファンのスピード制御に変換する例までを2コマで学ぶ。
|
||||
|
||||
### 秋葉原遠足
|
||||
|
||||
Arduinoの基礎的な使い方を学んだ後、次の実習では秋葉原を探索し、電子部品屋を巡り実際に使えそうなセンサーやアクチュエータなどのパーツを購入してみる。
|
||||
|
||||
ここでは代表的な電子部品店を紹介し、学生は秋葉原まで移動後、小グループに分かれ自分たちで店を巡る（大人数で一度に押しかけて店の迷惑にならないように注意する）。
|
||||
|
||||
この授業では上野と秋葉原という地理的に近しい場所にあるにも関わらず、文化的にはあまり接点のない2つの街の歴史的経緯についても事前に解説する。明治時代から文化の中心地として開拓されてきた上野と、戦後ヤミ市の整理によって高架下に集まった電気・電子部品屋という異なる由来を理解することで、東京藝術大学という場所で電子工作を用いた作品制作を行う意味について思索を広げてもらう。
|
||||
|
||||
### 雑なマウスを作る
|
||||
|
||||
@@ -117,16 +112,63 @@ Arduino Uno R3以前のAVRベースのものを使用する場合、HIDエミュ
|
||||
|
||||
本授業では2022年度はR3、2023年度以降はR4を用いたので以上の方法を使い分けた。
|
||||
|
||||
この実習での狙いは、普段自分たちが使っているコンピューターの入力のインターフェースもArduinoとスイッチなどこれまで作ってきたものの延長線で自作できることを実感し、インタフェースというコンピューターと身体を接続する界面が以下に制作物に影響を与えうるかについて理解することである。
|
||||
この実習での狙いは、普段自分たちが使っているコンピューターの入力のインターフェースもArduinoとスイッチなどこれまで作ってきたものの延長線で自作できることを実感し、インタフェースというコンピューターと身体を接続する界面が以下に制作物に影響を与えうるかについて理解することである。授業内では、1952のDATARで使用された最初のトラックボールや、ダグラス・エンゲルバートによる最初期のマウスなどインターフェースの歴史についても触れる。
|
||||
|
||||
自作マウスが完成した後は、そのマウスを使ってブラウザゲームをプレイしたり、Photoshopのような普段使用している制作ソフトを使用してお絵描きをするなどして、普段の操作環境との違いを身体で実感する。例えば上下左右キーをベースにしたマウスでは、原則45度単位での移動しかできないため、描けるグラフィックもそれに沿ったものになる。小課題として、これら制作したマウスで操作した結果（ゲームプレイ中の画面録画やPhotoshopで制作した画像など）を提出する。
|
||||
|
||||
## 簡易PONGゲームの制作
|
||||
### 簡易PONGゲームの制作
|
||||
|
||||
この実習では、ArduinoとProcessingを組み合わせて、簡易的なPongゲームを制作する。
|
||||
|
||||
この授業では、直接Arduinoのコードを書く代わりに、Firmataというシリアル通信仲介ライブラリを使用することで、Processing内に直接Arduinoの操作コードを記述する方法を学び、デスクトップアプリケーションとArduinoの組み合わせ方について学ぶ。
|
||||
この授業では、直接Arduinoのコードを書く代わりに、Firmataというシリアル通信仲介ライブラリを使用することで、Processing内に直接Arduinoの操作コードを記述する方法を学び、デスクトップアプリケーションとArduinoの組み合わせ方について学ぶ。また、PONGゲームという最小限のゲームの作り方を通じて、Processingで使われているJavaという言語とArduinoで用いられるC++の違いを知りつつ、両者に共通するオブジェクト指向プログラミングのコンセプトをある程度理解することも一つの目標である。
|
||||
|
||||
授業内では、Tennis for Two、MITのSpacewar!、Atari PONGなどの電子計算機を遊びに用いた実例を交えつつ、ビデオゲームという遊びのためのコンピューターへと発展していく歴史も紹介する。
|
||||
|
||||
Processingだけで一人用PONGゲームを制作した後、Arduinoを経由してバーの操作を可変抵抗にしたり、ゲーム開始/やり直しのボタンをタクトスイッチに変えて遊ぶことで、インターフェースの違いが生む体験の差を身体で実感する。
|
||||
|
||||
### 音声・モーターのプログラミング
|
||||
|
||||
第10回、11回目の授業の中では、学生から需要の高いトピックに応える目的で、Arduinoでの音声プログラミングやモーターの制御方法について教えている。この部分は、初回授業でアンケートを取るなどして毎年少しづつ内容を調整している。
|
||||
|
||||
音声プログラミングでは、音を電気信号として扱う基本的な概念の説明ののち、Arduino標準のtone関数を用いた音声出力について学び、Arduino向け音声合成ライブラリMozziを使った基本的な信号処理についても触れる。Mozziは使用しているArduinoのバージョンによって使用できるピンの番号や数が変化するため注意が必要となる。
|
||||
|
||||
モーター制御では、小型のファンをFETを用いPWMで速度制御する例を通じて基本的な制御方法を学ぶほか、小型サーボモーターSG90の操作を通じて、ArduinoのServoライブラリで任意の角度への回転を行う方法も学ぶ。例年ある程度重量のあるものを動かす需要が高いため、トルクの概念とモーターの選定方法を簡単に解説するほか、回転運動から直動への変換など機構設計の基礎についても軽く触れる。
|
||||
|
||||
### デジタルファブリケーション
|
||||
|
||||
この回は、センサーやアクチュエーターをデジタルファブリケーションの技術を用いて自作することで、入出力の造形的自由度を高めることを目的とする。
|
||||
|
||||
この授業の元となっているのは、MIT Media Labで[[Hannah Perner-Wilson]]が行なっていた[[Kit of No Parts]]というプロジェクトである。例えば、スピーカーは渦巻状の電極に磁石を近づけることで簡易的に形成することができるが、この電極は例えば導電糸で布に縫い付けたり、銅箔テープをカッティングプロッタで加工したり、エッチングや鋳造など、複数の方法で造形することができる。実際に授業内では、レーザーカッターで加工したアクリル部品と、カーボンベースの導電塗料、銅箔テープなどを組み合わせて簡易的な可変抵抗を制作する。限られた授業時間内の中ではあるが、レーザーカッターやカッティングプロッターなど、デジタルデータを用いて物理的な造形を行う装置の基本的な使い方についても習得できるのが望ましい。
|
||||
|
||||
|
||||
### 最終課題制作に向けた相談
|
||||
|
||||
最終課題制作に向けた相談を主とする回は、展示準備と講評の回を除いて2回設けてある。これらの回では、15分程度の区切りで教員と助手それぞれにオフィスアワーの時間を事前に予約できるようにしておき（予約が埋まっていなければ当日その場で相談も可）、それ以外の時間は自主的な制作時間にするのを基本とする。
|
||||
|
||||
電子工作を用いる制作には、部品調達の時間が必要となること、また大型の作品は教室で作業ができないこともあるため、事前に申請を行った上で授業終了時にその日の作業内容について報告することで、教室外での作業も許可するようにした。
|
||||
|
||||
また、電子工作については部品の選定後トライアンドエラーの結果新たな部品調達が必要となることもままあるため、1回目の課題制作相談の前に、プロジェクトシートの記入を事前課題として設けている。これは、作品概要、スケッチ、展示に必要な大きさ、必要な材料と部品リスト、制作スケジュールを記述したものである。
|
||||
|
||||
このプロジェクトシートは、制作進行のガイドとして使用するほか、教員が展示のレイアウトや機材の貸し出しなどのプランを練るのに使用する目的も兼ねており、また制作を進めるたびにその進捗も記入し、また最終課題発表後には展示の様子の写真や制作の感想なども記入し最終課題提出の証拠としての提出も課している。結果として、作品制作全体のドキュメントとして学生自身が後から見返す、また他の制作でも同様のプロジェクトマネジメントのテンプレートとして使用できることを想定している。
|
||||
|
||||
## 課題講評と評価基準
|
||||
|
||||
授業全体の評価基準として、事前にシラバスで共有される基準として、出席率を30%、小課題点を30%、最終課題点を40%として評価する。小課題の評価は基本的には提出の有無のみ（期限を過ぎての提出は70%）で評価する。
|
||||
|
||||
最終課題の評価は、前述の通り課題の
|
||||
|
||||
## 授業設計全体の反省点
|
||||
|
||||
前述した通り、本授業は筆者がSFPCで受けた授業内容を基に再構成したものである。その思想の源流を逆順に辿っていくと、SFPCが所在しているニューヨークで行われた、Experiments in Art and Technologyを代表とする1960年代のテクノロジーアートシーンがあり、E.A.Tに関わった多くの人（ロバート・ラウシェンバーグやジョン・ケージ）が関わった実践的なリベラルアーツの学校であるBlackMountain Collegeがあり、さらに上流にはBMCを主導したジョセフ/アニ・アルバース夫妻が参加していたバウハウスのような学校や、生活としての芸術や実学的教育を指向したアメリカの思想家ジョン・デューイなどに繋がる[@Taeyoon2016]。
|
||||
|
||||
本授業の設計にあたっても、参加者が単に技術的なチュートリアルに追随するのではなく、なぜテクノロジーを学ぶのか、どうやったら日常生活の中に、些細であったとしても、ありものを探してくるだけでなく、自分で道具を作ってみるところから始めるという発想をインストールできるかという点を重視して設計し、そうした目標に関してはある程度達成できたように思われる。
|
||||
|
||||
一方で、BMCやSFPCで行われていた教育の重要な点の一つは、参加者自体が自発的に学校の運営に携わる姿勢である。BMCでは農作業や家畜の世話などの生活レベルでの学校参加が行われていたし、SFPCに関しても基本的に1日ごとに1トピックを集中して扱い、じっくり課題に向き合う時間が取られていたほか、生徒同士で教え合うための時間や工夫が散りばめられていた。90分x2x15コマというフレームがあらかじめ定められている上に、必修の授業でもないという本授業の前提がある中で、こうした学びのフレームワーク自体の大局的な見直しに関しては十分に行えなかったのが現実である。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
また、PONGゲームという最小限のゲームの作り方を通じて、Processingで使われているJavaという言語とArduinoで用いられるC++の違いを知りつつ、両者に共通するオブジェクト指向プログラミングのコンセプトをある程度理解することも一つの目標である。
|
||||
|
||||
|
||||
|
||||
10
content/ナラティヴの被害学 - 阿部幸大.md
Normal file
10
content/ナラティヴの被害学 - 阿部幸大.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
date: 2026-01-16 16:25
|
||||
---
|
||||
#book
|
||||
|
||||
by [[阿部幸大]]
|
||||
|
||||
[[まったく新しいアカデミック・ライティングの教科書]]のある種実践編として書かれた書で、筆者がアメリカ留学中に執筆したレポート・論文を中心に、それらを独立した章として収録してある。
|
||||
|
||||
ただそれを説明した最初のこの本でいうナラティヴとは何か、被害額(victimology)とは何か、を説明した章だけでも読む価値はあった。各章冒頭に筆者自身による各章の書評がついているのだが、自分で自分の論文の論理構成をボロクソに批判してるので面白い。
|
||||
@@ -7,8 +7,33 @@ date: 2025-07-09 19:14
|
||||
|
||||
バージョンの依存性解決なども機能のうちに含む。
|
||||
|
||||
[[パッケージマネージャーはコミュニケーションツールである]]
|
||||
|
||||
[[パッケージマネージャーは音楽ストリーミングサービスになる]]
|
||||
|
||||
---
|
||||
|
||||
[[Suwa Takashi]]さんの記事がパッケージマネージャとは何かをよく解説してくれている
|
||||
|
||||
[パッケージマネージャを自作するときに考えること - gfnweb](https://gfngfn.github.io/ja/posts/2023-02-15-on-creating-package-managers/)
|
||||
|
||||
---
|
||||
|
||||
[[Andrew Nesbitt]]がたくさん解説している
|
||||
|
||||
[Package Management Blog Posts | Andrew Nesbitt](https://nesbitt.io/2026/01/09/package-management-blog-posts.html)
|
||||
|
||||
この中で面白かったもの
|
||||
|
||||
[Package Manager Design Tradeoffs | Andrew Nesbitt](https://nesbitt.io/2025/12/05/package-manager-tradeoffs.html)
|
||||
|
||||
[[Zooko Triangle]]
|
||||
|
||||
[[Go]]のパッケージ管理システムを作った[[Sam Boyer]]による記事
|
||||
|
||||
[So you want to write a package manager | by sam boyer | Medium](https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527)
|
||||
|
||||
[[開発者のためのハームリダクション]]
|
||||
|
||||
[[uv]]
|
||||
|
||||
|
||||
28
content/パッケージマネージャーはコミュニケーションツールである.md
Normal file
28
content/パッケージマネージャーはコミュニケーションツールである.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
date: 2026-01-12 08:48
|
||||
---
|
||||
#thoughts
|
||||
|
||||
[The Cutting Edge of Versioning (LambdaConf 2024) — Sympolymathesy, by Chris Krycho](https://v5.chriskrycho.com/elsewhere/cutting-edge-of-versioning/)
|
||||
|
||||
> **バージョン管理はコミュニケーションツールである**
|
||||
|
||||
> **バージョン管理は*社会技術的契約*である：**
|
||||
|
||||
パッケージマネージャが導入されることで初めてプログラミング言語はインターネットで繋がれたツールになる。
|
||||
|
||||
パッケージマネージャは自動で問題を解決してくれるわけではない。なぜなら問題を管理する人間が不完全だからである。
|
||||
|
||||
バージョン管理は通常[[Semantic Versioning]]で管理されるが、メジャーバージョンは互換性とは別にマーケティング的都合で動かされることもままある。作者がパッチバージョンとマイナーバージョンを間違えてタグづけることもある。Gitで操作した履歴とパッケージマニフェストのバージョン番号が不整合なこともある。
|
||||
|
||||
どっちかというとこれらの不整合の責任を分離するツールとも言えるかもしれない。
|
||||
|
||||
例えば[[Homebrew]]は技術的にはあまり良くできたパッケージマネージャではない。どれが依存パッケージかの区別がないので管理が面倒だし、ロックファイルもない(Pythonツールのresourcesのやり方は少しロックファイルっぽいが）。なので基本的にどのツールも複数バージョンの共有を許さないため、依存ツール間でバージョンの不整合が起きると死ぬことがある。だがなんだかんだ割とよく使われてて成立している。それがなぜかというと、Pull Requestベースのレビューでリポジトリが中央集権管理されていて、また管理がよく行き届いていてユーザーが多いから、というややトートロジー的な理由である。
|
||||
|
||||
不整合は起きるかもしれないが、起きたら起きたでユーザーからの報告がすぐ届いて、対応も早い。運用でうまいことツールの不出来さをカバーしている。そのぐらいの複雑度だから多くの人が運用に参加できているとも言える。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
42
content/パッケージマネージャーは音楽ストリーミングサービスになる.md
Normal file
42
content/パッケージマネージャーは音楽ストリーミングサービスになる.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: 2026-01-12 09:13
|
||||
---
|
||||
#thoughts
|
||||
|
||||
[[音楽プログラミング言語]]における[[パッケージマネージャー]]の設計を考えると、パッケージマネージャーとはSpotifyのような音楽ストリーミングサービスになりうるポテンシャルがあると思う。
|
||||
|
||||
一般的にパッケージマネージャは依存ライブラリのバージョン管理に使われるが、[[npx]]や[[Rust]]の[[cargo]]は何かツール（例えば[[wasm-pack]]とか[[clippy]]とかもそうだ）バイナリのインストールにも使える。では音楽プログラミング言語の実行バイナリとは何かと言われれば、音楽作品そのものである。音楽にはリミックスという文化もあるので、実行バイナリとして配布されているツールをさらに改変して新しい曲を作ることだって考えられる。
|
||||
|
||||
今ある音楽プログラミング言語でパッケージマネージャを持つものは多くはないが以下の通りである。
|
||||
|
||||
- [[Max]] : 確か7くらいから導入された。レジストリは中央集権、cycling74のレビューを通過したものが収録される。
|
||||
- [[PureData]]: [[deken]]というtcl/tkで書かれたマネージャが0.47あたりで導入。これのおかげで、ユーザーライブラリを多数収録して配布するのに管理が複雑になっていたPd-extendedは役目を終えた。パッケージは中央集権管理、レビューあり。
|
||||
- [[SuperCollider]]: [[Quarks]]という、SC言語自体で書かれたパッケージマネージャがある。レジストリはGitHub上で管理された中央集権インデックスと、個々のパッケージはGitHub上のそれぞれのアカウント下のリポジトリに置かれる。
|
||||
- [[ChucK]]: 最近[[ChuMP]]というパッケージマネージャが導入された。パッケージのマニフェストファイルもChucK言語で書ける（最終的にはJSONにエンコードされる）。パッケージ一覧はGitで中央集権管理。
|
||||
|
||||
基本、こうした音楽言語用のパッケージマネージャは「完成した作品配布」の目的で作られたものは今のところない。
|
||||
|
||||
既存のパッケージマネージャエコシステムを音楽配布のアナロジーで考えると、レジストリ：レコード会社、パッケージauthor：作曲者ということになる。
|
||||
例えばレーベルとかは既存のパッケージマネージャでは少し当てはめづらい概念かもしれない。なぜならレーベルはときにレコード会社を跨ぐこともあるし、複数のアーティストが複数のレーベルから作品を出版することもある。この辺はChatGPTに聞いたら、秘密鍵をローテーションで持ち回れるような仕組みを作って、署名付き出版履歴を作るのがレーベルに対応するのではないかということ。確かに？
|
||||
|
||||
アルバムとかは、実行バイナリを複数含んで指定の順番で再生するような仕組みがあれば実現できそうだ。だがこの場合コンピレーションアルバムのような複数authorが個別の作曲者である場合のデータベース管理とかはややこしくなる。それぞれのパッケージをキュレーションしてアルバムとして再配布するような仕組みもあってもいいかもしれない。
|
||||
|
||||
依存するパッケージのライセンス情報をトラックできるのもパッケージマネージャの旨みではあるが、ついでに考えるならメタデータとして演奏者の情報なども埋め込みたい。もし収益が発生したらそれを分配するための基盤としても使えるかもしれない。
|
||||
|
||||
有料でデータをやり取りするようなこともあり得るのだろうか？
|
||||
|
||||
音楽の場合は、他のパッケージマネージャよりもマルチレジストリな設計の方が腑に落ちるかも。レジストリ間でパッケージIDが被った場合は同じものとして扱うべきか？という問題は残る。レジストリ間での連動みたいなことは考えられるのか？
|
||||
|
||||
---
|
||||
|
||||
音楽プレイヤーのようにパッケージを再生する場合、そのUXはどのようなものが適切か。まず`mmmpm play <package-id>`のようなコマンド一発で曲が即時再生されて欲しい。裏側ではパッケージを`~/.mmmpm/cache/`みたいなところにダウンロードしてそれを実行するような形になる。PCMベースのストリーミングと違って、ファイルをチャンクに分けてDLすることができないのは難しいポイントだ（WAVのパーツを切り貼りするようなインタラクティブミュージックだと、普通のPCMよりデータ量は多くなるかもしれない）。
|
||||
|
||||
また、エンドレスな曲の場合再生停止をどうするという問題もある。
|
||||
|
||||
やはり専用のGUIアプリは必要になるかもしれない。というか、開発用のローカルなパッケージ管理に関するUIと曲の再生に関わるUIは結局分けないといけないのかもしれない。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,3 +2,7 @@
|
||||
date: 2025-09-17 09:55
|
||||
---
|
||||
#stub
|
||||
|
||||
- [[YACC]]([[Bison]])
|
||||
- [[Tree-Sitter]]
|
||||
- [[Lady Deirdre]]
|
||||
|
||||
@@ -18,6 +18,7 @@ date: 2024-04-02 15:37
|
||||
- 完全に個人じゃないけど[生存学のarsvi.com](http://www.arsvi.com/)
|
||||
- これも1959年の本を写した内容ではあるが [Basic Audio-Norman Crowhurs](http://www.vias.org/crowhurstba/)
|
||||
- [MAD研究所](https://madlabo.oops.jp/MAD/index2.htm)[^miyashita]
|
||||
- [Asylum in Silence](http://www.asyluminsilence.halfmoon.jp/)
|
||||
|
||||
## 参考
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ https://logmi.jp/tech/articles/324146
|
||||
MetaOCaml を使った自己反映言語のコンパイル 浅井 健一 (Black )
|
||||
http://www.is.ocha.ac.jp/~asai/jpapers/ppl/asai14.pdf
|
||||
|
||||
メタプログラミングのための時相論理に基づく型付 λ 計算 湯瀬 芳洋 五十嵐 淳
|
||||
メタプログラミングのための時相論理に基づく型付 λ 計算 湯瀬 芳洋 [[五十嵐淳]]
|
||||
http://www.fos.kuis.kyoto-u.ac.jp/~igarashi/papers/pdf/lambdaCB-PPL05.pdf
|
||||
|
||||
筑波大学 論理と計算（2）
|
||||
@@ -42,7 +42,21 @@ http://www.cs.tsukuba.ac.jp/~kam/lecture/gairon2-2012/gairon2.pdf
|
||||
|
||||
**Cross-Stage Persistence**：基本的にステージ0/1でのコードはそれぞれステージ0/1の中でしか使えない。何らかの方法で両方のステージで跨いで使える仕組みを作れると便利
|
||||
|
||||
**Run**プリミティブ：
|
||||
[multi-stage-programs-in-context.pdf](https://mpickering.github.io/papers/multi-stage-programs-in-context.pdf)
|
||||
|
||||
Path Based Persistence: グローバルレベルで定義されたシンボルはどのステージでも使えるようにする
|
||||
|
||||
Serialisation-based persistence
|
||||
|
||||
各プリミティブにliftという関数を用意して、値→値リテラルのコードを変換できるようにする。構造体などは各フィールドを再帰的にliftしたものになる。
|
||||
|
||||
問題は関数丸ごとリフトするような一般的な方法がないことである。
|
||||
|
||||
例えばこんなコードだったら
|
||||
|
||||
``let x = `(x+1) ``
|
||||
|
||||
``let x = `($(lift(x) + 1))` ``であってほしい。これは構文木を再帰的に辿れば一応できそう
|
||||
|
||||
## [[依存型]]との組み合わせ
|
||||
|
||||
@@ -58,6 +72,15 @@ https://link.springer.com/chapter/10.1007/978-3-030-34175-6_4
|
||||
この辺はなんかやりたいことに近そうな予感がする
|
||||
|
||||
|
||||
## [[モジュール]]システムとの組み合わせ
|
||||
|
||||
[A Research Talk at FLOPS 2024: An ML-Style Module System for Cross-Stage Type Abstraction in Multi-Stage Programs - gfnweb](https://gfngfn.github.io/posts/2024-05-18-slides-flops2024/)
|
||||
|
||||
[[Suwa Takashi]]
|
||||
|
||||
|
||||
|
||||
|
||||
## [[Rust]]でのプログラム合成
|
||||
|
||||
https://fitzgeraldnick.com/2018/11/15/program-synthesis-is-possible-in-rust.html
|
||||
|
||||
@@ -7,7 +7,7 @@ date: 2025-10-30 17:14
|
||||
|
||||
2026年度 未踏アドバンスト
|
||||
|
||||
[[未踏アドバンスト2026応募内容]]
|
||||
[[private/未踏アドバンスト2026応募内容]]
|
||||
|
||||
## 2019年度 未踏IT人材発掘・育成事業
|
||||
|
||||
|
||||
@@ -1,56 +0,0 @@
|
||||
|
||||
プロジェクト名：音楽流通プラットフォームとしての、音楽プログラミング言語向けパッケージマネージャの開発
|
||||
|
||||
合計5～10ページ以内
|
||||
|
||||
## プロジェクトの背景、目的、目標
|
||||
|
||||
このプロジェクトは申請者が2019年度未踏IT人材発掘・育成事業で開発した音楽プログラミング言語mimiumを、さらなる社会実装のために機能拡張するものである。
|
||||
|
||||
今回実装するのは、この言語向けのパッケージマネージャ、すなわちネットワークを介してユーザーがコードを交換できる仕組みである。パッケージマネージャは一般的に、ライブラリのバージョン管理などを目的として設計されるが、本プロジェクトでは、パッケージマネージャの役割を拡大解釈して、コードで生成される音楽を流通させるためのインフラストラクチャとして機能することを目指す。
|
||||
|
||||
パッケージマネージャは以下のようなエコシステムで構成される。
|
||||
|
||||
まず、Node.jsにおけるnpmなどと同じように、ソースコードを管理、配布するためのサーバー、レジストリが存在する。レジストリには、複数のパブリッシャーがアカウントを登録し、ソースコードをアップロード、公開する。公開名義は、個々のパブリッシャーにすることも可能だが、複数のパブリッシャーをグループ化した、パブリッシャーグループ名義で公開もできる。
|
||||
|
||||
このレジストリ、パブリッシャー、パブリッシャーグループは、既存の音楽流通エコシステムにおける、レコード会社、ミュージシャン、レーベルというアナロジーで捉えることができる。
|
||||
|
||||
ソースコードはサーバ上でGit LFSを用いてバージョン管理される。
|
||||
|
||||
バージョン同士の依存関係は、npmやRustにおけるCargoのように、依存ライブラリおよびそのバージョンの宣言を設定ファイルに書き込み、ビルド時に自動でロックファイルが生成される。
|
||||
|
||||
|
||||
|
||||
|
||||
## 開発に関する未踏性の主張、期待される効果など
|
||||
|
||||
従来の音楽プログラミング言語においては、そもそもパッケージマネージャが存在しない言語も多く、存在しているものとしても、Maxのパッケージマネージャ、Pure Dataのdeken、SuperColliderのQuarks、ChucKのパッケージマネージャなどが存在するが、いずれも目的はライブラリの管理であり、その言語を使って作られた音楽はライブ演奏か録音して配布することが主である。
|
||||
|
||||
音楽をプログラムとして流通、配布するアイデアとしては、CSoundを発展させたMPEG-Structure Audioとして規格化されたSAOLなどが古くから存在するものの、広くは普及しなかった。2000年代には、黎明期のTwitterで、SuperColliderを用いて140文字以内で音楽を作り投稿する#SC140といったムーブメントなどがあったが、より大規模な音楽配布として発展することはなかった。
|
||||
|
||||
今回提案するmimium言語では、これら既存の取り組みと比較して、言語が強く形式化されていることで、多くのプリミティブな機能（オシレーターやフィルターなど）をmimium言語上で定義でき、CやC++などネイティブバイナリのライブラリへの依存が少なく、パッケージマネージャを用いた音楽配布に適した設計になっている。また、WebAsssemblyを通じたWeb上での実行も実現しており、ポータビリティも高い。
|
||||
|
||||
|
||||
|
||||
|
||||
## 開発の具体的な進め方
|
||||
|
||||
|
||||
## 提案者の実力・能力を示す実績（スキル・経験・受賞歴等）及びそれに基づくプロジェクトの実現性
|
||||
|
||||
提案者は、2019年度の未踏IT人材育成・発掘事業で本提案の基となるmimium言語を開発しており、スーパークリエータ認定を受けている。また事業終了後も継続してmimiumの開発を続け、ACM SIGPLAN FARMや、情報処理学会プログラミングシンポジウムなどで論文発表を行い、後者では山内奨励賞を受賞している。
|
||||
|
||||
音楽向けのプログラミング言語の開発には、言語設計およびオーディオプログラミングという異なる2つのドメイン知識が求められ、世界的にもこれを専門とする研究者の数は非常に限られている。
|
||||
|
||||
|
||||
|
||||
|
||||
## 事業化・社会実装の新規性・優位性、想定するターゲットと規模
|
||||
|
||||
## 事業化・社会実装の具体的な進め方
|
||||
|
||||
## 事業期間終了後の事業化・社会実装に関する計画
|
||||
|
||||
## 予算内訳のまとめ
|
||||
|
||||
|
||||
16
content/椎野秀聰.md
Normal file
16
content/椎野秀聰.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
date: 2026-01-15 13:34
|
||||
---
|
||||
#person
|
||||
|
||||
[[ESP]]と[[Vestax]]を立ち上げた人。
|
||||
|
||||
[ベスタクスの夢──椎野秀聰と世界を変えるものづくり \| WIRED.jp](https://wired.jp/special/2017/hidesato-shiino/)
|
||||
|
||||
|
||||
> 「それまで音楽っていうのは特別に訓練された人たちのものだったわけでしょう。でもロックは違った。エレキギターというのは、誰でも自分のクリエイティヴィティを自由に解放することができるツールなんだって思ったんですよ。これで世界は変わるんだって」
|
||||
|
||||
|
||||
> 椎野はわずか数年で特にあてもなく[[ヤマハ]]を退社、大手楽器卸しのひとつだった[[神田商会]]の紹介で、楽器製造メーカーだった[[富士弦楽器]]製造にデスクを得ることになる。
|
||||
|
||||
|
||||
26
content/物語化批判の哲学 〈わたしの人生〉を遊びなおすために - 難波優輝.md
Normal file
26
content/物語化批判の哲学 〈わたしの人生〉を遊びなおすために - 難波優輝.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
date: 2026-01-16 14:22
|
||||
---
|
||||
#book
|
||||
|
||||
[[難波優輝]]
|
||||
|
||||
難波さんの文章にはいつもそのインプットの量と横幅の広さに驚かされる。年間読書人の書評ではそれが衒学的だと批判されているけど、むしろこのくらいが本来の学術的な態度だと思う(もっと必要のないところで必要のない引用をしている人はいくらでもいる)
|
||||
|
||||
[難波優輝 『物語化批判の哲学 〈わたしの人生〉を遊びなおすために』 ： 著者は意外に〈いいやつ〉、そこが肝心。｜年間読書人](https://note.com/nenkandokusyojin/n/ndfeb4689d7a1)
|
||||
|
||||
これもかなり批判的な書評。
|
||||
|
||||
[難波優輝『物語化批判の哲学』への批判｜なさぎ](https://note.com/nasagi/n/n10bc68822f9e)
|
||||
|
||||
> 本書は「物語化批判」を冠しているものの、実際には全てを批判し、全てを擁護している、という事になるだろう。
|
||||
|
||||
この点は的を得た指摘であり、難波さんの文章ってだいたいそうだよなと思う。それが難波さんの文章の好きなとこでもあり、嫌いなところでもある。
|
||||
|
||||
難波さんの文章はいつでも正論だし、正論すぎてその態度を実践するにはそれなりのストイックさが求められるから鼻をつままれるところはあるのだろう。私が時々苦手に思うのは私自身がどちらかと言えば正論パンチャーであり同族嫌悪に近いものだから。
|
||||
|
||||
と、途中まで読んだ感想がそういう感じだったのだが、最後の章のおもちゃ的態度については少しフックを感じた。おもちゃ的な態度としての倫理観とは、責任感を持たないという責任を持つこと、という話。
|
||||
|
||||
これは少し共感できる話で、[[中途半端さの徹底はできない]]ということをよく考えている。何かを極めてしまうよりも中途半端でい続けることのほうが余程難しい、そして人はなるべくそのように生きるべきであるという根拠なき確信を私は持っているのだけど、そこに対する別解のように最後の章は読むことができた。
|
||||
|
||||
ところで、この本のテーゼとリンクするのは[[阿部幸大]]の[[ナラティヴの被害学 - 阿部幸大|ナラティヴの被害学]]かも。
|
||||
@@ -1,3 +1,8 @@
|
||||
#cooking
|
||||
|
||||
ライ麦の種にすりおろし玉ねぎ使うレシピって他探しても全然出てこないけどどこ由来なんだろう（最終的にドライイーストも使ったり卵も入ってたりでハードブレッドっぽくないのも不思議なレシピ）
|
||||
|
||||
---
|
||||
|
||||
ライ麦パンの作り方
|
||||
＊初種の作り方
|
||||
@@ -6,29 +11,12 @@
|
||||
玉ねぎすりおろし小さじ1
|
||||
水930cc
|
||||
|
||||
日数
|
||||
ライ麦
|
||||
水
|
||||
|
||||
1日
|
||||
30g
|
||||
30cc
|
||||
すり玉ねぎ小さじ1
|
||||
2日
|
||||
60g
|
||||
60cc
|
||||
|
||||
3日
|
||||
120g
|
||||
120cc
|
||||
|
||||
4日
|
||||
240g
|
||||
240cc
|
||||
|
||||
5日
|
||||
480g
|
||||
480cc
|
||||
日数 ライ麦 水
|
||||
1日 30g 30cc すり玉ねぎ小さじ1
|
||||
2日 60g 60cc
|
||||
3日 120g 120cc
|
||||
4日 240g 240cc
|
||||
5日 480g 480cc
|
||||
|
||||
|
||||
6日目
|
||||
@@ -41,23 +29,25 @@
|
||||
300gずつの6袋でもいい。
|
||||
|
||||
ライ麦パン
|
||||
|
||||
【材料】
|
||||
初種1袋
|
||||
強力粉400g
|
||||
牛乳160cc
|
||||
卵1個
|
||||
イースト小さじ2〜約6g
|
||||
砂糖20g
|
||||
塩5g
|
||||
バター40g
|
||||
|
||||
- 初種1袋
|
||||
- 強力粉400g
|
||||
- 牛乳160cc
|
||||
- 卵1個
|
||||
- イースト小さじ2〜約6g
|
||||
- 砂糖20g
|
||||
- 塩5g
|
||||
- バター40g
|
||||
|
||||
初種を解凍 自然に置いてもいいし水につけてもいい
|
||||
|
||||
1.強力粉の中へ砂糖イーストを加え混ぜる。塩を入れて混ぜる
|
||||
1. 強力粉の中へ砂糖イーストを加え混ぜる。塩を入れて混ぜる
|
||||
くぼみをつけてほぐしておいた卵と牛乳100ccを入れ、周りからゆっくりかき混ぜていく
|
||||
2.牛乳と卵がぼろぼろと混ざり出し粉はまだ残っている状態のところへ初種を混ぜ込んでいく
|
||||
2. 牛乳と卵がぼろぼろと混ざり出し粉はまだ残っている状態のところへ初種を混ぜ込んでいく
|
||||
混ざりにくければ残りの牛乳を少しずつ入れていく
|
||||
3.まだ固いかなと思うくらいの状態でバターを混ぜ、様子をみながらニーダーに入れて捏ねる
|
||||
3. まだ固いかなと思うくらいの状態でバターを混ぜ、様子をみながらニーダーに入れて捏ねる
|
||||
|
||||
捏ね終わったら1/2ずつに分けてビニール袋に入れる
|
||||
|
||||
|
||||
@@ -51,6 +51,11 @@ date: "2024-02-05T12:49:01+0900"
|
||||
|
||||
[[デザインにできないこと - シルビオ・ロルッソ]]
|
||||
|
||||
[[なぜ働いていると本が読めなくなるのか - 三宅香帆]]
|
||||
|
||||
[[なぜ社会は変わるのか 初めての社会運動論 - 富永京子]]
|
||||
|
||||
[[物語化批判の哲学 〈わたしの人生〉を遊びなおすために - 難波優輝]]
|
||||
|
||||
### 読みたいものリスト
|
||||
|
||||
|
||||
5
content/開発者のためのハームリダクション.md
Normal file
5
content/開発者のためのハームリダクション.md
Normal file
@@ -0,0 +1,5 @@
|
||||
|
||||
[Harm reduction for developers](https://jvns.ca/blog/2014/11/18/harm-reduction-for-developers/)
|
||||
|
||||
> switching out YOU’RE WRONG TO DO THAT JUST DON’T DO THAT for _doing something to help people be safer_
|
||||
|
||||
4
content/阿部幸大.md
Normal file
4
content/阿部幸大.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
date: 2026-01-16 16:25
|
||||
---
|
||||
#person
|
||||
4
content/難波優輝.md
Normal file
4
content/難波優輝.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
date: 2026-01-16 14:22
|
||||
---
|
||||
#person
|
||||
Reference in New Issue
Block a user