On 1/9/2011 2:09 PM, ronni.montoya@gmail.com wrote:
Hello, one question, if i have a big patch with a lot of subpatches, is it possible to know which parts of the whole patch are consuming more cpu resources?
Is something like this possible?
One way I can think of that you could do this would be to open each
subpatch individually and then use the load meter (Media > Load
Meter) to see what the cpu load for each subpatch is, though this
may take a while for a lot of subpatches. You could also estimate
it by looking at where most of your audio/DSP processing is
happening. These are most likely to be the most cpu intensive parts
of your patch.
thanks
R.
On 1/9/2011 2:09 PM, ronni.montoya@gmail.com ronni.montoya@gmail.comwrote:
Hello, one question, if i have a big patch with a lot of subpatches, is it possible to know which parts of the whole patch are consuming more cpu resources?
Is something like this possible?
This sounds great, what about spawning each subpatch in a new thread, and have a simple processmonitor in the gui? That would also take a big advantage in the newer processor designs.
-- buZz
On Mon, 10 Jan 2011, Bastiaan van den Berg wrote:
This sounds great, what about spawning each subpatch in a new thread, and have a simple processmonitor in the gui? That would also take a big advantage in the newer processor designs.
Pd's execution order model forbids launching threads transparently in any sort of meaningful way at the patching level.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC