Andrew,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Oh, right, I suppose your intuition on the click removal is a good<br>
one. No one really wants a .1 second swell, after all.</blockquote><div><br>One more or less follows from the other... Instantaneous changes will leave spectral artefacts. In general Envelope can't be praised highly enough for it's uses as a utility module, I feel.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My thinking was<br>
that if you don't do the full ramp down/ramp up again you'll have to<br>
add envelopes to each of the pitches or else you'll get<br>
frequency-change clicks, and that just gets into more hairy territory.<br>
<br></blockquote><div>Fortunately in this case we can have cheap gradual frequency changes without clicks as we are dealing with a SinOsc here. SinOsc can track a input, which may be a Envelope (used with a Step set to 1 as it's own input). Set the osc's frequency to 0 and sync to fm modulation.<br>
<br>From there on your Envelope's .target() can set the desired frequency with the .duration() setting the length of the glide. This is very cheap, doesn't require attention once set and generally a good idea, but it only works with the basic osc's as those are the only UGens with a .sync(). The good news is that you can still have arbitrary wave-forms as you can use this with a Phasor and a LiSa set to track.<br>
<br>I could supply a example if needed. <br> <br>For other UGens you are on your own. Instantaneous frequency changes *will* mean a more or less sharp corner in the resultant signal which *will* have a spectral effect. It's hard to say anything about the general case; you'll have to analyse the situation and your needs and come up with cleverness to minimise audible artefacts. I think SC interpolates over the block-size, that's a good solution to minimise artefacts in most cases but I don't think that would suit our more precise control and less clear boundary between code and UGens.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Good call on the .period() thing--I'm going to try passing time in<br>
multiples of periods to get instantaneous click-less transitions. This<br>
sounds like something Stockhausen would do, making durations in<br>
periods. Sounds algorithmic.<br><br></blockquote><div><br>It's a good feature; a strongly-timed approach to frequency. Aside from the kind of technique mentioned it's especially convenient for expressing LFO rates as multiples or fractions of musical intervals. The idea is one of my contributions and one I'm still a bit proud of. Pride is a bad emotion, I'd much rather be dis-satisfied and work harder because of it, but this is just so ChucKian that I can't help it. :-)<br>
<br>Yours,<br>Kas.<br></div></div>