So - here is another idea building on the one I sent out last night:
1) add an \ar rate to SynthDef:
SynthDef(\test, {arg freq, amp;
...
}, [nil, \ar]);
2) \ar rates will be mapped to a new UGen Audio.ar. Audio.ar can
take any value that the current Control UGen takes, BUT it outputs
an a-rate signal. If a control bus is mapped to it, then Audio.ar
has to take care of outputting linearly interpolated values between
control values. If a scaler is given to it, it just outputs that
value (like Line.ar).
\tr, \ir and float values will act in the same way as always. Like
all SynthDef rates, the rate is non-modulatable. No code here should
be broken.
IF an audio bus is mapped to the default \kr Control, then
Control.kr will only read the first sample on the audio bus. *WILL
WRITE LATER ABOUT WHETHER OR NOT THIS IS THE BEST WAY TO DO THIS*
* NOT SURE IF / HOW TO DO THIS YET *
3) Bus structure remains the same. add a server messages \n_mapa and
\n_mapan for node map audio an dnode map audio * n.
- in SC_Misc_Cmds add meth_n_mapa and meth_n_mapan.
- in SC_Node, add Node_MapAudio
4) n_map, n_mapa, n_mapn and n_mapan (and the methods that these use
in SC_Node.cpp and SC_Group.cpp) will have an extra argument, a flag
that tells the mapping function if control rate or audio rate
mapping is happening. e.g. n_map and n_mapn sets the flag to 0 and
tells the following functions to look at the control busses (which
tells the Audio UGen to interpolate). n_mapa and n_mapan sets the
flag to 1, and tells Audio to look at audio busses and just route.
We may also want to alter Control to do the same thing IF we want
Control to look at audio busses at all. As Nick points out, this may
or may not be desirable.
More soon - gotta run the kid to school!