Hi,
I realize I'm not giving you a true solution but hopefully this will explain a little about the problem? In the meantime you can try to get clever, for example when modulating a oscillator's pitch you could make the modulation run at the same rate as the oscillator and try to only set it at times when it crosses the zero, that could save CPU while not zippering.
Yup, I understand a lot of the issues involved. The problem comes in when for example trying to compute filter coefficients, it's not something that is really wanted at every sample. On the other hand a possible part-solution might be to have it re-calculate the coefficients only while the value (e.g., cutoff) is actually "sliding".. Anyways, I know that this is not an easy thing to answer, and in a lot of cases will depend on the particular UGen and so is difficult to generalize. I'd think though that enveloping less demanding values (FM parameters, for example) should be possible.. I dunno, anyways I thought I'd toss the idea out there. The reason I guess it seems to be a bit of a problem with Chuck specifically is that you tend to want to abuse the sample-accuracy of it by doing things like frequency modulation or LFO-based effects in a simple while{}. But when you actually drop down to 1::samp, the CPU really starts spiking. I guess maybe the answer is to just build that kind of thing into a UGen, but it sort of defeats the idea of doing nice effects quickly using =>. Steve But then when you do this in Chuck code instead of building it into a UGen, you get