[PD] PD effiecientcy

[Frank Barknecht]

Hallo,

William Fields hat gesagt: // William Fields wrote:

> I've found that a lot of pd performance problems come from the GUI.
> While running your patch, open up the Windows Task Manager and keep
> an eye on the "pd.exe" and "wish83.exe" processes.  I've found that
> the "wish83.exe" process corresponds to the GUI and the "pd.exe"
> process corresponds to the actual audio/midi/control processing.
> Keep an eye on the CPU% usage for these processes while using your
> patch and you should be able to see what the bottleneck is.  
> 
> I've found that changing states (e.g. via pool or state) will cause
> a big spike in the GUI process because many numberboxes/sliders/etc
> are being updated at once.  Also, I've found that GOPs use up more
> GUI power.
> 
> If the GUI is the problem, try putting as much of the patch as
> possible in a sub-patch and keep that sub-patch window closed... so
> you only have a minimal amount of GUI elements on the screen.  This
> is where an external MIDI controller of some sort comes in handy,
> because you can tweak parameters without relying on the GUI.

This definitely is so. Because of this I've split up my rrad.pattseq
patch into several sub-modules. You have the GUI patch, which is very
graphics heavy and thus bad for audio performance, and then there are
copies of that patch without the GUI, but which can be controlled by
the main GUI patch. Also there is a toggle in rrad.pattseq which turns
off all graphic updates. Think of it like you'd use switch~ to turn
off audio computation in a subpatch. 

But you will be as pleased as I was to hear, that making graphics more
independent from audio is one of the goals for pd-0.38. 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__