[sc-dev] Re: Some 3.3 work

[Rohan Drape <rohan.drape@xxxxxxxxx>]

Hello Julian,

Firstly, also to clarify, so long as the public & documented interface
of scynth is not broken I don't at all want to obstruct work being
done on the sclang classes.

However, I've replied inline below because I still don't understand
why the proposed notation is not *more* rather than *less* confusing.

On 2008-12-19, Julian Rohrhuber wrote:
> Just to clarify: the basic problem of the current implementation is 
> that map and set do not work the same with auudio rate and control 
> rate. This makes things unnecessarily complicated and leads to many 
> workarounds. 

My understanding is that currently the named 'control inputs' to
synthdefs are never at audio (a-) rate, only control (k-) and init
(i-) rate.

This situation makes sense to me, as interconnection of unit
generators at different operating rates is not symetrical.

This is all a little informal, however some terminology: 'filter' unit
generators broadly speaking have two types of inputs, 'signal' inputs
and 'parameter' inputs (ie. for LPF the first input is the 'signal',
the second a 'parameter'.) 'oscillator' unit generators only have
'parameter' inputs.

As I understand, the named control inputs are ordinarily used for
communicating 'parameter' data.

Both 'oscillator' and 'filter' unit generators operating at i-rate,
k-rate and a-rate can all usefully process both i-rate and k-rate data
at 'parameter' inputs.

However *only* unit generators operating at a-rate can process a-rate
signals at 'parameter' inputs.

Ie. *all* unit generators in the graph can process the data from named
controls if they are restricted to k-rate.

Further, only a small number of 'analysis' unit generators operating
at k-rate can usefully process a-rate data at 'signal' inputs,
otherwise the same sitauation applies for 'signal' inputs.

> Mapping audio rate signal from one synthdef to another you use the
> In UGen and send a set message, mapping control rate signals, you
> use the Control ugen and send a map message. This is not very
> systematic, since in most cases within a ugen graph control rate and
> audio rate work analogously.

k-rate subgraphs are precisely the appropriate mechanism to lift
non-continous event streams into the unit generator graph.

Running the whole graph at audio rate, and then very occasionally
sending c_set messages is *not* a good model.

So audio rate controls should only be used if you *know* already that
you want to run the input at audio rate, in which case it is clearer
to write In.ar, where the parameter gives the bus number, not the
audio signal.

If one wants to conflate audio and control rates it seems to me the
correct way to do that is to run the server with a very small block
size (1-4 frames).

Kind regards,
Rohan


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