<br><br><div class="gmail_quote">On Tue, Apr 5, 2011 at 2:33 PM, Seth Nickell <span dir="ltr"><<a href="mailto:seth@meatscience.net">seth@meatscience.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Mathieu,<br>
<br>
Thanks, I assumed (without checking :-P) that the dsp call happened<br>
every time, didn't realize it was a setup/patching call that registers<br>
my "_perform" function with a call graph. Exactly what I need.<br>
<br>
I think the difference in approach comes from the needs of the<br>
external. fiddle~ probably needs much larger blocks than typical to<br>
discriminate between low frequencies. In my case, I can run at 64<br>
sample sizes, but I'll take your whole CPU to do it. It might be smart<br>
to default to some internal buffering (say 512), and let people order<br>
the external to do really really low latency if they need it and are<br>
willing to pay in CPU.<br></blockquote><div><br>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.<br>
<br>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.<br> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
That said, Peter reminded me of an optimization that I hadn't<br>
implemented yet. AudioUnits are rarely asked to run below 128 sample<br>
block sizes, so it didn't make sense for the AU, and I forgot that it<br>
was on the TODO list from 2 years ago. ;-) By convolving very small<br>
blocks in the time domain, and switching to frequency domain for<br>
larger blocks, I think we can get excellent CPU usage at very small<br>
block sizes too.<br></blockquote><div><br>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)?<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
-Seth<br>
</font><div><div></div><div class="h5"><br>
On Tue, Apr 5, 2011 at 8:49 AM, Mathieu Bouchard <<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>> wrote:<br>
> On Mon, 4 Apr 2011, Seth Nickell wrote:<br>
><br>
>> Are the DSP calls liable to vary t_signal->s_n (block size) without<br>
>> notification? 64 samples, apparently the default on pd-extended, is<br>
>> doable without buffering for partitioned convolution on a modern<br>
>> computer, but it exacts a pretty high CPU toll, and if I have to<br>
>> handle random blocksize changes, it gets more expensive.<br>
>><br>
>> Also, since convolution is much more efficient around block sizes of 256<br>
>> or 512, perhaps I should default to one of these, buffer a little, and have<br>
>> a "runatpdblocksize" message or somesuch?<br>
><br>
> There's always a notification. Any change of s_n will result in a new call<br>
> to the dsp-function.<br>
><br>
> Note that it's best to make sure that the dsp-function is fairly fast most<br>
> of the times, because any patching may retrigger the dsp-function in order<br>
> to recompile the graph.<br>
><br>
> dsp objects working with some kind of blocks don't have to be using s_n as a<br>
> setting. I mean that you can accumulate several dsp-blocks in order to make<br>
> your own kind of bigger block. This is what [fiddle~] and [env~] do, for<br>
> example.<br>
><br>
> But some other object classes use s_n as a setting. For example, [fft~]<br>
> does. I don't know why this is not consistent across all of pd. (I'm not<br>
> saying either approach is better than the other.)<br>
><br>
> _______________________________________________________________________<br>
> | Mathieu Bouchard ---- tél: <a href="tel:%2B1.514.383.3801">+1.514.383.3801</a> ---- Villeray, Montréal, QC<br>
<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br>