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