On 11/3/07, <b class="gmail_sendername">Stephen Sinclair</b> <<a href="mailto:radarsat1@gmail.com">radarsat1@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yup, I understand a lot of the issues involved. The problem comes in<br>when for example trying to compute filter coefficients, it's not<br>something that is really wanted at every sample.<br><br>On the other hand a possible part-solution might be to have it
<br>re-calculate the coefficients only while the value (e.g., cutoff) is<br>actually "sliding"..</blockquote><div><br>That would, I think, be a case where ChucK's dynamic control-rate could indeed yield savings.
<br>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.
<br><br>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.
<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anyways, I know that this is not an easy thing to answer, and in a lot<br>
of cases will depend on the particular UGen and so is difficult to<br>generalize. I'd think though that enveloping less demanding values<br>(FM parameters, for example) should be possible..</blockquote><div><br><br>Yes, indeed, and anything that can be re-expressed as sums and multiplications can be dealt with by a clever network of Gain ugens.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I dunno, anyways I thought I'd toss the idea out there. The reason I<br>guess it seems to be a bit of a problem with Chuck specifically is
<br>that you tend to want to abuse the sample-accuracy of it by doing<br>things like frequency modulation or LFO-based effects in a simple<br>while{}. But when you actually drop down to 1::samp, the CPU really<br>starts spiking. I guess maybe the answer is to just build that kind
<br>of thing into a UGen, but it sort of defeats the idea of doing nice<br>effects quickly using =>.</blockquote><div><br><br>I wonder how bad something like the <br><br><br>SndBuf b => dac;<br>Envelope e => b.rate
;<br><br>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.
<br></div><br>This would be one of those issues where I'm quite happy we have Ge to think of consistent solutions :¬)<br><br><br>Yours,<br>Kas.<br></div>