Feb 11 2014 | 12:03 am
    It would be good to know which object is eating up the CPU. Sometimes its impossible to figure out exactly which object is eating up CPU. Quite often, there is a particular object that will eat every signle bit of CPU, and its impossible to track it down... In M4L this sometimes happens after 30 minutes of using a patch, making it even more difficult to understand where and why it is happening. Just a simple % of each object and the CPU it is using would be good.
    Rant Over!.

    • Feb 11 2014 | 12:38 am
      Hi !
      i know .
      - sometimes it helps to find out how long it take for an operation to finish , i dont know any better way .
      if you are using preset interpolation , or automating parameters that are in relation with pattrstorage , you may see higher cpu utilization .
      EDIT : updated
    • Feb 11 2014 | 12:46 am
      Cool! This will help with the flow in certain processes. What about continuous processes? For instance if I have a counter driving a dial, the process never ends, so Im wondering how I can detect cpuclock time? Ive just put a [speedlim 50] on there for the time being, but id love to know why this is happening. Wish I knew more about these objects and how they can be used to optimise :)
    • Feb 11 2014 | 12:56 am
      you cant get precise results here as object that measure "stuff" also are doing their job with CPU at time .and often from time to time the result might vary , you can see also that UZI results differently (it bangs fast like crazy) , but the result is somehow compromised or optimized , not sure (or its spread over cpu cores ? really not sure ,as im seeing faster times than simple bangs).
      here you can bang your "buddies" as shown in the patcher through the middle outlet of "our" trigger .
    • Feb 11 2014 | 1:04 am
      as for optimization . the less on the road the faster / lighter for CPU .
    • Feb 11 2014 | 2:23 am
      a counter will always need the same processing power, for every value it outputs.