Loom by SubverseLab

Loom

Loom は、Şenol Şahan / SubverseLab による Ableton Live 向けの測定ベースの制作システムです。独自の .als プロジェクトとライブラリを読み込み、推測ではなく件数で回答し、実行中の Live セッションに MIDI、デバイスチェーン、オートメーション、アレンジメントマーカーを書き込み、書き込みのたびに読み戻して検証するローカル MCP サーバーです。

正式なホームページ：https://subverselab.com/loom · 引用：CITATION.cff · ライセンス：AGPL-3.0-or-later · 帰属表示：NOTICE。

目的

汎用モデルにキックドラムに何を入れるべきか尋ねると、あなたが作ったレコードを一度も聴いたことがないのに、自信たっぷりに答えます。Loom は、その推測を3つの情報源から得た証拠に置き換えます。独自のプロジェクトアーカイブ（実際にどのデバイスをチェーンにつなぎ、どのサンプルを選んでいるか）、実際にリリースされたレコード（記憶から説明するのではなく、音声から測定したジャンルの証拠）、そして現在開いている Live セットです。証拠が尽きた場合、ツールは何も返さず、その旨を伝えます。エミュレートは行わず、結果が不確かな場合に再試行することもありません。また、すべての書き込みは承認されるまでドライランです。

Live への接続は1つだけです。Live 12.4 beta 内で動作する Ableton Extension、Loom 拡張機能です。Control Surface も、自動フォールバックも、2つ目の書き込み経路もありません。

内容

レイヤー	役割
Sensei	固定され、ハッシュ検証されたデータセットからの MIDI バリエーション（ドラム／ベース／コード）
ArrangementGPS	プロンプトからのプロジェクト計画：テンポ、キー、ジャンル、チャンネル、セクション（Node）
AIMixMaster	.als の検査、ゲインステージング、クリップの位置合わせ、ドラムバス、オートメーションの書き込み（ファイル上）
Presetor / AISoundDesigner	ユーザー自身のプロジェクトから測定したデバイスチェーンとサウンドパレット
MusicalIntelligence	実際のレコードから測定したジャンルの証拠。プロジェクトに合わせたパートの提案
Mix Check / SampleAgent	リリース済みマスターのプロファイルに照らした音声測定。YouTube → スライス済みサンプルパック。クレートディギングエージェント
Loom extension	Live 内の Ableton Extension：MCP と実行中のセットをつなぐ唯一の接続
mcp_server	stdio JSON-RPC による45個のツール、リソース、プロンプト、進行状況、キャンセル

どのレイヤーも推測を生み出しません。証拠がなければ提案もありません。SDK で実行できないことはエミュレートせず、書き込みを行うすべてのツールはデフォルトでドライランです。

アーキテクチャ、正式な呼び出しフロー、ブリッジプロトコル： Docs/ARCHITECTURE.md。

インストール（1つの手順）

python3 install.py            # installs
python3 install.py --check    # changes nothing, reports state

install.py：

1. 検出したすべての MCP クライアント（Claude Desktop、Claude Code、 Antigravity）に Loom を登録し、各設定をバックアップします。再実行しても安全です。
2. 拡張機能パッケージ（extension/dist/loom.ablx。ツールチェーンがある場合はビルドします）を準備し、Live にインストール済みの拡張機能のバージョンとブリッジプロトコルを、このチェックアウトと比較します。Live では Loom、ID は subverselab.loom として表示されます。レガシーパッケージ（loom.sensei-midi-writer）がインストールされている場合は、その旨が報告されます。MCP がそのパッケージに変更リクエストを送ることはありません（LEGACY_EXTENSION）。
3. お使いの Ableton ライブラリからカタログを構築します。

Live での作業は1つだけです。Live 12.4 beta の Extensions 設定で .ablx を追加し、Live を再起動します。拡張機能は独自のストレージディレクトリにファイルブリッジを開き、MCP は呼び出しごとにそのブリッジを検出します。

同じサーバーは、リリースページの MCP バンドル（loom-<version>.mcpb、server.json で定義）としてもパッケージ化されています。

バージョンは3種類あり、それぞれ異なります。パッケージバージョンは extension/manifest.json に一度だけ記載します（package.json も一致している必要があり、ビルド時に検証されます）。ブリッジプロトコルは loom.bridge/3、SDK API は 1.0.0 です。

接続の診断（1つの手順）

MCP ツール live_bridge_status は、接続先のブリッジとその理由、状態の経過時間、セッション ID、拡張機能が公開する機能、mutations_allowed、プロトコル判定（OK／UPGRADE_REQUIRED／PROTOCOL_MISMATCH／STALE_STATE／NO_STATE）、ジャーナルの状態、キュー内または処理中の項目を報告します。python3 install.py --check を実行すると、同じ情報がターミナルに表示されます。

古い拡張機能（0.1.0／0.2.0。プロトコルを公開しないもの）は、読み取りのみ可能で、書き込みは行われません。すべての変更リクエストは、リクエストファイルが書き込まれる前に UPGRADE_REQUIRED で拒否されます。レガシー ID でインストールされたパッケージも同様に扱われます（LEGACY_EXTENSION）。新しい拡張機能をインストールし、古い拡張機能を Live から削除すると、live_command op=journal_import で古いジャーナルが引き継がれます（忘れられるものも削除されるものもありません）。複数の Loom ブリッジが検出された場合は AMBIGUOUS_BRIDGE になります。LOOM_BRIDGE_ROOT はテスト専用です。

対応している MCP ツール

種類	ツール	実証元
Live 経由（拡張機能）	live_state、live_bridge_status、live_command（set_tempo、set_mixer、set_device_parameter、list_device_parameters、create_locator、create_midi_track、import_audio_clip、render_pre_fx、drum_pads、build_drum_kit、journal_import、delete_track、delete_locator）、midi_write_arrangement、midi_write_to_live（セッションクリップ）、crate_to_live、mix_from_live、project_build、midi_generate（auto_write）	mcp_server/tests/test_bridge_consumer_real.py（実際の bridge.ts）、test_extension_path.py、extension/tests/bridge.test.ts
Live を使わないエンジン	project_*、automation_*、drumbuss_*、chain_*、render_*、palette_read、library_search、genre_evidence、part_suggest、plan_create、plan_verify、projects_arrangement_shapes、mix_measure/analyze/profiles、crate_fetch/read/spots/chop/agent、setup_scan、gap_record	mcp_server/tests/test_mcp_tools.py（stdio 経由の 45 ツール）と各エンジン独自の pytest スイート
OS レベル、リクエスト時	live_project（Live の起動／終了／状態。Live 自身のログで検証済み。セットを変更すると拡張ホストが再起動します）	test_live_project.py
マシンに依存	mix_capture（method="tap"：LaunchServices 経由で LiveTap.app として起動する Core Audio プロセスタップ。macOS は MCP を実行するアプリではなく、LiveTap の項目に「画面収録とシステムオーディオ録音」の許可を付与します。2026-09-06 に再生中の Live で測定）	実機でのみ

拡張機能における唯一の Live 内ユーザーコマンド 「Loom: Generate」（セッションスロットを右クリック）は、同じ write_clip の実装と同じ所有権台帳を使用します。Loom が書き込んでいないクリップが上書きされることはありません。

キットとプリセット

SDK はプリセット（.adg／.adv）を読み込みません。Loom はこれを「不可能」とは呼ばず、経路を分けています。

• 名前付きキット：project_build(kit="Boom Bap Kit")、または .adg へのパスを指定します。キットはプリセット独自の XML（パッド、ノート、名前、サンプルファイル。Sensei の .adg リーダー）から読み取られ、ファイルはこのマシン上で解決されます。拡張機能では、パッドをチェーン＋Simpler＋サンプルとして再構築します。回答では、引き継がれたものと引き継がれなかったもの（パッドごとのエフェクト、マクロ、チョークグループ、Simpler のパラメーター、リターンチェーン）を明記します。これはプリセットをそのまま読み込むものではなく、そのように説明されることもありません。
• サンプルから作成するキット：live_command op=build_drum_kit pads=[{note, sample}]。
• インストゥルメントのプリセット（ベース／コード）：SDK では読み込めません。device_map を使ってネイティブデバイス（Operator、Electric、Wavetable、…）を使うか、Live でプリセットを読み込み、同じプランを再実行してください。チャンネルが引き継がれ、そのデバイスは状態から読み取られます。回答では needs_preset の下に両方の方法を記載します。
• キットのパッドにドラムノートを配置：Sensei のドラム情報は GM パッドレイアウトです。77～92 などのキットでは、ノートをパッドの役割（キック／スネア／ハイハット、pad_mapping: by_role）に基づいてマッピングします。マッピングできない役割は除外して報告され、ノートが残らない場合はクリップを書き込みません（no_notes_for_pads）。
• 簡略化は明示されます：tracks=[...] と device_map を指定すると、回答の simplification ブロックに、除外されたチャンネルとその理由、どのデバイスがどのプリセットの代わりになるかが記載されます。テンプレートの空チャンネルはそのまま残されます。
• ファイルパス（B）：.als に対して動作するライター（automation_write、drumbuss_build、chain_apply）はディスク上のセットを変更します。開いているセットには変更が加えられないため、再度開く必要があります。プリセット XML が手作業でセットに変換されることはありません。それは Live の役割です。

SDK のため未対応

Extensions SDK 1.0.0-beta.1 は以下を提供していません。Loom はこれらをエミュレートせず、リクエストファイルを書き込む前に、不足している機能名とともに UNSUPPORTED_BY_SDK を返します。

• トランスポート（再生／停止／位置）→ live_command op=transport、mix_capture follow_transport
• 曲のキーの書き込み → live_command op=set_key。project_build の手順は UNSUPPORTED_BY_SDK として報告されます
• プリセット／ブラウザーの読み込み → create_midi_track はデフォルトのプリセットを持つネイティブデバイスのみを追加します（not_loadable_in_extension）。キットは再構築され（上記参照）、インストゥルメントは device_map またはユーザーの手順を通じて処理されます
• 拍子 → 小節から拍への変換には明示的な beats_per_bar が必要です。値が指定されている場合は .als から読み取り、指定されていない場合は beats_per_bar_source で 4/4 と仮定したことを示します
• メーター、録音（録音モード／リサンプリング）→ mix_capture method="resample"、capture_* の各操作

2026-09-03 に Centercode を通じて Ableton に報告済みです。

ブリッジの契約（簡易版）

Live からのすべての応答には、構造化された outcome が含まれます。 {kind: applied|refused|failed|indeterminate, code, applied, verified, side_effects, next_step}。 MCP のステータスはこれに基づきます。OK、REFUSED_IN_LIVE（Live は変更されていません）、FAILED_IN_LIVE（試行されましたが、以前の内容が復元されました）、INDETERMINATE（適用された可能性があります。副作用と安全な次の手順は応答に記載されています）、NOT_CONSUMED、INVALID_RESULT。結果が不確かな場合、どこであっても自動的に再試行することはありません。

キー付きリクエスト（ビルド手順、idempotency_key）は、変更を行う前にジャーナルに記録されます。同じキー＋同じ内容の場合は保存済みの結果を返し、異なる内容の場合は競合となり、別のセッションからのリクエストは拒否され、処理が途中で終わっている場合は INDETERMINATE となります。ジャーナルがないか破損している場合、キー付きの変更は拒否され、応答に対処方法が示されます。ジャーナルの削除は決して推奨されません。詳細は Docs/ARCHITECTURE.md を参照してください。

テスト

./scripts/check_ci.sh    # needs neither Ableton nor personal data; CI runs this
./scripts/check_all.sh   # everything; needs a real Ableton install

check_ci.sh はすべてのテストスイートを合格、失敗、スキップのいずれかとして集計します。依存関係が欠けているスイートが合格として集計されることはありません。拡張機能独自のキューコード（bridge.ts）は、単独（npm run test:bridge）と、MCP を相手にした実際の利用側（test_bridge_consumer_real.py）の両方で実行されます。Python のフェイクは高速化のために用意されているもので、単独ではプロトコルの証明にはなりません。

テストでは一時ディレクトリと分離されたフィクスチャを使用します。実際の Live、インストール済みの拡張機能、ユーザーデータに触れることはありません。Ableton Extensions SDK は再配布できないため、ホステッドランナーでは拡張機能の型チェックを実行できません。このジョブは合格ではなく、スキップとして扱われます。

実際の Live での受け入れテストスクリプトは extension/tools/measure_bridge.py です（実行中の Live で開いているセットに書き込みます。空のセットで実行してください）。

データポリシー

このリポジトリに含まれるのはコードとフィクスチャのみで、測定データは含まれません。Presetor のデバイスチェーンのエビデンス、AISoundDesigner のパレット、Sensei のカタログは、ユーザー自身のプロジェクトと Ableton のインストール環境から生成されるもので、いずれもリポジトリには含まれていません。クリーンなクローンでは合成フィクスチャを使ってテストが実行され、すべての応答で data_source にデータの出所（measured または synthetic_fixture）が示されます。

python3 scripts/extract_device_chains.py --out Presetor/data/measured_device_chains.json
python3 scripts/extract_sound_sources.py --out AISoundDesigner/data/measured_sound_sources.json
python3 scripts/setup_scan.py --check      # catalogs: what is there, what is missing

ステータスと既知の制限

• 2026-09-07 に実際の Live での受け入れテストに合格しました。 空の状態から開始し、実際の .adg / .adv プリセットを開き、パッドをすべて解決し（16/16）、MIDI とロケーターを書き込みました。保存して再度開いた後も、すべて正しく配置されていました。未解決の点： 拡張機能 0.4.4（2026-09-11）で追加された delete_track / delete_locator は、ヘッドレス環境でのみテスト済みです。実際の Live での受け入れテストはこれからです。バージョンと受け入れテストに関する記述は、extension/manifest.json と同時に更新されます。
• レンダリングには Live のオーディオエンジンが必要です。render_plan は出力されるはずの内容を示し、render_verify は実際の出力がそれと一致するかどうかを示します。
• （ファイル上での）オートメーション書き込みは、ミキサーとデバイスのパラメーターに対応しています。クリップのエンベロープには対応していません。
• ツールのタイムアウトは厳密ではありません（Python のスレッドは終了できないためです）。タイムアウトした呼び出しが、その後 Live に別のリクエストを書き込むことはありません。
• SDK ではクリップのオートメーション、色、起動設定を読み取れないため、replace_owned は同じオブジェクトをその場で置き換える場合に限り対応します。削除が必要になる置き換えは拒否されます。完全な保持は保証していません。この限定的なポリシーが保証の対象です。
• ジャーナルは厳密な exactly-once ではありません。適用されたかどうかが不明な処理は、適用済みとも未適用とも数えられません。状態の読み取りは呼び出し元の責任です。
• render_verify とオーディオ測定には soundfile / numpy が必要です。それ以外のすべてのツールは macOS 標準の Python で動作します。

ギャップログ：Docs/MISSING_CONTROLS_LOG.md（冒頭の注記で過去の項目を区別しています）。

著作権とクレジット表記

© Şenol Şahan / SubverseLab。GNU AGPL v3 or later に基づくフリーソフトウェアです。使用、変更、再配布が可能です。その際は著作権表示と NOTICE ファイルを保持し、配布またはサービスとして実行する変更版のソースコードを公開し、サーバーがすべての応答に含める _source フィールドを削除しないでください。正式なホームページ： https://subverselab.com/loom . 文書または学術論文での引用については、CITATION.cff をご覧ください。