Dan;<br><br><div class="gmail_quote">2010/3/2 Daniel Trueman <span dir="ltr">&lt;<a href="mailto:dtrueman@princeton.edu">dtrueman@princeton.edu</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">i have no idea if this will help, but i&#39;ve been meaning to bring the old gQ filter stuff to ChucK for sometime. gQ is a really nice filter:<div><br></div></div></blockquote><div><br></div>
<div>That&#39;s a good idea in any case. More filters would be better. I&#39;d still like a a state-variable filter with three outputs. Such filters are spectacularly useful in modular synthesis yet often under-appreciated in the digital context.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div><a href="http://www.music.princeton.edu/~dan/gQpage/gQ.html" target="_blank">http://www.music.princeton.edu/~dan/gQpage/gQ.html</a></div>
<div><br></div><div>it might be more stable. maybe not. it usually sounds real nice. in any case, here it is, and it seems to work ok. probably should make a class out of it...</div><div><br></div></div></blockquote><div>
<br></div><div>Sounds great! I&#39;d say, BTW, that unless this is implemented as a new object with three outputs it could also be made a part of the old plan to extend LPF, BPF and HPF to be able to switch to different topographies.</div>
<div><br></div><div>I have to say though that the plain &quot;convenience&quot; filters like BPF are -from memory- 2nd order Butterworth filters. That&#39;s hardly a exotic type of filter. At the very least they should be stable for static settings with a reasonable Q. For what I understand of DSP there are two ways to get into the current situation; you can make a typo or reasoning error in the function that sets the coefficients or there can be instabilities induced by rounding due to finite word-length. These can be checked for, though of course at some computational price.</div>
<div><br></div><div>These, IMHO, need to be fixed, as something is plainly buggy there. How much time would this take from somebody who is fluent in C/C++ (needed to evaluate the rounding possibility) and not too scared of the Z-plane stuff? I&#39;d look into it myself but I&#39;d be out of my league in both fields.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>