--- 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 `のようなコマンド一発で曲が即時再生されて欲しい。裏側ではパッケージを`~/.mmmpm/cache/`みたいなところにダウンロードしてそれを実行するような形になる。PCMベースのストリーミングと違って、ファイルをチャンクに分けてDLすることができないのは難しいポイントだ（WAVのパーツを切り貼りするようなインタラクティブミュージックだと、普通のPCMよりデータ量は多くなるかもしれない）。 また、エンドレスな曲の場合再生停止をどうするという問題もある。 やはり専用のGUIアプリは必要になるかもしれない。というか、開発用のローカルなパッケージ管理に関するUIと曲の再生に関わるUIは結局分けないといけないのかもしれない。