repl-plugin-player
オーディオプラグインをREPLライクなUIで演奏。UAPMDを利用しています。Rustで書かれています。
機能にクセがあります。ほぼ自分専用です。明日には仕様変更して今までのファイルが読めなくなる可能性があります
ダウンロード
実験用プロジェクトなのでときどき404です
これまでの課題と、このアプリが解決すること
オーディオプラグインをscriptで鳴らす遊び
- DAWはオーディオプラグインで高品質な作編曲ができて素晴らしいですね!
- ですがオーディオプラグインを演奏するには「DAWの使い方」を学ぶ必要があります。
- 特に主流のDAWはそれが顕著で、慣れるまではハードルが高い。
- ですがオーディオプラグインを演奏するには「DAWの使い方」を学ぶ必要があります。
- ライブコーディングはプログラムで音楽ができて素晴らしいですね!
- ブラウザのplaygroundもあり、入門しやすいです。
- とはいえ専用の文法を学ぶ必要があり、慣れるまでにちょっとハードルはあります。
- また、ネイティブの大規模VST3/CLAPオーディオプラグインにデフォルトで対応してバイナリ一つで起動直後からそれらを鳴らせるものは見つかりませんでした。
- さて、ファミリーベーシックやMSXの時代は、
PLAY "CDE"のような記述でドレミを演奏できました。- 直感的ですね!
- そして
CDEの部分はプログラムでその場で生成することもできました。
- アプリを起動したら
play("cde")を入力してVST3/CLAPオーディオプラグインを鳴らせる、演奏内容そのものをプログラミングして即座に(時間のかかるビルドなしに)演奏できる、そんな遊びをしてみたいと思いました。 - 現代は、ほしいUXがあれば、バイブコーディングで実現できます。
- そうすることにしました。
コンセプト、目指すもの
- おもちゃ
- 割り切って遊ぶ
- 自分用
- 頻繁に破壊的変更をします。明日には仕様変更して今までのファイルが読めなくなる可能性があります
- scripting
- scriptを書くだけで、
- プラグインホスティングライブラリAPIを利用できる。時間のかかるビルドは不要
- VST3/CLAPオーディオプラグインをプログラムで制御できる
- プラグインホスティングライブラリAPIを利用できる。時間のかかるビルドは不要
- scriptを書くだけで、
- リッチな音色
- VST3/CLAPオーディオプラグインを鳴らせる
- 手軽さ
- すぐ音が鳴る
- snippetsを選ぶだけ。かんたん!
- ガイド
- もしオーディオプラグインのない環境なら、Surge XTを楽にインストールできるよう、ガイドする。かんたん!
- 軽量
- GitHubのreleaseからダウンロードした単体exeを実行するだけ。かんたん!
- すぐ音が鳴る
- 可視化
- ミニマムのsimpleなビジュアライザ
目指さないもの
- 音楽プログラミング言語
- SuperCollider / SonicPi , TidalCycles / Strudel , Glicol
- 性能を極限まで追求
- builtin snippetsを無限に充実
- 迅速なバグ修正
- user要望に応える
補足
- イメージの補足
- リッチな音色を、プログラマブルに遊ぶ
- ブラウザ上の各種音色よりも、もっとリッチに(ネイティブのVST3/CLAPの音色をフルに鳴らせるので)
- MMLよりも、もっとプログラマブルに
- 音楽プログラミング言語よりも、もっとscriptライクな文法とコーディング内容で
- VSCodeを使う音楽プログラミング言語よりも、もっとシンプルな環境構築で(GitHubからexeをダウンロードして実行するだけ)
- ネイティブアプリを都度ビルドするよりも、もっと素早くイテレーションをまわせるかもしれない(用途によっては)
- 使い分け
- ブラウザなら、機種を選ばず鳴る
- MMLなら、もっと小さい記述量で、素早く音楽(譜面)を構築して演奏して楽しめる
- 音楽プログラミング言語なら、もっと波形単位で表現ができるし、より素早く多様な記述ができる
- VSCodeを使う音楽プログラミング言語なら、より効率的なキータイピングで、より素早く結果が得られる
- ネイティブアプリなら、より大編成でリッチな(マシン処理負荷の高い)音を鳴らすことができる
- リッチな音色を、プログラマブルに遊ぶ
- 互換性がない
- scriptingの仕組み上、この上に音楽プログラミング言語のlayerを乗せる等、いろいろなことが可能でしょう
- ただし、このprojectは頻繁に破壊的変更をします
- よって現実的には「そうやって作り込んでも、すぐに演奏不可能になる」可能性が高いです
- データ移行のコストは大きいでしょう(AIを利用してコスト軽減できる可能性があるとはいえ)
- ですので、そういった作り込みをせず、小規模に遊びましょう
- データ移行のコストは大きいでしょう(AIを利用してコスト軽減できる可能性があるとはいえ)
- よって現実的には「そうやって作り込んでも、すぐに演奏不可能になる」可能性が高いです
- ただし、このprojectは頻繁に破壊的変更をします
- scriptingの仕組み上、この上に音楽プログラミング言語のlayerを乗せる等、いろいろなことが可能でしょう
ライセンス
MIT