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
    • Wetterberg
      Jan 11 2015 | 6:07 pm
      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.
    • Wetterberg
      Jan 11 2015 | 6:30 pm
      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?
    • carloskleiber
      Jan 11 2015 | 7:45 pm
      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)
    • Ernest
      Jan 12 2015 | 11:51 am
      it seems as if you are reloading the preset data in the background, without realizing it.
    • dtr
      Jan 12 2015 | 1:16 pm
      In principle something like this shouldn't happen but hard to advise without seeing the actual patch (and I don't mean a screenshot).
    • Wetterberg
      Jan 12 2015 | 11:31 pm
      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.
    • carloskleiber
      Jan 13 2015 | 3:51 pm
      Hello, I am experiencing problems to post in this forum since yesterday. Here's an attempt with another browser..
    • carloskleiber
      Jan 13 2015 | 3:57 pm
      It works, but only if I do not paste any code :S
    • carloskleiber
      Jan 13 2015 | 4:01 pm
      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.
    • carloskleiber
      Jan 13 2015 | 4:06 pm
      Ok here it is as a zipped attachment.