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/