---
date: 2025-06-12 09:29
---
#computermusic #programming-language 

[[Nyquist]]を作った[[Roger Dannenberg]]が開発している音楽プログラミング向けの中間表現。

[GitHub - rbdannenberg/arco](https://github.com/rbdannenberg/arco)

[[SuperCollider]]のようにクライアント-サーバーモデルで動作し、scsynthに相当する部分がArco。sclangに相当する部分として、[[Serpent]]というPythonっぽいフロントエンド言語も用意されている。

内部通信はOSCではなくO2というまた別のUDPの上に乗った汎用プロトコル。

## メモ

オーディオレートの処理でも、サンプルごとの処理のパターンと、ブロックレベルの処理の2種類がある。

ブロックレベルの処理の場合は入力もブロック

UGenは基本的に[[参照カウント]]GC

ここが重要そう

> ポイントは、入力信号の種類が非常に多様である点です。constant、block、audioレート入力に加え、単一チャンネルとマルチチャンネル信号の組み合わせにより、潜在的に6種類の入力タイプが存在します。入力数がNの場合、`real_run`のバリエーションは6^Nに及ぶ可能性があり、自動コード生成であっても管理が困難になります。
> この問題を解決するために、2つの主要な戦略を採用しています。まず、入力と出力信号の複数チャンネルを反復処理するコードは、単一の`real_run`メソッドに実装されます。ただし、異なる種類の入力の処理は、`run_channel`メソッドを介した間接的なメソッド呼び出しにより個別化されています。run_channelは、対応するメソッドを指すメソッドです。例えば、`mult`では、2つのオーディオレートチャンネル（各々32浮動小数点数のベクトル）を乗算してオーディオレートチャンネルを生成する`chan_aa_a`メソッドと、オーディオレートチャンネルとブロックレートチャンネル（単一の浮動小数点数）を乗算する`chan_ab_a`メソッドがあります。変数`run_channel`は入力が変更されるたびに適切なメソッドに設定され、正しい個別化されたDSP計算が実行されます。

> 2 番目の戦略では、入力チャンネルを反復処理するロジックを、`run_channel` を呼び出す前に各入力に対して 1 つの加算命令に削減します。したがって、オーバーヘッドは出力チャンネルの数 x 入力信号の数になります。これは、アクセスおよび計算されるデータの総量に比べて非常に小さいです。

> 各 `run_channel` メソッドは、入力が入力ごとのサンプルポインタのアドレスから開始することを期待しています。ポインタは `run_channel`によって変更されることはありませんが、戻ると、サンプルポインタは入力ごとのストライド量だけインクリメントされます。シングルチャンネル入力の場合、各チャンネルで同じ入力を再利用したいので、ストライドは 0 です。マルチチャンネルオーディオ入力の場合、入力の次のチャンネルに進みたいので、ストライドは 2 です。入力と出力はメモリ内で連続しているため、ストライドはブロック長 (BL = 32) になります。マルチチャンネルのブロックレート入力の場合、1 ブロックにつき 1 サンプルしかないので、ストライドは 1 になります。最後に、定数入力 (メッセージによって更新できる値) は、ブロックレート信号と同じように扱われます。定数は、ストライドが 0 または 1 のシングルチャンネルまたはマルチチャンネルにすることができます。

> これらの戦略により、オーディオレート入力とブロックレート入力に異なるコードが必要であるため、組み合わせは 6^N バージョンの内部計算ループから 2^N バージョンに減少します。一部の入力をオーディオレートに制限することで、これをさらに制限することができます。たとえば、ブロックレート信号にオーディオローパスフィルターを適用することはあまり意味がありません。

[arco/doc/design.md at main · rbdannenberg/arco · GitHub](https://github.com/rbdannenberg/arco/blob/main/doc/design.md)