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.
Is there still a RAM/memory limit for AUv3?
If I am hosting a sampler or Loopy Pro in AUM, is there a storage limit to how much audio can be in an audio unit? I know there was a limit back in the day, but I don't know exactly what it would have applied to.
Comments
There are memory limits but Loopy Pro streams audio from disk. AudioLayer and Loopy pro stream from disk rather than load all the audio into memory. Some samplers load everything into memory.
So the memory limit doesn’t really impact the total amount of audio it accesses. The number of individual clips might impact the memory footprint.
Yes, the processor memory limit for an AUv3 is still in force, somewhere around 380 MB. The critical thing is that it applies to all instances of a particular AUv3, because the instances are actually the same program with different blocks of data. Obviously, how that affects audio will depend on how the AUv3 handles the data, as already explained.
In iOS 12 Apple allowed memory limits to grow from 360mb to higher if the underlying device had the memory to handle it.
For example, an iPad with 3gb of memory will most likely have its apps still limited to 360mb, a new iPad M2 Pro with with the 16gb option won’t. It’s up to the developer how and if it’s implemented.
My understanding is that the previous fixed memory limit was relaxed. One of the drawbacks of how Apple implemented the shared memory, AU get no chance to fail elegantly. They get no warning that memory is getting tight and don’t have a reliable way to check if there is enough memory for an operation ahead of time.
Thanks, y’all!
The limit is still there, and it’s different per device. But the developer has absolutely no influence over it. In fact we don’t even have a way to tell what the limit is or detect when the fatal overflow is going to happen.
So basically let it give a dump and have users pestering the developers while apple whistles? Nice of apple, always putting their customers first /s
In this case, pretty much yeah.
And I don't understand why. If someone wants to use all their RAM loading 25 instances of the same plugin, I say let them.
This restriction feels very arbitrary and not thought through.
So this doesn’t work for you?
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_kernel_increased-memory-limit
That talks about an app, not an AUv3, which is an Extension in Apple-speak. Apps also have memory limits, and are killed if they exceed them. Not sure if the features described would apply to an AUv3.
Technically an app and an auv3 should be similar in terms of programming and requesting memory allocation resources.
The host has no control of nor visibility into the plugin memory allocation though. So the host can't prevent plugins exceeding it and can't unload them gracefully if they exceed it.
Sooner or later people will have to commit to audio, even if not until the final mix down (weirdly that sounded in my mind like ‘The Final Countdown’). But depending upon iDevice & Host DAW workflow, those convenient little AUv3s might be best handled by “bouncing” to audio. Or… we could all just do what Apple wants us to do: buy the newest iPad and/or Mac every year.
I had read that starting in iOS 15 Apple made it optional for developers to have their apps use more memory, It wasn’t automatic in iOS, the developer had to code for it in their app.
https://developer.apple.com/documentation/bundleresources/entitlements#3855549
This is what a found in Apple Developer Documentation, section Entitlements, under: Memory
“ com.apple.developer.kernel.increased-memory-limit
A Boolean value that indicates whether core features of your app may perform better with a higher memory limit on supported devices.
Extended Virtual Addressing Entitlement
A Boolean value that indicates whether the app may access an extended address space.
Key: com.apple.developer.kernel.extended-virtual-addressing”
It's my understanding that this lets the AU use more memory but the memory is still finite and the overall mechanism is the same.
I don’t think it applies to extensions, but maybe if the host enables it, it will give AU extensions running inside it more room? I will check with my CoreAudio contacts when I get back home from my work trip.
I have just had a chance to experiment with this.
It is indeed not possible to assign this entitlement to AU plugins. Only to standalone apps.
Perhaps this will let hosts increase the memory sandbox per plugin when opening AU extensions, but I currently have no easy way of testing this.
So my best guess is that the situation around the memory limit for AU plugins has not changed in the past few years