[chuck-users] chuck neophyte trying to remove clicks via Envelope patch

[Andrew C. Smith]

Kas,

Oh, right, I suppose your intuition on the click removal is a good
one. No one really wants a .1 second swell, after all. My thinking was
that if you don't do the full ramp down/ramp up again you'll have to
add envelopes to each of the pitches or else you'll get
frequency-change clicks, and that just gets into more hairy territory.
I like to hold (in an ideal world) to the whole code, refactor, repeat
cycle.

Good call on the .period() thing--I'm going to try passing time in
multiples of periods to get instantaneous click-less transitions. This
sounds like something Stockhausen would do, making durations in
periods. Sounds algorithmic.

Andrew

2009/11/25 Kassen <signal.automatique at gmail.com>:
> Andrew;
>
>> You're just making swells, right?
>
> I was assuming the Envelope was for click-removal and the rest of the tone
> was desired to be of constant volume. I may well be misunderstanding the
> question.
>
>
>>
>> In that case, the only change should
>> be that you need to provide ramp-down time of e.duration() => now.
>
> Yes, while it may not be needed here this is a great trick. Any function
> returning a dur may be chucked to now. This is great as it leads to compact
> code, it's expressive, and there is only a single thing to change if we need
> to speed the piece up or down. You can even take it further, this is
> perfectly legal as well.
>
> 10::my_SinOsc.period() => now; //advances time by exactly 10 cycles.
>
>>
>> Also, make sure you scale the gain so that you keep the overall power
>> of the signal below 1.0.
>
> Yes, that too is a good trick and a good reason to keep track of the number
> of UGens connected to the dac.
>
>> and then once you expand from 4 to 100 SinOscs you'll only have to
>> change the one line of code.
>>
>
> This too is great advice that could stand repeating. As a rule of thumb I
> tend to scan my code with my eyes half-closed; anything that looks
> monotonous or repetitive when looking at it like that is cause for adding a
> array (or more rarely a function). This keeps code-size down, cuts down on
> editing time and errors.
>
> All good notes on style.
>
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>