[sc-dev] Re: Some 3.3 work

[Rohan Drape <rohan.drape@xxxxxxxxx>]

On 2008-12-19, Julian Rohrhuber wrote:
> 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.

exactly, so why confuse the issue?  the control and audio rate buses
are completely different systems.

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

but this is usually a nonsense, what does LPF.kr(In.ar(...), 65)
'mean'?  and the sclang classes *do* implement implicit rate flow for
unary & binary operators.

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

i disagree, i think it is a major change.  zero based control buses
are part of the scsynth specification, in the same way that
Out.ar(0,...) is going to get to the audio card.  it is in the 'Main
Design Concepts' section of the 'SuperCollider 3 Synth Server
Architecture' document.

regards,
rohan

note that under the new proposal in order to reliably work out where
the first control bus is you would need to query the server.  this is
an altogether new source of complexity, and quite unlike the slight
awkwardness of finding private audio buses (which in any case can be
done using unit generators) because control buses are very often the
point of interface between scsynth and various external processes.


_______________________________________________
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/