Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
AU Host Memory Issues
I've been helping debug a memory issue in a recent BM3 beta but I now believe the behavior I'm seeing is not isolated to BM3. I've been able to reproduce in AUM and in GarageBand. The behavior I first noticed was that if I was switching between songs I would eventually start having performance problems in the app that would require me to kill it and restart. After monitoring memory usage I could see that as sessions were loaded memory was never freed from the AU's in the previous session. An easy way to see it would be to load a session with a bunch of AU's and then create a new session with no instruments. Memory usage never dropped. I took a look at AUM and then GarageBand and I noticed similar behavior. It seems like the AU's are never told to shut down and are tied to the app until it's closed. Another way I verified this theory was that since I knew my iPad can only load four instances of Kaspar I loaded a single instance into AUM, cleared it and repeated until I had done this four times. On the fifth it crashed.
I'm not sure what to do moving forward. Is this a bug? Seems like an unwanted behavior. Who do I report it to? Apple? Is it the hosts responsibility? Does the AU spec allow for hosts to inform when a plugin should be unloaded/killed? Is that happening but the AU's are ignoring it? I'm leaning towards it being an AU/CoreAudio issue but I'm completely ignorant when it comes to AU dev.
I'd love to get your input @j_liljedahl @brambos @Chris_Randall
Comments
One more observation. I'm now realizing that it's not only the master process that stays resident for the life of the host but all instantiations of that plugin as well.
Does BM3 3.0.4 beta 7 (that was released just a few hours ago fixing some severe memory-leaks) work differently?
I get that, I had run into it initially with Kaspar. What I'm reporting now is that starting a new session or unloading plugins from an existing session does not close the plugins that were open and return memory until the host has been restarted. You can switch between project files and all of your previous plugins stay resident.
That was the bug I helped isolate but it seems that it resolved a different leak. I started looking at other hosts to make sure it wasn't specific to BM3 and that's when I observed similar behavior in AUM and GarageBand. I'd be curious how Cubase or Auria handle it. Guess I can check Audiobus as well.
Thanks for the report! I vaguely remember observing something like this long ago, when AUv3 was still new. I thought it was fixed. As far as I can see, it's a bug in iOS itself. Even though the host gets rid of the AU instance fully, it doesn't free up its memory. I think it's the AU's process (parent of all its instances in a given host) that is holding the memory.
Unfortunately I don't think there's anything the host can do about this. I just tried here with AUM and I see that AUM's own memory is released back to where it started when clearing a session. But reloading the same session multiple times indeed makes the AU fail to load, even though AUM's own memory usage hasn't grown.
Have you seen any AU where this does not happen?
@rezidue tried my app (sequencism), and I also tested it. It has the same bug
.
Maybe we should try to contact all host developers and file a radar?
Confirmed by watching the processes via computer running Instruments (developer tool), the AU's process grows for each AU instance, but does not shrink the same amount, so it accumulates until it crashes.
Wow this is so awesome to see the developers talk technology. So interesting.
But yeah, this is huge ai hopefully Apple can fix it. Maybe if we send Sampler’s dev a message? He might have some apple connections?
I do wonder if the pressure to release constant updates at faster phase has made Apple more 'sloppy' in the error/debug department...
...or they simply trust that the team handling Core OS 'garbage collection' works magic without others having to worry about it...
Hopefully Apple sorts it out and fixes it by iOS11.5 or something, iOS11.1 should drop soon...
Possibly this is how all iOS extensions work, except most other extensions are rarely unloaded because they’re loaded as part of OS processes. It’s a messy bug anyhow. All the more reason to do a restart every now and then.
This definitely explains why I was getting so many AU crashes while beta testing an instrument using different hosts. Switching hosts would not free up memory allocated by previous hosts.
Yeah you’re right. Perhaps this is the reason AB3 implemented the “Clear Session” option.
Could this help if AUM had this as well? Sort of doing a soft app restart?
Thanks for the responses. I was testing audiobus and it seems like it might successfully unload the AU's somehow (memory returned and I wasn't having that crashing issue reloading sessions) but I ended up hitting a different issue and had to get back to work. I'll look back into it later today.
"Clear Session" does not cope with this issue. As far as I know it simply unloads all the hosted IAA node apps in a controlled way, to work around another iOS bug that made only the first 4 or so hosted IAA nodes dispose correctly if the host terminates. It's the same as CLEAR in the menu of AUM.
As far as I can see, there's nothing a host can do about this problem. A host isn't allowed to kill the extensions process.
I tried in Audiobus3 and got the same issue there. So I still don't believe a host can do anything about it, unfortunately. Note that AUM opens each AU instance GUI offscreen (to workaround yet another iOS bug) and I'm not sure if AB3 also does that yet, if not then that might explain if you get a different amount of instances before the crash.
So this looks like the sequel to the IAA zombie movie.
I'd also like to figure out how best to bring this issue to apple. Along the other problem where hosts have had to load UI in the background to prevent crashing.
@Michael @Sebastian maybe you can shed some light on this process?
Sorry to take so long to chime in here guys. This is an issue Apple are aware of and are working on. Not sure if the fix will be in 11.1, but it won't be long after, I'd imagine.
That would be awesome, considering the bug has been there since iOS 9
#iOSLife
Would this necessitate rebooting the whole device to clear things up, or just the host? BTW, I agree with rebooting the device once in a while, but I'm just curious about this particular bug...
OK everyone, 11.1 is out. What are the team results?
Smooth sailing here on my Air 2.
I seldom bump into problems with updates but If I do I'm pretty vocal about it...
From what I’ve seen the original AU process + forks are cleared when the host is killed. Memory is restored.
This particular issue still exists in 11.1
Memory is restored properly when the host is killed so I believe it takes care of the 'zombie' AU processes/forks. I don't think a reboot is required.
I tested a few of the 11.1 betas and didn't notice a change in behavior.
Good to know! So for now, I need to remember to kill one host before starting another one. Thanks! for the info! Everyone should be informed of this!