zakって良く分かっていないので、少しお勉強

http://ecmc.rochester.edu/onlinedocs/Csound/Zak/zakinit.html
を読んでいいたらちょっと内容が面白かった。ZAKってこういう風に考えてもいいのか。。

• -

zakは一言で言うと、k-rate, a-rateのパッチング（i-rateでもよいが）。名前の付け方はzで始まるようにつけないとZAKの変数であると認識されない。ZAKは配列変数がcsoundで実現されるまでの回避策である。zakシステムではi-rate, k-rateのための領域とa-rateのための領域を確保して動作する。

Why arrays or "zak" are important for some applications

配列変数の観点からみたzakの重要性

A major theme of my approach to making music is to set up processes and let them interact and be affected by random occurrences. This can be expensive in analog hardware - but a load of fun too.

音楽を作成する上で、プロセスを作成し相互作用させ、ランダムに発生するイベントに影響を受けるようにするのが私の方法論上の最大のテーマである。これはアナログのハードウエアでは高価につくが面白い方法でもある。

Setting up a garden of interacting processes and then tweaking them to whatever state of control or chaos I like is my idea of fun! Lets say I want to set up a musical cellular automata - with 100 similar cells.

相互作用するプロセスの庭を造ってやって、それを微調整して自分の制御下もしくはカオス状態にすることがしたいのです。

Each one produces sound and has various internal states stored as i, k or a rate variables. The behaviour of each cell is at least partially dependant on that of its neighbours. Typically, each cell would make some of its own internal state - including sound output - readable by its neigbours or other things.

プロセスの夫々が音を生み出し、色々な内部状態をi-rate,k-rate,a-rateの変数で表現されるような状態にするのです。各セルの挙動は少なくとも部分的には隣り合うセルと依存関係にあります。各セルは夫々の内部状態（音の出力も）を作り出して、近隣のセルや、そのほかの外部から読み出しができるような状態にします。

There could be a global matron function who tries to control the cells' level of friskiness if they individually or collectively incur her wrath by becoming too obstreperous.

ふざけまわるセルを全体的に監視する寮母役がいて、騒々しくなりすぎると、それに罰を当てえるようなことができるだろう。

So I have a 10 x 10 array of cells, and their internal state is made available as global variables - with different names for the same variable in different cells. This could be done with 100 carefully written instruments, but life is too short.

10×10のセルがあるとして、その内部状態が大域変数として利用する事ができて、異なったセルの同じ変数を異なった名前で認識する事ができる状態を考える。これは100個のごく短時間の寿命しか持たないような楽器を作る事によって実現できるだろう。

The only alternative is to use one instrument and have each instance decide where its interal states are written to for others to read. It should decide which of the 99 other instances it will read the states of. The ideal way is if we could write global variables as:

gahuey[p7] = afoo * abar　or　gahuey[kdest] = afoo * abar

唯一の別の方法としては、一つの楽器を使って、個々のインスタンスが外部から読まれるような内部状態を持つようにする事と、他のどのインスタンスから状態を読めるようにするかを決めることによって実現できる。理想的な方法としては、大域変数を以下のように書く事ができるようにする事だ。

gahuey[p7] = afoo * abar　or　gahuey[kdest] = afoo * abar

In either case, one element of an array huey[] of a rate variables is written. (Actually each variable is an array of ksmps floats.) Likewise we want to be able to write these array specifications in the right hand of equations.

gaduey[kdest] = huey[ksource] * (ablah + p4)

どちらの例もa-rate変数である配列変数huey[]の要素に書き込む事を意味している。（各変数はksmpsの要素を持つ浮動小数点の型の配列変数となる）また、これらの配列変数への代入を式の右辺で書く事ができるようになる事も必要だ。

gaduey[kdest] = huey[ksource] * (ablah + p4)

So that is the first thing about arrays - make them easy and direct to use with i or k rate indexing. Secondly, make them multidimensional:

galouey[4, 10] Is a 2D array of global audio rate variables.
gkblah[2, 4, 10] Is a 3D array of global k rate variables.

これによって、配列に関してまずは、i-rate, k-rateのインデックスによって、その要素に簡単にアクセスできるようにする事が必要だ。次に、多次元配列を利用可能にすることだ、

galouey[4, 10] Is a 2D array of global audio rate variables.
gkblah[2, 4, 10] Is a 3D array of global k rate variables.

Thirdly, we want them to be either global or local to the instance of the instrument. This is quite a tall order, since the core of Csound is not perfect and is largely devoid of comments. Such facilities are obviously beyond what Csound was originally conceived to do, but now that CPUs are so much faster, many people will be writing more sophisticated programs.

三つ目に、これらの配列変数が楽器の各インスタンスにおいて大域変数もしくはローカル変数となる事である。この要望はかなり難しいだろう。なぜならば、csoundの核部分は完全ではないし、今まで書いたようなことは実装されていない。開発開始当初のcsoundの動作として意図されていたものからは逸脱している、しかし現在はＣＰＵはずっと早くなっているし多くの人がより洗練されたプログラムを書いているのだから難しいということはないかもしれない。

In principle, the global aspect of arrays can be acheived with the zak system, but it is trickier. zak ugens do not go on the left or right of equations, they have their own line. They must write to normal variables and be fed by normal variables. Arrays, and multi dimensional arrays can all be done with offsets and multiplications to arrive at the final number of the location in za or zk space - but it this involves bulky, hard do debug and understand .orc code, and there is no prospect for building mnemonic names into the way these variables are accessed.

原則的に、zakを使う事によってこれまで述べてきた配列の大域変数という面は実現できるだろう、しかしながらトリッキーな方法が必要になる。zakは式の右辺と左辺の両方でつかうことはできない。zakはzak以外の変数から代入されてzak以外の変数に代入するしかできない(zak同士での代入はできない)。オフセット値と配列変数の大きさの掛け算を用いれば、配列変数と多次元配列変数として、zaもしくはzk空間における位置をあらわすインデックスを得ることができるので、代用は可能である。

I intend to do some cellular automatata or use multiple reverb and sound source instruments with varying delay times between them, all mixed with my binaural model - with the instruments, reverb points (and hence their connecting time delays) potentially moving around.

セルラーオートマトンにして、リバーブを何重にもかけ、時間変化のあるディレイのかかった楽器の音源を立体音響モデルと混ぜ合わせ、リバーブポイントをグルグル動き回るようにして（だから相関のあるディレイ）ということをやろうとしているのである