Hi Rohan and all,
At 11:46 Uhr +0000 19.12.2008, Rohan Drape wrote:
My understanding is that currently the named 'control inputs' to
synthdefs are never at audio (a-) rate, only control (k-) and init
(i-) rate.
This situation makes sense to me, as interconnection of unit
generators at different operating rates is not symetrical.
yes, this makes sense. It would be good to be able to interconnect
unit generators across synths in audio rate, with the same syntax
as connecting control rate ones.
But also I agree that it makes not too much sense to mix
capabilities, like reading control rate audio from an audio rate
bus, or vice versa, at least if this means a confusion of other
structures.
Josh, I find that your suggestion is good because it is explicit.
We can easily write some sclang code that chooses the UGen (Control
or Audio), just as it currently does with TrigControl. Somehow I
wouldn't call it Audio (I think it suggests that Control is called
Control because it is control rate, which I think it isn't.). Maybe
AudioControl ? Or actually, in the end, Control.ar would be the
best, and could implement your point (2).
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!
--
.
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/