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"..
That would, I think, be a case where ChucK's dynamic control-rate could indeed yield savings.
I'm not so sure interpolation would help with swwps either, if we have two sets of coefficients that both yield a stable filter I'm not so sure we can interpolate from one set to the other and assume all of the stages in between will be stable as well.
The only real solutions there (as I see it) would be more "readymade" (perhaps importable and user constructible?) filters like LPF and so on where you can just set a frequency and have the C++ code deal with it or a lot of optimization in ChucK itself. If you want a sweeping filter those calculations will need to be done *somewhere* every sample in any case.
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..
Yes, indeed, and anything that can be re-expressed as sums and multiplications can be dealt with by a clever network of Gain ugens.
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 =>.
I wonder how bad something like the
SndBuf b => dac;
Envelope e => b.rate
;
example I gave would be for the CPU. theoretically it shouldn't be that bad as we have e.last() in the system anyway and the SndBuf would need to take it's rate into account every sample as well so perhaps some sort of asignment between the two could be used to get this effect "for free". This would of course run into unpredictable issues if somebody were to chuck multiple Ugens to a single parameter.... In that sense it's a lot less clean then what we have but it would be very powerful indeed.
This would be one of those issues where I'm quite happy we have Ge to think of consistent solutions :¬)
Yours,
Kas.