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

Re: [sc-users] Re: Ryoji Ikeda glitches

On December 27, 2015 1:06:40 AM chanof <chanof@xxxxxxxxxxx> wrote:


Actually i'm not in a synthdef, this is my case, do you think i need select
or is possible something like this?
As Dan pointed out, yes, you ARE in a SynthDef. Doing "play" on a function evaluates the function as if it were in a SynthDef.
In SC, there is no signal processing without a SynthDef. Ever. If you're getting ar or kr signals, then there is a SynthDef somewhere. 


The two sin are not one per time, like i want, it don't work, when
envTrig[2] is playing envTrig[1] should be mute..

(play{
	var env, osc, env2, osc2;
	var trig = Impulse.ar(8);
        var trig2 = Impulse.ar(0.5);
        var vincr =Dseq((31) ,inf)!4;
        var v = Demand.ar(trig2, 0, vincr);
        var envTrig = BinaryDigits.ar(trig, v, 5);
        if(envTrig[2]==1){envTrig[1]=0}{envTrig[1]=envTrig[1]};
        if(envTrig[2]==1){envTrig[0]=0}{envTrig[0]=envTrig[0]};
Let's imagine that SC supported this usage. It doesn't, but let's pretend. envTrig is, then, an array of audio rate units. Therefore, the conditions have to be evaluated anew for every audio sample. Now, the only way to do that is to run the function again... for every audio sample. This would have a bunch of problems. First, the language is too slow. If every synth were re-running a function repeatedly at audio rate, SC would be a toy. Second, that would create a new Impulse, Demand etc. for every sample... but you need these to keep running continuously.
What makes sense, instead, is the way SC actually does it. The SC language code inside a SynthDef function *creates relationships* among UGens. It doesn't do anything else. Those relationships are set in stone at that time. There is no way to say that x should be *assigned* 0 at one moment and y at another moment.
In a SynthDef, you *can* have both the true and false signals running continuously, and use a unit to choose which one of them to use further down the chain. That "selector" UGen is (unsurprisingly) called Select. 

Select.ar(condition, [false_signal, true_signal])  // or Select.kr
In the server, Boolean tests are true = 1 and false = 0. In Select, then, a false condition points to the first array element (index 0).
Further, == and != require you to create the binary operator UGen explicitly. (The reason why is complicated.) 

Select.kr(BinaryOpUGen('==', envTrig[2], 1), [envTrig[1], 0])
If you reimagine the condition as "bit > 0" then you can do away with the explicit BinaryOpUGen. 

Select.kr(envTrig[2] > 0, [envTrig[1], 0])
And, Nathan's approach (using multiplication) is valid when one of the Select branches is 0.
Note also that both of your "if" statements above use the same condition and activate both, or silence both, at the same time. That's not the desired behavior that you're writing in English. So, take a little time to rethink those. 

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/