mira cpu hog issues
Hello
I've created an interface for use with mira however running mira seems to be rapidly sucking a huge amount of cpu regardless of if I implement mira through max for live or run independently using the max standalone. After a few minutes of running the patch in max being controlled by chrome via mira my cpu in ableton begins spiking well above 100 and the audio drops out.
I have been toying with the max scheduler which seems to help a bit, however mira is still exhibiting very strange behavior in relationship to the cpu, after sending a notes out of my patch for a few minutes the ableton cpu monitor revs up quite high, 100-170% with dropouts- but then it calms back down to 50-60% after letting it sit and calm down for a minute, I play a few more notes and it skyrockets right back up to the cpu usage at it's peak, instantly reaching the 100%+ usage it had climbed to over the course of a few minutes of play but now from just a handful of notes- all of this INSTANTLY goes back to a normal cpu usage however the second I close the chrome window running mira, the cpu usage consistently immediately drops from 100%-150% to 20% upon closing the chrome window running mira. Have tried inside of microsoft edge and receive similar results
What can I do to optimize mira's performance? Are there schedule settings or anything else I can do in order to make it run more efficiently? My patch has 7 mira multitouch objects but all have been stripped down to be minimally demanding (just using for single finger tapping not multi finger gestures)
I've attached a download link to the patch below please let me know if you have any suggestions about how I could optimize mira to be less cpu demanding. I am running on windows 10 on a surface pro 4
Thanks so much
@whitelobster, can you give everyone an idea of how to reproduce the slowness? When you talk about CPU usage, you refer to Ableton Live. How is Live integrated? Do you see the same problems when you take Live out of the equation?
A set of numbered steps with descriptions for each would be incredibly helpful, thanks!
Also, it would be great to know if it is specific objects that cause this CPU drain or Miraweb in general.
Have you tried another browser? That is something that would be important to try, in case it is browser-specific.
FWIW, I did just do some profiling and it seems like there is a lot of seemingly expensive garbage collection, and definitely something we can look in to.
-Ben
Hi Ben
Thanks so much for getting back to me
I've tried using microsoft edge as a browser as well as chrome and have received identical results. I have also tried running the mira interface I created from within max via max for live rather than running the patch from a standalone version of max and it produces the same results. I'm not sure what taking live out of the equation would accomplish as that is what I am using to generate all of my audio.
Do please let me know if any of your profiling efforts reveal anything I could implement to make things run smoother/stop accumulating expensive garbage or if there is anything I can do on my end to help you gather more info.
Unsure how I would tell which objects are specifically causing drain- I've read about people in an OSX environment running Shark to determine which max objects are most taxing on the cpu but I've also read some people doubting that this is an effective way of monitoring individual object activity, also not sure how I would go about setting up a way of keeping tabs on individual max object cpu demands in a windows environment but if you would like me to try anything specific I'm happy to do so
Here are the steps that can reproduce the issue
1. launch the max patch in max standalone
2. launch ableton live and load up a channel with a synth and some demanding effects, reverb pitch shift etc, shouldn't be too taxing on the cpu but get it to the point where playing a few notes yields a 30-50% cpu load according to Live's cpu meter
3. in the max patch running in the standalone app-set the midi out to be in communication with ableton and press the OPEN button in the patch, then use the large circular buttons below the multitouch pad on the left to open a mirror of this interface in browser via mira
4. move your finger over the mira multitouch object in the mira window in browser (the largest one to the far left of the patch window), just play around, put your finger on it and move it around causing notes to be triggered and sent to live
5. after a couple minutes of this live's cpu meter will start peaking fluctuating between 100-170% , also dipping down below 100% but it will begin having very disruptive audio dropout and popping after a couple minutes of playing around sending notes to live in this fashion
6. close the browser window with the mira interface loaded into it and observe the live cpu meter drop waaaaay down instantly
7. now re-establish the link between the max patch and the browser by re-initiating mira from within the patch and play a couple notes the same way as before using the mira multitouch pad- you will see that live's cpu meter skyrockets right back up past 100% as if re-initiating mira instantly put some kind of burden on the cpu that it had accumulated during the last time the patch was used in conjunction with mira
- it is this behavior that seems very strange to me, the accumulated strain on the cpu that seems to be retained similarly to the burden placed on system memory when an application is quit but fails to release memory back to the system, only here we are talking about burden on the cpu not memory
8. if you close the mira browser window again at this point you will see the live cpu meter drop to a reasonable % again
Thanks!
@WHITELOBSTER can you send me a Live set so that I may reproduce here? I see no significant CPU load when following your steps. It would also be good to know what versions of Live and Max you are running.
-Ben
Hi Ben
Yes here is the attached live set. I am running the latest version of max 64bit alongside live 9.7
third party plugins you will need
massive
gsnap
fabfilter pro-L and pro-G
and three custom max for live devices I am including in the zip file, smooth pan, pitch shift and spectral_blur_turbo_dualiemix
please let me know if there is anything else I can send your way
Thanks!
@WHITELOBSTER
Could you remove all third party plugs? I won't be able to reproduce with those.
Also, do you have the same problem when you remove the custom MFL devices? There are too many variables right now to easily track down where the problem might be originating from.
-Ben
Hi Ben,
Yes the issue does still occur if the third party plugs and custom max for live devices are removed HOWEVER it does not cause audio dropout since the cpu is being taxed less in the absence of the plugins- WITH the 3rd party plugs+custom devices the live cpu monitor hovers at around 30-50% when at rest however revs up well above 100% as described in my previous posts once mira is introduced into the equation and continues to exhibit the problem with cumulative cpu burden-
WITHOUT these plugs/devices the cpu burden still accumulates in the same way however it does not cause audio dropout because instead of the differential being a jump from 50% to 150% instead it is only jumping from 10 or 20% to 85% (since the cpu is being taxed less to begin with with fewer plugins/devices)- still it exhibits the same behavior with cumulative unexpected cpu burden that is not released until the mira browser window is closed
You said you are having difficulty reproducing the issue but also mentioned that you noticed expensive accumulation while profiling mira, was this manifesting in a different way than what I've described?
Here is a new version with no third party plugs, also included a version without custom devices
Thanks!
@WHITELOBSTER
I'm running out of ideas for what to test, as I don't see any significant CPU load in Ableton. All of your projects hover around 15-20%, even after going at it for a while.
Does the problem happen when Miraweb is taken out of the equation altogether, just sending MIDI from Max? The activity in Max and Miraweb should have no significant impact on Live, as you are just sending MIDI, and Live should buffer it appropriately.
When I was talking about a CPU load, I was referring to some garbage collection in the browser, not in Ableton.
It seems like there is something very specific to your machine going on. Please follow up with support at cycling 74 dot com and we can do some further investigation. It may be that you will need to take this to Ableton to get their opinion, but I would suggest even further stripping down your examples so that we can continue to eliminate elements.
-Ben
Hi Ben
Thanks again for getting back to me. Yes the issue only happens if miraweb is opened and disappears the second it closes. It also never begins if miraweb is not ever loaded and the interaction is purely between max and live.
Sounds great re:contacting support-is there a transcript of your notes or everything you've tried that I could send them or if I email you my email address is there a way you could put me in touch with them directly with a synopsis of where we are at/what has been tried so far?
I'm not sure how this is possible, as the browser should have no interaction with Live. I wonder if Chrome is somehow blasting data out at a very high rate.
One thing to try is to put a speedlim on the output of the MIDI in your patch before it hits Live?
Just drop a note to Support and point them to this conversation, we can follow up there.
-Ben
i'm testing a new Max for Live patch and am working on an audio-dropout problem that occasionally pops up when i bring up a Mira connection in certain circumstances. note that this is Mira not Miraweb. my puzzler is still a little elusive and i'm leaning toward one of the plugins rather than Mira as the culprit. in order to get things to break more often during testing, i crank /Audio/Buffer Size/ way down (eg . 64 samples).
maybe the opposite (raising the audio buffer size in Live) would help in your case?