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

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



I still haven't had the time to map this out in great detail... But here is what I think can happen:

1) add an \ar rate to SynthDef's rates:

SynthDef(\test, {arg freq, amp;
	...
	}, [nil, \ar]);
	
2) \ar rates will be mapped to Control.ar. Control.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 Control.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), etc.

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

3) To get this to work, I think the bus structure may have to change. IF it does, then there will be one set of busses, with the first block acting as Audio busses, the remainder controls. I still need to look at how the busses are put together to see if this is indeed the case, or even possible. This would BREAK any HARDCODED control indices between 0 and numOuptutBusses - 1.

4) The Bus class can be altered to handle the change mentioned in 3) (if needed)

5) The bus allocators in Server can be altered to handle the change mentioned in 3) (if needed)

I think that sums it up. I should have time tonight to look at the code that creates the busses, and see if this looks possible.

Josh


On Dec 18, 2008, at 2:36 PM, Rohan Drape wrote:

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?  And therefore all unit generators
that read control data need to run at audio rate also?  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?

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.

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.


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