[PD] Making a Realtime Convolution External

Seth Nickell seth at meatscience.net
Tue Apr 5 21:33:44 CEST 2011


Hi Mathieu,

Thanks, I assumed (without checking :-P) that the dsp call happened
every time, didn't realize it was a setup/patching call that registers
my "_perform" function with a call graph. Exactly what I need.

I think the difference in approach comes from the needs of the
external. fiddle~ probably needs much larger blocks than typical to
discriminate between low frequencies. In my case, I can run at 64
sample sizes, but I'll take your whole CPU to do it. It might be smart
to default to some internal buffering (say 512), and let people order
the external to do really really low latency if they need it and are
willing to pay in CPU.

That said, Peter reminded me of an optimization that I hadn't
implemented yet. AudioUnits are rarely asked to run below 128 sample
block sizes, so it didn't make sense for the AU, and I forgot that it
was on the TODO list from 2 years ago. ;-) By convolving very small
blocks in the time domain, and switching to frequency domain for
larger blocks, I think we can get excellent CPU usage at very small
block sizes too.

-Seth

On Tue, Apr 5, 2011 at 8:49 AM, Mathieu Bouchard <matju at artengine.ca> wrote:
> On Mon, 4 Apr 2011, Seth Nickell wrote:
>
>> Are the DSP calls liable to vary t_signal->s_n (block size) without
>> notification? 64 samples, apparently the default on pd-extended, is
>> doable without buffering for partitioned convolution on a modern
>> computer, but it exacts a pretty high CPU toll, and if I have to
>> handle random blocksize changes, it gets more expensive.
>>
>> Also, since convolution is much more efficient around block sizes of 256
>> or 512, perhaps I should default to one of these, buffer a little, and have
>> a "runatpdblocksize" message or somesuch?
>
> There's always a notification. Any change of s_n will result in a new call
> to the dsp-function.
>
> Note that it's best to make sure that the dsp-function is fairly fast most
> of the times, because any patching may retrigger the dsp-function in order
> to recompile the graph.
>
> dsp objects working with some kind of blocks don't have to be using s_n as a
> setting. I mean that you can accumulate several dsp-blocks in order to make
> your own kind of bigger block. This is what [fiddle~] and [env~] do, for
> example.
>
> But some other object classes use s_n as a setting. For example, [fft~]
> does. I don't know why this is not consistent across all of pd. (I'm not
> saying either approach is better than the other.)
>
>  _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC



More information about the Pd-list mailing list