[PD] Making a Realtime Convolution External

[Matt Barber]

> Just scanned the source... big difference would be performance, and if
> you're picky (you have to be pretty picky, honestly), some difference
> in accuracy due to floating point's reduced precision at large/small
> values. Convolution is still expensive enough for performance to
> really matter.
>
> the biggies:
> - partconv implements a single fixed block size, but freq domain
> convolution is faster by far on bigger blocks (peak on a core duo is
> near 4k sample blocks). implementing growing block sizes makes a big
> difference to low latency performance (e.g. 64 64 128 128 256 256 512
> 512 1024 1024 2048 2048 4096 4096), as you can get low latency while
> most of your convolutions operating on the ideal high-performance
> block size.


I was putting one of these together in Pd vanilla with dynamic
patching as an exercise a few years back, but there were some problems
I had. I think you can just do a simple 64 128 256 512 etc. and let
the block delay take care of the timing automatically, but I actually
found the kind you posted here to work a little better. Another one
that worked even better was something like 64 32 32 64 64 128 128 256
256 etc., which seemed to front-load some of the calculation a little
(and with this one and the one you posted, if Pd's block size were 1,
you could do the first block as a direct convolution for extreme
low-latency).

Anyway, this brings up a problem I've been wondering about with Pd --
If you have lots of reblocking going on I have been assuming that if
you had, say, one patch blocked at 64, another at 128, and others at
256 512 1024 2048 and 4096, that at the end of the 4096 block all 7
patches will have just finished a block cycle and there will therefore
be a CPU spike relative to other places between the beginning and end
of the 4096 block as the calculation for all 7 is done. Is there a way
in Pd to offset larger blocks by a given number of samples so that the
calculation for that block happens at a different time? It's easy
enough to delay the samples -- that's not what I want. I want to delay
the calculation as well, so that you could deliberately stagger the
blocks and more evenly distribute the calculation in cpu-intensive
situations. I'm imagining something like two 4096 blocks running say,
64 samples apart so that one is does its calculation while the other
is still collecting samples.

Matt


> - vectorization (sse/altivec) of partconv would give a 2-3.5x performance boost
>
> -seth