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