[PD] Making a Realtime Convolution External

[Seth Nickell]

Hi Charles,

I have a few partitioning methods. I used to do profiling when you
first load the plugin, to determine the optimal partitioning, but
found that on intel/amd cpus with sse3, it didn't vary much, and just
hardcoded a simple rule set for when to use each partitioning style.
In the more cross-platform context of pd, I think that profiling code
might make sense again, I'll see if I can resurrect it.

-Seth

On Tue, Apr 5, 2011 at 5:04 PM, Charles Henry <czhenry at gmail.com> wrote:
>
>
> 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
>
>