Hey, guys, before you continue! If this were implemented, ChucK would also get a "control rate", and the CPU-load would be about the same as any other realtime audio (programming) app. The difference would be that you can choose to not use it.
I don't agree that applying envelopes to parametric changes would imply a "control rate". The envelope would occur at sample rate. If anything it would imply some (adjustable) frequency response for changing the given parameter.
100 => e.updaterate; // controlrate 100 hz
So having updaterate (or simili) on every ugen would allow on a per ugen-instance choice of "control rate".
Don't think this is the right approach.. now _this_ would imply some kind of control-rate network that runs outside of the chuck code, which is not what we want. In cases where you want to do things at less than sample-rate, using while{} is perfectly fine. (For me at least.) The problem I started this thread about is simply that when you do things at a control rate, you can't easily envelope your changes without running your loop at 1::samp, so you get zipper. cheers, Steve