[PD] Making a Realtime Convolution External

[Charles Henry]

On Tue, Apr 5, 2011 at 2:33 PM, Seth Nickell <seth at meatscience.net> wrote:

> 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.
>

Here's where your users' choice of block sizes comes in--if your user puts a
partitioned convolution external into a canvas with block size 64, it means
to be low-latency.  If the user puts it in with [block~ 1024], then the
buffering is defined.

Pd means to be ~user~programmable and modular.  The more you try to monolith
your externals, the worse they work (I've done this).  I know I'm not
expressing it well, but I hope the point comes through.


>
> 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.
>

It sounds like you'd have a bit of a problem without first profiling the
system or having known profiles for different hardware.  Can you tell me
more about your partitioning method (just the math)?


>
> -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
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110405/477ee653/attachment.htm>