Bradon, 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.
I hope this helps.
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__
-
Frank Barknecht -
William Fields