Embarrassing newb question

[mikecalvert]

still learning and and wanted to create a simple
synth that has random decay values. here is what I was thinking it would map out like.

and here is the code I was trying

(
SynthDef(\test,{
	var sig, env, trig, rand;
	trig = Dust.kr(12);
	rand = Trig.ar(trig,exprand (0.01, 2));  // this line is not the ticket 
	env  = EnvGen.ar(Env.perc(0.001,rand), gate: trig,doneAction:0);
	sig  = SinOsc.ar(mul:env);
	Out.ar(0,sig!2 * 0.1);
}).play;
)

please advise… its something like re-using dust in the perc release value but with a range ?

[jamshark70]

@mikecalvert

Trig.ar(trig,exprand (0.01, 2));

exprand is language side only. Its result will be hardcoded into the synth and not change.

TExpRand.kr(0.01, 0.2, trig) is what you wanted.

hjh

[mikecalvert]

def closer but for some reason I was expecting more a mix for very short sounds with little to 0 decay…

(
SynthDef(\test,{
	var sig, env, trig, rand;
	trig = Dust.kr(6);
	rand = Trig.ar(trig,ExpRand(0,1)); //needs to be on a control buss?
	env  = EnvGen.ar(Env.new([0,1,0],[0.01,rand]), gate: trig,doneAction:0);
	sig  = SinOsc.ar(mul:env);
	Out.ar(0,sig!2 * 0.1);
}).play;
)

[jamshark70]

@mikecalvert

Trig.ar(trig,ExpRand(0,1));

Trig isn’t the UGen that you want for this case, not in any way. Trig takes a trigger value and extends it in time (making a gate out of it). It is not sample-and-hold, and not “perform the op upon trigger.”

See my post earlier today. TExpRand.

(The other issue there is that ExpRand, by design, grabs one random value at the start of the synth, and then never changes. It will be different between synth instances but only one value per synth. That’s why you’re not hearing variation. If you want a sequence of random values following a trigger, that is “triggered ExpRand” = TExpRand.)

hjh

[mikecalvert]

@jamshark70

TExpRand

ah got it ! thank you
excited to mess with TExpRand

[jordan]

@jamshark70

people can do as they like.

@smoge

to establish a uniform coding style

I only said that from a desire to decrease the amount of stuff new users have to learn, and to make sure the things they do learn are the simplest, most valuable, and don’t have any weird surprises hidden in them.

There are 20+ years of different approaches in supercollider, supporting all of these approaches is great and helps preserve art and keep users across decades, requiring new users to learn all of these isn’t.

My dream is for a majority of people to agree on what this smaller, more concise subset of supercollider might be, so that all the docs and tutorial can be rewritten in a similar style, reducing the ‘steepness’ and ‘length’ of the learning curve that turns away many.

---

There is also this chunk of code in SCDocHTMLRenderer that hides the mul and add arguments, but only when the help file doesn’t explicitly mention them with the argument tag.

// ignore trailing mul add arguments
if(currentMethod.notNil) {
	currentNArgs = currentMethod.argNames.size;
	if(currentNArgs > 2
	and: {currentMethod.argNames[currentNArgs-1] == \add}
	and: {currentMethod.argNames[currentNArgs-2] == \mul}) {
		currentNArgs = currentNArgs - 2;
	}
} {
	currentNArgs = 0;
};

[smoge]

@jordan

My dream is for a majority of people to agree on what this smaller, more concise subset of supercollider might be, so that all the docs and tutorial can be rewritten in a similar style, reducing the ‘steepness’ and ‘length’ of the learning curve that turns away many.

Isn’t that more or less the case? I would need to know how strict and how much personal room your dream would bring. (maybe give examples to clarify?) It’s a balance.