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

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



Hi everyone,

I about to start taking a crack at this. Just wanted to check and see if anyone was interested in collaborating a bit on it off-list, then we can present a diff for review.

Any takers?

Josh

On Dec 20, 2008, at 6:28 PM, Josh Parmenter wrote:

On Dec 20, 2008, at 1:25 PM, ronald kuivila wrote:

Hi Josh,

Just reviewing this thread. I am with the traditionalists on bus naming (i.e. don't mess with the indexing scheme). (The problem is every time you change allocation of buses, you would have to rename control buses. This basically kills
raw OSC style - too drastic a change in my book.)

We aren't... I am now pretty sure that we can get around that totally.


On the other hand, I don't see why that would be really necessary.
Step 1: why not just make an AudioControl UGen that has rate and index arguments?
	'scalar' -> actually acts as a Control, index is the value
	'control' -> reads from control bus index
	'audio' -> reads from audio bus index
This could then be exercised just using regular Controls for its two arguments.

Yep! That is basically the approach.


Step 2: integrate with the Control naming scheme - perhaps automatically generating the secondary rate control.

Step 3: integrate with SynthDef (and while we are at it, we should consider an attempt to make this code more comprehensible:)

I agree here... I'm going to have some time this week I think to start on the AudioControl part of things. Thanks for thinking this through as well Ron!

josh




RJK


On Dec 19, 2008, at 6:30 PM, Josh Parmenter wrote:

I like AudioControl better. I'll start looking into this more this weekend.

Perhaps this is better post 3.3? Not sure how much it will take to implement this at the moment, but I actually think this discussion is starting to find a rather simple and elegant solution that doesn't break code (which is nice!).

I'll start looking into it some more.

Josh

On Dec 19, 2008, at 3:25 PM, Julian Rohrhuber wrote:

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*

* 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!

--





.

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



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


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