cat2151

Recent Notes

宣言的なリッチaudioおもちゃ

11 min read

以下、ころころ変わる可能性があります

宣言的なリッチaudioおもちゃを考えておった

3行で説明

  • 実績。インストールが楽なサウンドおもちゃを pipx や cargo で実現済み。userの音楽へのハードルを下げたい。
  • リッチ化。Salamander Piano などCC BYな楽器で、よりリッチな音色で、userの音楽体験の満足度を高めたい。
  • 妄想。インストールが楽、リッチ、を両立する手段としての、宣言的なインストールの仕組み。オーディオプラグインやプラグインホストも宣言的にインストール。まずPoCを小さく始める。以降で詳述。

宣言的なインストール

  • Koruriのような宣言的なUI記述、による演奏、についても興味があるのですが（Atsushi Enoさん情報ありがとうございます）、本稿ではそこはスコープ外とし、
  • あくまで宣言なインストールに話を絞ります。

開発とインストール

  • pipx と cargo の恩恵で、
    • 現代は、カジュアル開発者とカジュアルuserとがwin-winの関係にある
    • なぜなら、GitHubでカジュアルに発表すれば、
      • pipxとcargoのワンライナーで一発インストールが完了する
      • そこに面倒なインストール手順は一切ない
        • 時間がかかる？寝る前に実行すればよいだけだ

CC BY

  • さて、GitHubには、Salamander Piano のように
  • リッチかつ CC BY な楽器がいくつか存在するはずだ
  • ※詳しくないので雑に発言する

アプリ

  • もし、それらを組み込んだアプリが
  • pipxやcargoで一発インストールできる形で発表されており
  • そのアプリが対話的に動的に音楽を楽しめるおもちゃであれば
  • リッチな音響体験を
  • カジュアルに
  • userに提供できるはずだ

モジュラー

  • ワンオフの巨大アプリで構築されていると、そこからエコシステムが広がるのは困難だろう、属人化だ
  • そこでモジュラーを考える
    • 大前提
      • オーディオプラグイン層、プラグインホスト層、アプリ層、の3層は別リポジトリである
      • 対象プラットフォームは、モダンなデスクトップPC、Windowsだ
        • 狙いが、よりリッチに、だからだ
          • もしカジュアルさを最大化するなら、
            • 後述のスマホブラウザアプリが向いているだろう、それは別件であり、スコープ外だ
      • Why windows？
        • Linux audio programming は手元の環境だとWSL2なので、そのぶん開発コストが大きい
    • アプリ層
      • ここで重要なのは、アプリ層のモジュラー化だ
      • 時間管理層
        • （staticなtimelineだけではなく、おもちゃなら動的な時間管理を可能にせよ）
        • は独立したリポジトリがよいだろう
      • ミドル層
        • 最上位階層のGUIの層と、時間管理層の中間にも、
        • ミドル的ななにか（ふわっとした表現）が独立したリポジトリで存在するとよいかもしれない
      • GUI
        • GUIの層も、key bindやskin差し替えを別リポジトリでやって別物のUXにできるくらいモジュラーで疎結合だとよいだろう
      • メッセージング
        • HTTP
          • GUIはHTTPメッセージングで疎結合にするくらいにしてもよいだろう
            • リアルタイム性（10ms付近）の実現が困難になるかわり、
              • 準リアルタイム（50ms付近）でも、今回の用途なら許容範囲内だろう
        • MIDI
          • MIDIは、おそらくPCとDAWを含む音楽環境全体のMIDIルーティングを宣言的な管理をする仕組みが現状なさそうなので、対象外にして、HTTPがよいだろう

宣言的

  • さて「宣言的」とは何か？

  • それはDAW風に言うならオーディオプラグインとプラグインホストは何か？の宣言だ

  • それを新たなフォーマットのプロジェクトファイルに宣言する

  • 楽器もエンジンも、GitHubのURLとcommit hashで宣言する

  • そのプロジェクトファイルさえあれば、

    • あとは環境構築アプリが、pipxやcargoでインストールを行い、
      • あとはリッチな音のaudioおもちゃで遊ぶことができる

  • いわば音楽的IaCだ

  • 責務の分担はこうだ：

    • 上記プロジェクトファイルを読む、環境構築アプリ（音楽的IaC）
    • 構築された環境で音楽体験を提供する、おもちゃアプリ本体

  • プラグインがロストしたりアプリ互換性で悩んだりするリスクは、ある

    • CC BYなリポジトリが削除されれば終わりだし、
      • 破壊的変更があった場合も、対応コストは発生する

Why 宣言的？

  • 一般的なDAWやオーディオプラグインは、installや運用が宣言的でないため、UXが悪い

    • 少なくともテキストファイルの設定ファイル一発ですべてが宣言的に運用できるものは多分ないだろう
    • ※詳しくないので雑に発言する

  • そこで、テキストファイルの設定ファイル一発ですべてが宣言的に運用できるものがあれば、

    • その点だけに限ってはUXを改善できるだろう

  • このUX改善のメリット

    • user参入障壁を減らす
      • よりカジュアルに音楽体験にふれることができるチャンスを増やす、と考える
    • つまるところ本件の一番の焦点はここ、
      • 「カジュアルuserが、よりカジュアルに音楽体験にふれることができるチャンスを増やす」
      • かつ「カジュアルな範囲内で、音のリッチさを最大化する」
      • のバランスのとれたものを目指す、である

なんでストアじゃないの？

  • ストアは
    • メンテコストが大きい
    • 破壊的変更ができなくなる
  • GitHubでcommit hashにすれば、
    • それを宣言的に指定するだけで済む
    • メンテコストの最小化
      • 破壊的変更が自由に可能
        • このメリットが非常に大きい
          • 開発スピードの最大化
            • 計画実現の可能性の最大化

なぜ完璧な完成品じゃないの？

  • 開発スピードの最大化
    • 計画実現の可能性の最大化
      • 小さく始める
  • ある意味、 digital garden に通じる考え方

使い分け

  • カジュアルさを最大化する用：
    • スマホのブラウザアプリ
  • 最高品質の楽器やエフェクトを利用し、最大効率で作曲する：
  • 制約を割り切って、リッチかつカジュアルに遊ぶ用、教育用：
    • 本件

規格

  • さて、これは共通規格として成立しうるか？
    • 現時点では、いいえ
  • 進め方としては、
    • 仮共通規格を作った上で、関連PoCがいくつか作られるレベルまで到達する、その間は破壊的変更を頻繁に繰り返す、
      • とやっていくのがよいだろう
        • でないと共通規格を正式決定したあとで、
          • 「やってみた結果、この変更をしないとマズいことがわかった。
            • だが、決めてしまったので、今から変更は、やりづらい。
              • 変更できなかったり、userが不利益だったり、中途半端な変更になったり」
                • という、よくある問題が発生するだろう

PoC

  • 以上を見てみると、必要なのはカジュアルなPoCの試行数の最大化だ
  • LLMが進歩してきている現代、軽量PoCのレベルであれば、いくつかが実現する可能性は多少はあるだろう

で、いつやるの？

  • 気が向いたら。
  • 妄想しただけなので、今やるつもりはない
  • 最低限、以下くらいまで進んで知見を得てからでないと、やっても迷子になるだけだろう：
    • GUI層 / 時間管理層 / プラグインホスト層 / オーディオプラグイン内部のrender層
      • まで一通りを雑にLLMに車輪の再発明させて、学ぶ
      • ※一部はライブラリ使うだけで済みそうなので、それも選択肢に入れている
      • ※もっと細分化した別リポジトリにすることもありうる（前述）
      • それらを個別リポジトリで公開する
    • それらを技術スタックとした、「超小規模オレオレDAW風おもちゃ」の試作品を発表して遊ぶ

Graph View

Backlinks