[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