[sc-dev] Re: Some 3.3 work

[Julian Rohrhuber <rohrhuber@xxxxxxxxxxxxxx>]

> 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
> TrigControl?

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
> troubled.

nothing will change for the other uses of control.

> 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.

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/