Actually that is the idea I am trying to lead to as well with a patching and design documentation to help with.
I'd like to try to understand more about the "tax" of items for efficiency.
I think it would be very beneficial to document standard module CPU consumption, behaviours etc...
One thing I have learned is that a delay module seems to consume more CPU, when idle....then when fed an audio source it reduces CPU (I assume a threading function comes in). These kind of relationships I'd like to understand more and document for others as well.
Moreso, not necessarily a 100% detailed output from HH programmatically, but more of an understanding of how many Objects are used, and more understanding for optimizing complex patches to make them more compatible on multiple setups.
I can create a utility to parse the .pat file and give details about how many objects, what types, etc.... I will work on this, along with a patching design and rules.
Here is a question and idea though:
So one of the questions regarding "measuring and understanding CPU usage"..... If three types of CPU items are really in use....wouldn't it be beneficial to separate the CPU usage of these into their own Meter along with the combined output.
Say a Graphic CPU use meter, an Audio CPU use meter, and Object/Application use one....then the combined CPU output?
By having these available If someone has issues, I can understand quickly and easily to say "Your graphics card is not able to handle", maybe you should update it. Or possibly your audio driver, bloc, or buffers are not high enough. It would give a higher understanding of how the patch is working even on multiple setups, and understanding this over-time would lead to efficiency in designing user patches.
Would if be difficult to put CPU meters on the individual thread priorities? Maybe even under the debug options?
-SStatistics: Posted by sephult — 14 Feb 2015, 15:52
]]>