[PD] Making a Realtime Convolution External

Mathieu Bouchard matju at artengine.ca
Tue Apr 5 17:49:06 CEST 2011


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