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

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

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* 

* NOT SURE IF / HOW TO DO THIS YET *
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!

Josh


On Dec 19, 2008, at 1:44 AM, Julian Rohrhuber wrote:
Hi Rohan, regarding the question where to start to count control rate busses, I completely agree, while it is a minor change, it still can have too big consequences when you don't boot the server yourself.
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. 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.
The issue is only who knows what is an audio/ a control bus and how is it communicated?
Josh's suggestion is that the client knows it and the server understands it because client and server share the knowledge about their buffer number ranges. This may indeed by a wrong assumption. 

(1)
In order to follow this path, one should tell the server explicitly the rate of a bus number one sends.
Two places are used to map controls: the extended \set message tag (\c_), and the map messages. 

For the set messages, another tag would suffice.
Regarding the map messages, a mixed (typed) message could work, where every bus number is preceded by a sympol for the rate. 
\mapa index rate value index rate value...

(2)
An alternative would be to only allow mapping control rate busses to control rate controls and audio rate busses to audio rate controls. The control ugen knows its rate, so it can decide what set of busses to read off. This was what I had begun to implement, but it turned out to be slightly more complicated.
Currently map messages do not just register a bus number somewhere, but create access to the control bus directly. Thus it would be better if the 'receiver' (the control ugen) could decide how to interpret a bus number, and to have map messages store bus numbers instead of creating a pointer. 
--





.

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


******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/
“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono 
*/


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