zakinit isizea, isizek
"zak" means a or k rate patching, (i rate too), with a z at the start of the names of the ugens. This is a fudge to do the work until arrays are implemented. The zak system uses one area of memory as a global i or k rate patching area, and another for audio rate patching.
isizea - The number of audio rate "locations" for a rate patching. Each "location" is actually an array which is ksmps long.
isizek - The number of locations we want to reserve for floats in the zk space. These can be written and read at i and k rates.
These are establised by a ugen which must be called once only:
zakinit 10 30
reserves memory for locations 0 to 30 of zk space and for locations 0 to 10 of a rate za space. With ksmps = 8, this would take 31 floats for zk and 80 floats for za space. At least one location is always allocated for both za and zk spaces. There is nothing wrong with having za and zk ranges thousands or tens of thousands, but most pieces probably only need a few dozen to patch their signals around. These patching locations can be referred to by number with the following ugens.
The easiest way to run zakinit just once is to put it outside any instrument definition. Typically this would be at the start of the orchestra file, with the sr etc. definitions. All code outside the instrument definitions is treated as instrument one and is given an init run at time = 0.
Known bugs in zak system
When using the mix function of zkwm or zawm, care must be taken that the variables mixed to are zeroed at the end (or start) of each k cycle. The same applies to any variables to which signals are mixed. If you keep adding signals to them, their values can drift to astronomical figures - which is probably not what you want.
My intention is to have certain ranges of za and zk variables used for mixing - I use zkcl and zacl in the last instrument to clear those ranges.
Why arrays or "zak" are important for some applications
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.
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.
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
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
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.
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.
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.
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.