high number of presets draining CPU?

    carloskleiber
    Jan 11 2015 | 4:22 pm
    Hello, I use personalized store/recall systems in my Live sets and each time it is as the preset gets fuller that the CPU raises, causing frozen screen and lack of response with MIRA. I realize my patches probably can be optimized a long way, but there are situations where you cannot replace live.objects by live.remote~s. So, what else can be in cause for a high CPU? Inexisting entries in dict? Error messages in the max window? Missing ids? Or of course, too many live.objects with too much happening. But actually I really suspect the elevated number of presets. I would love to have your opinion, carloskleiber
    • Jan 11 2015 | 6:07 pm
      Wetterberg
      It's pretty easy to test. Delete all your live.objects and see how that affects your cpu. Then reload and delete all your presets.
    • Jan 11 2015 | 6:30 pm
      Wetterberg
      oh, and opinions, I forgot about that :)
      I've never had presets be a problem. Like, what are we looking at here... thousands of presets?
    • Jan 11 2015 | 7:45 pm
      carloskleiber
      To respond to the idea of erasing the live.objects: how can I compare a device that does something on a preset recall - changes the tempo, looks up for clip names and triggers them, recalls effect parameters - to a device that does not do the actions: even if the preset recall is correct, I will never know... Besides, in this case I am talking about high CPU from the symptoms, not that I can read the value anywhere (I could probably, in Activity Monitor) ...And no, it does not need that many presets. Let us say I clear the preset/pattrstorage system and everything runs fine, and with 15-20 presets I might already have a noticable slowdown. If I erase the presets, my speed is back again. edit: The only extra thing that I do is naming some of the presets (slotname)
    • Jan 12 2015 | 11:51 am
      Ernest
      it seems as if you are reloading the preset data in the background, without realizing it.
    • Jan 12 2015 | 1:16 pm
      dtr
      In principle something like this shouldn't happen but hard to advise without seeing the actual patch (and I don't mean a screenshot).
    • Jan 12 2015 | 11:31 pm
      Wetterberg
      yeah, I'm thinking there's a patch problem, along the lines of what Ernest is suggesting. And like DTR said, that's really incredibly difficult to diagnose without the patch. It' like trying to guess what the weather is like at Ernests house by looking out of your own window.
    • Jan 13 2015 | 3:51 pm
      carloskleiber
      Hello, I am experiencing problems to post in this forum since yesterday. Here's an attempt with another browser..
    • Jan 13 2015 | 3:57 pm
      carloskleiber
      It works, but only if I do not paste any code :S
    • Jan 13 2015 | 4:01 pm
      carloskleiber
      I try a trick and post the patch as an attachment. It is a device that you throw to the leftmost track and it will store and recall the parameter values of the devices on the tracks, the clips by name on 4 tracks, BPM and solo and mute settings. In its present state it has the problems as I described. Thank you in advance for having a look into it.
    • Jan 13 2015 | 4:06 pm
      carloskleiber
      Ok here it is as a zipped attachment.