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

Re: [sc-dev] Re: Some 3.3 work

Hi Rohan and all,

At 11:46 Uhr +0000 19.12.2008, Rohan Drape wrote:
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.

yes, this makes sense. It would be good to be able to interconnect unit generators across synths in audio rate, with the same syntax as connecting control rate ones.

But also I agree that it makes not too much sense to mix capabilities, like reading control rate audio from an audio rate bus, or vice versa, at least if this means a confusion of other structures.

Josh, I find that your suggestion is good because it is explicit. We can easily write some sclang code that chooses the UGen (Control or Audio), just as it currently does with TrigControl. Somehow I wouldn't call it Audio (I think it suggests that Control is called Control because it is control rate, which I think it isn't.). Maybe AudioControl ? Or actually, in the end, Control.ar would be the best, and could implement your point (2).

So - here is another idea building on the one I sent out last night:

1) add an \ar rate to SynthDef:

SynthDef(\test, {arg freq, amp;
	}, [nil, \ar]);

2) \ar rates will be mapped to a new UGen Audio.ar. Audio.ar can take any value that the current Control UGen takes, BUT it outputs an a-rate signal. If a control bus is mapped to it, then Audio.ar has to take care of outputting linearly interpolated values between control values. If a scaler is given to it, it just outputs that value (like Line.ar).

\tr, \ir and float values will act in the same way as always. Like all SynthDef rates, the rate is non-modulatable. No code here should be broken.

IF an audio bus is mapped to the default \kr Control, then Control.kr will only read the first sample on the audio bus. *WILL WRITE LATER ABOUT WHETHER OR NOT THIS IS THE BEST WAY TO DO THIS*


3) Bus structure remains the same. add a server messages \n_mapa and \n_mapan for node map audio an dnode map audio * n.

- in SC_Misc_Cmds add meth_n_mapa and meth_n_mapan.
- in SC_Node, add Node_MapAudio

4) n_map, n_mapa, n_mapn and n_mapan (and the methods that these use in SC_Node.cpp and SC_Group.cpp) will have an extra argument, a flag that tells the mapping function if control rate or audio rate mapping is happening. e.g. n_map and n_mapn sets the flag to 0 and tells the following functions to look at the control busses (which tells the Audio UGen to interpolate). n_mapa and n_mapan sets the flag to 1, and tells Audio to look at audio busses and just route. We may also want to alter Control to do the same thing IF we want Control to look at audio busses at all. As Nick points out, this may or may not be desirable.

More soon - gotta run the kid to school!



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/