On Tue, Apr 5, 2011 at 2:33 PM, Seth Nickell <seth@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@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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list