<br><div><span class="gmail_quote"> <b class="gmail_sendername">Ken Restivo</b> </span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Consider maybe adapting code Fons is writing.
<br><br><a href="http://www.kokkinizita.net/linuxaudio/">http://www.kokkinizita.net/linuxaudio/</a><br><br>His JACE is really fast. He's also rewriting it and creating a new convolution engine, with a goal of having any latency at all and being very CPU efficient.
</blockquote><div><br>Hi, Ken!<br><br>That one (I just read the intro just now) is FFT based. That's nice and I'm sure it's way faster then what I described but doesn't realy fit with this "do new things with ChucK's timing" thought experiment.
<br><br>Depending on exactly what the spectral stuff that Dan hinted at might be coming involves that might be a option for the future. Doing FFT math yourself still sounds a bit scary to me.<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;">
Or, using JACK to feed ChucK stuff out to an external convolution engine and back again. One of the bummers about ChucK using RTAudio is that it can't mess about directly with JACK graphs. It seems like a missed opportunity, when a sample-accurate, real-time music programming language doesn't have direct access to a sample-accurate, real-time audio engine like JACK.
<br><br>LADSPA and/or LV2 support inside ChucK would be really nice too. There are some fine "ugens" available in LADSPA format, and new ones coming for LV2 that are quite nice.</blockquote><div><br>Sounds like good ideas. On a practical level though; I have to confess to being a bit behind the times and actually using a spring-reverb when I need reverb most of the time.
<br><br>ChucKian-convolution (Chuckvolution!) was a bit of a thought experiment but I could imagine it being practical at times. For example one could use a IR that would end in a tail of noise that would eventually decay. Using LiSa one could loop the noisy end befor the decay during quiet passages or at the end of a phrase, then drop that loop at other moments to preserve clarity and headroom, for example.
<br><br>Convolution, like my springreverb, is nice but it's usually not very versatile once set up and roling your own, then doing new and weird stuff to it seems easier then having a CV-controled damper on a spring-reverb.
<br> </div><br>I'll be the first to admit that if efficiency is a issue then mine is a very bad idea. A less bad idea might be using LiSa to try to make a grain-based reverb like Ableton has?<br><br>Yours,<br>Kas.<br>
</div>