ラズベリーパイで動くかどうか確認する方法ってある？

残念ながら、アームビルドが必要だから、リストはかなり小さくなりそうだね。

kxstudioはRaspberry Piをサポートしてて、いくつかのDAWが付いてるし、他にもたくさんの機能があるよ。自分でコンパイルするつもりがないなら、これが一番いい選択肢だと思う。 https://kx.studio/

Zynthian（RPiベースのシンセコレクション＆グルーブボックス）は、ウェブサイトにいくつかの主要なものをリストアップしてるよ： https://zynthian.org/engines インストールレシピのディレクトリには、あまり派手ではないけど、たぶんもっと包括的なリストがあるかも： https://github.com/zynthian/zynthian-sys/tree/oram/scripts/r... Zynthian OSが動いている状態で、プラグインの完全なリストはウェブコンフィグページに表示されるけど、長すぎてほとんどのプラグインをデバイスのUIから隠さなきゃいけないくらいだよ。大まかに言うと、オープンソースならほとんど動く可能性が高い。プロプライエタリなら、Pianoteqと少数のu-heプラグインだけが動くと思っておいて。バイナリのみの配布を行っている商業製品は、RPiデバイスの市場が十分大きくないと感じているから、バイナリを作ることはないみたい。たとえApple Silicon用のARMビルドやx86用のLinuxビルドを提供していたとしてもね。

これを作ろうとしてる人へのお知らせなんだけど、マウスでノブを回すのって最悪のインターフェースだと思う。オーディオアプリやDAWがここでスキューモーフィズムにこだわる理由が全然わからない。

ハードウェアを使わないなら、クリックして横か縦に動かすだけだよね。もっといいインターフェースって何だろう？数値が変わるときに表示されるのは好きだけど、他にどんなUIが合うのか全然思いつかない。通常、ノブがたくさんあるからコンパクトにするのは理にかなってるけど、MIDIコントローラーのノブのビジュアライゼーションに合わせるのもいいよね。

密なコントロールができるし、みんなそれに慣れてるから問題ないと思う。直感的じゃないかもしれないけど、ノブをつかんで「回す」って感じじゃなくて、直線的にドラッグすることを覚えれば、使いやすくて一貫したインターフェースになるよ。giancarlostoroが言ってたように、ライブ演奏や録音中にノブをいじりたいなら、MIDIデバイスにマッピングできるしね。

> マウスでノブを回すのは、思いつく中で最悪のインターフェースだ。値の範囲の中から数値を選ぶための、もっと良いインターフェースは何だろうって頭を悩ませてるけど、思いつかない。ウェブアプリの「伝統的」なUXに相当するのはスライダーコントロールだけど、それは機能的には同じだし、あまりメリットがないのに長年のドメイン特有の共通理解に逆らうことになる。

20ピクセルのノブは、最大解像度が20の20ピクセルのスライダーよりもかなり高い解像度を持ってると思う。マウスで回さなきゃいけないデジタルノブには、前世紀以来出会ったことがないよ。上下左右にドラッグするだけだし。

実装が本当に悪くない限り、ノブの方がスライダーよりも実際にはもっとコントロールできるよ。技術的にはノブを完全に取り除いて、クリックしてマウスを動かすだけのテキストの数字に置き換えることもできるけど、ノブの方が読みやすいからね。

でも、実際にはすごくうまく機能するよ。代わりは何？視覚的に小さいから、狭いスペースにたくさんのコントロールを収められるし。ちらっと見ただけで現在の設定や可能な値の範囲内での位置がわかる。ノブをクリックしたときにマウスコントロールをモーダルにすることで（ドラッグを始めて、スライダーよりもずっと大きなエリアをドラッグできる）、リアルタイムで値を非常に正確にコントロールできるし、大きな変更もすぐにできる。これはパフォーマンスには欠かせない。ドラッグ中のコントロールの変化率に優しいマウス加速を組み合わせると、さらに正確なコントロールが可能になる。これもスライダーではできないよ。むしろ、特定のシナリオにおいては完璧なインターフェースだと言えるね。他のコンピュータソフトウェアではあまり起こらない要件があるから。

おはよう。どんどん増えていくボタンやタブ、メニューは、関数とは直接関係ない幾何学的な記憶を必要とするよね。最初のGUIは、機能が「見つけやすい」ように設計されてたけど、今やその見つけやすい機能が隠れている干し草の山の大きさは指数関数的に増えて、認知的な負担が増して、アプリをマスターするのに必要な習熟期間も長くなってる。見た目がかっこいいGUIは、そのアプリの宣伝みたいなもんだよね。アクセス可能なターミナルベースのDAWアプリの作者として、'add-track'や'list-buses'みたいな呪文を覚えるのと、あちこち探し回るのを比べると、やっぱり後者は面倒だなって思う。これらの呪文は、'lb'でリストバスを表示したり、'help bus'や'h bus'で十分見つけやすくできる短縮形があるし、プラグインのパラメータを±1/10/100で調整できるホットキーもあればいいな。多くのユーザーがこれを選ぶとは思えないけど、GUIは多くの目的に対して素晴らしい機能を提供してるし、Linuxには音楽制作や制作アプリがたくさんあるのは大成功だと思う。

OSレベルの拡大鏡（ctrl+スクロールなど）を使うと、ひどく壊れてるよ。これがアプリの開発者のせいなのかは分からないけど、OSのマウスワーピングAPIについては調べてない。ノブの中心にマウスを戻すと、拡大鏡とフィードバックループになって、クレイジーなマウスイベントが発生して、すぐにノブが最小または最大に行っちゃう。ほんとに恥ずかしいアクセシビリティの失敗だけど、誰も気にしてないね。

僕は毎日オーディオツールでノブを使ってる（トラックパッドで）けど、3つの機能があれば全然問題ないよ。1. 値を変えるために上下にドラッグ。2. ドラッグを遅くするための修飾キー。3. 正確な値を入力するためにノブをダブルクリックできること。GUIのノブの問題は、デザイナーがより早いオプションがあるのにノブにこだわること。例えば、3つのノブを組み合わせる機会があるのに。SSLのチャンネルストリップのEQは、元のハードウェアのスキューモーフィックデザインにこだわってて、調整するのがすごく面倒。ハードウェアでは、ミキサーがゲインと周波数を同時に調整するために両手を使う必要があったし、Qを3つ目のノブでダイヤルする必要があったから、マウスでやるとすごく面倒。これがうまくできてると、FabFilterのPro-QグラフィックEQみたいになる。ゲインと周波数のコントロールは、周波数スペクトラムの表現を簡単にドラッグできるX/Yスライダーになってる。さらに、修飾キーを使ってQを狭めたり広げたりできる。すべてがバンドのクリック＆ドラッグでできるんだ。

MIDIキーボードでコードを押さえながら、片手でマウスでいろんなノブを操作するのがすごく理にかなってるよね。調整したいパラメータが分かれば、自動化したりMIDIコントローラーにマッピングしたりできるけど、最初からそれをやるとかなり時間がかかるよね。

音楽家に必要なリアルタイムの低遅延マルチチャンネルオーディオストリーミングは、電話のためのそれとすごく似てる。でも、なぜかこの二つの業界は全く違う技術スタックを持ってて、あまり連携してないみたい。

技術スタックの性質によって皮肉が増幅されてるねｗ きっと何かしらのチャンネルで明確にコミュニケーションできる方法を見つけられるはずだよ、ハハ。

それは全然違うよ。電話はリアルタイムオーディオ処理よりも遅延に対してずっと敏感じゃないし、単一チャンネルだから負担も少ない。必要な圧縮レベルや音質も全然違うしね。音声用にコーデックを調整できるけど、オーディオ録音のときは圧縮を避けたいし、特定の入力に偏ることもできない。音を扱うという点では似てるけど、それは一輪車とF1カーのニーズがホイールがあるから同じだと言ってるようなものだよ。

これはすごく興味深い考えだね。低レベルのオーディオにはあまり経験がないし、電話については全然無知なんだけど、音楽のオーディオを扱ってる人たちは低レベルで作業してるわけじゃない気がする。自分のプラグインを作っていても、オーディオインターフェースと統合してるわけじゃないだろうし。JACKやPipewireの目的は、そういうことを抽象化して、みんなが楽器に集中できるようにすることだと思う。音楽における遅延は、声の遅延よりもずっと大きな問題だから、遅延が急上昇するとネットワークオーディオは完全に使えなくなるよね。Zoomには「音楽家のためのリアルタイムオーディオ」機能があるけど、ロックダウン中のZoomデモ以外で誰が使ってるのかはわからない。Pipewireはネットワーク上でオーディオチャンネルをサポートしてるけど、これが何のためなのかもよくわからない。デバイスAからデバイスBに音楽をストリーミングするのには便利だと思うけど、制作現場で誰が使ってるのかは疑問だね。「ライブコーディングシンフォニー」みたいなものがあればいいなと思う。みんな自分のライブコーディングセットアップを持ってて、音声が中央サーバーで生成される感じ。Animal Collectiveがやったことに近いかも。でも、ライブコーディングは独自の美しいメディアだけど、楽器を演奏する時の筋肉の記憶や触覚的フィードバックが欠けてるんだよね。あなたが言ったように、これらの分野がコラボするのを見たいけど、今のところ実用的じゃない理由があると思う。

テレフォニーと音楽制作を同じだと言うのは、ファームウェアを書いたり、ウェブサイトのHTTP/JSONバックエンドを作ったりするのと同じだと言ってるようなもんだね。確かに、どちらもプログラミングではあるけど、要求や前提、環境が全然違うから。

僕が経験したほとんどの電話は、遅延が秒単位で測定される（隣にいる友達や配偶者に電話すると、すごく分かるよ :)）のに対して、音声録音や処理はミリ秒単位で測定されるんだよね。さらに、少し知ってる限りでは、電話は人間の声の特定の周波数に最適化されていて、その中で強く圧縮されてる。加えて、単一の電話ストリームは基本的に単一チャンネル。曲は何十ものチャンネルを持っていて、高解像度でフルスペクトラム、計算負荷の高いエフェクトや処理が必要なのに、遅延や同期はミリ秒単位で測定される必要がある。だから、音を処理するという点ではお互い逆の存在だよね。

そうでもないよ！AES67は基本的にRTPにPTP由来のメディアクロックを加えたものだね。接続の説明にはSDPを使って、ユニキャストのシグナリングにはSIPを使う。VoIPと同じ感じだね。それにTDMは最初に電話で使われたんじゃないかな。

なんか「Linuxミュージシャン」って言葉を聞くと、'cat /dev/random > /dev/dsp' みたいなアートを作ってる人を思い浮かべちゃう。で、Windowsミュージシャンってどんな感じなんだろうって考えちゃったよ（怒りやフラストレーションを表現する人が多いのかな）。

どんなノイズオシレーターでも似たような目的に使えるよ。

今はPCベースのAbleton環境を使ってるけど、完全にITBで、サウンドカードとAbleton Push gen 1以外の外部機材は使ってないよ。特に問題はないけどね。deadmau5も有名なPCユーザーで、彼はWindowsに特に問題がないみたい（知ってる限りでは、何百万ドルもするハードウェアや複数のコンピュータを使った特定のセットアップに関する問題を除いて）。彼のセットアップは、オタクの遊園地みたいだよ。

ALSA以前の時代、LinuxがOSSを使っていた頃は、/dev/randomを/dev/dspに流し込むとノイズが出てきたし、何でも/dev/dspに流し込めば大体ノイズが得られたよ。BSDでもまだOSSを使ってるから、今でもできるかもしれないね。

古いお気に入りのdexedやzynaddsubfxを見つけるまでかなりスクロールしたけど、Helm（https://tytel.org/helm/）は全然見なかったな。

Surge XTもリストの一番下にあるね。

Helmは実質的にVital（同じ作者）に置き換えられたと思う。

僕が使ってる高度なマルチエンジンFOSSソフトシンセ、Yoshimi（https://yoshimi.sourceforge.io/）を追加する提案を出したよ。これはZynAddSubFXのLinux専用フォークなんだ。

これ、めっちゃすごい！本当に。音楽制作をしているのに、まだ新しいLinuxプラグインを見つけるなんて驚きだよ。これをコンパイルするのは簡単じゃなかっただろうね。情報がネットのあちこちに散らばってるし。圧縮やサチュレーションのフィルター機能があるのも最高だね！

LinuxでDAWを使いたくないなら、https://github.com/glicol/glicol-cliを試してみるといいよ。

もちろん、Glicolでどうやってバンド全体を録音してミキシングするのか教えてくれたらね。

Ardourはどう？

Ardourはリストに載ってるよ。検索バーで探してみて。もしArdourの使い方についての質問なら、ちょっと使ったことがあって、曲を作ることができたよ。このチュートリアルをおすすめするよ： https://www.youtube.com/watch?v=ACJ1suTVouw

LogicやAbleton、ProTools用のラッパーを出してくれる会社があればいいなと思ってる。以下の条件で： - ポータブルで再現可能な環境：これってdockerセットアップで実現できると思う。違うワークステーションに移動したとき、設定に悩まされずにプロジェクトを読み込みたい。 - ライセンス管理がドットファイルデータベースみたいな感じ：ライセンスが2、3のメールアドレスに分散してて、PCがクラッシュするたび（過去5年で2回）に再収集しなきゃいけないのが面倒。クエストみたいで、クエストは嫌だ。 - リモートやクラウド処理：移動中にワークステーションに接続したり、DAWを動かしてるクラウドクラスターに接続したり。確かに、これだと遅延が出てピアノロールに引きずり込まれることもあるけど、ミックスをいじるだけの時もあるしね。でも、ソニーみたいなゲーム大手はPS4/5タイトルでそれを実現してる。 - ライセンスの壁を乗り越えるための革新的なビジネスソリューションを持った共有可能なプロジェクト。誰かのプロジェクトにアクセスして、全部読み込めるようにしたい—Neural DSPの最新のArchetypeがあろうがなかろうが、Serum2があろうがなかろうが関係ない。AppleはバンドをiTunesに載せることができたのに、WavesやNeural DSPが同じ道を歩むことはできないの？ロイヤリティベースのアプローチとか？これは一部のシナリオでは突飛な要求かもしれないけど、WindowsやmacOSがゴブリンウェアのオペレーティングシステムである時代の音楽制作の苦痛を解消すると思うんだ。

オープンプラグインやほぼオープンな結果ファイル形式があっても、メディアソフトウェアの世界は主にいくつかの理由でプロプライエタリソフトウェアに依存してる。短命な流行で一気にお金を稼ぐことができるとか、新しい技術の統合がオープンスタンダードに向かないとか、実際の支払い顧客の大半が予算のある働くミュージシャンで、その市場は結局小さいから。これに伴う副作用は、ラジオやRCプレーン、ドローン、他の趣味と同じように、小さな製品を作る組織がさらに小さく、より均等な競争の場を持っていることだね。モジュラー機器の製造者の中には、実際のハードウェアのマーケティングギミックとしてプラグインの無料版を提供しているところもある。ただ、Linuxの世界を除けば、創造的なブロックを打破するためのプロプライエタリな解決策の神秘が、人々を短期的な販売推進に向かわせている。だけど、あなたが挙げたことは全部好きだよ。PipeWireのようなものが、良くも悪くも、オープンソースの世界の混乱を管理するためのより良いアイデアを推進していると思う。これは数十年かけて作られてきたものだから。

元々映画やゲームの作曲家からプログラマーに転身したんだけど、あなたが書いたことはまさに私が人生の仕事として目指していることだよ :p これらの全てが私にとっての白鯨で、何らかの形で取り組んでいることなんだ。もっとこのことについて話したいなら、連絡してね（メールアドレスはプロフィールに載ってるよ）。

タイトルにリンクされているサイトは、主にLinuxで音声/音楽制作を行う人々のためのFLOSSプロジェクトについてだよ。あなたが説明している問題、特にライセンスに関するものは、プロプライエタリソフトウェアに特有のものだね。これがLinux上のBitwigに影響を与えることはあるけど、一般的にLinuxの音声ソフトウェアの特徴ではない。クラウド作業は今のところあまり魅力がないみたい。人々はApple M{1..5}のノートパソコンを持ち歩いていて、10年前にはスタジオシステムでできなかったことができる計算能力を持ってる。確かに、高品質なサンプルライブラリを使ったサンプルベースの再生や、物理モデリング合成を行うなら、大きなオーケストラ作品でどんなシステムも限界に達するけど、バスや電車、車の後部座席でできることは、ほとんどの人がやりたいことの大半をカバーしてる。iTunesはLinuxの人には役に立たなかったし、Wavesが何らかの「暗黙のライセンス」スキームに参加するようなシステムも同じだね（彼らは販売するハードウェアユニットの中でLinuxを動かしているのに）。再度言うけど、このリンクはLinuxでの音声作業の状況に特に関心を持ったセットに向けられている。プラグイン開発者が一斉にこれをサポートすべき有効なプラットフォームとして認識するまで（改善は毎日行われているけど、非常にゆっくり）、これはLinuxにとってiTunesが役に立たなかったのと同じくらい無意味だよ（今もそうだけど）。

リストを作ってくれてありがとう。でも、無限スクロールは嫌いなんだ。誰が好きなんだろう？意味がわからない、GUIの拷問だよ。フッターにアクセスできないようにする理由は何なの？