[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sc-dev] Re: Some 3.3 work

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?

if you want to use its output in audio rate, it has to be constructed that way. One must decide in advance what controls are audio rate and which are not - this is a constraint of the UGen graph optimisation.

 And therefore all unit generators
that read control data need to run at audio rate also?

no, if you map them onto an audio bus, they will just read only the first sample in the block, just as any audio rate input to a control rate ugen would work.

 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

as far as I can see it is quite a minor change. The only problem is if you use hand-coded control rate busses then you have to offset them enough so that they do not get interpreted as audio rate busses.

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

nothing will change for the other uses of control.


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.

ah yes, this is a bit like this, just done automatically.


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/