1) add an \ar rate to SynthDef's rates:
SynthDef(\test, {arg freq, amp;
...
}, [nil, \ar]);
2) \ar rates will be mapped to Control.ar. Control.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 Control.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), etc.
\tr, \ir and float values will act in the same way as always (mapping to Control.kr). Like all SynthDef rates, the rate is non-modulatable. No code here should be broken.
3) To get this to work, I think the bus structure may have to change. IF it does, then there will be one set of busses, with the first block acting as Audio busses, the remainder controls. I still need to look at how the busses are put together to see if this is indeed the case, or even possible. This would BREAK any HARDCODED control indices between 0 and numOuptutBusses - 1.
4) The Bus class can be altered to handle the change mentioned in 3) (if needed)
5) The bus allocators in Server can be altered to handle the change mentioned in 3) (if needed)
I think that sums it up. I should have time tonight to look at the code that creates the busses, and see if this looks possible.
Josh On Dec 18, 2008, at 2:36 PM, Rohan Drape wrote:
On 2008-12-18, Julian Rohrhuber wrote:I think this is a good idea, but maybe let's wait for some more opinions on this.I'm not sure that this is a good idea, perhaps I don't understand it. Since unit generator graphs are static, doesn't allowing control's to be mapped to audio buses mean that the Control unit generator needs to run at audio rate in all cases? And therefore all unit generators that read control data need to run at audio rate also? And so on down the graph? And won't this interact oddly with the sclang convention of specifing node operating rates for non 'unary/binary operator' filter nodes? And also won't this interact somewhat oddly with TrigControl? However, so long as the new unit generator is given a new name (ie. *not* Control) and the current unit generator (ie. Control) continues to work with zero based control indexes, I will not be too troubled. Regards, Rohan As an example of the rate shifting aspect, a variant of James McCartney's 'aleatoric quartet' graph with implicit rate flow for all filters and midi note and amplitude inputs gives the following unit generator operating rate counts depending on whether the inputs are k-rate or a-rate. KR => [(IR,26),(KR,54),(AR,37)] AR => [(IR,26),(KR,15),(AR,76)] Ie. transforming the control rate inputs to run at audio rate shifts 39 of the 117 nodes (one third) from k-rate to a-rate. _______________________________________________ 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/
****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/ _______________________________________________ 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/