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 Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

AUv3 vs standalone mode for ios apps cpu / memory usage query

Hi,
I was wondering if using AUv3 versions of apps on my iPad is more stable than having standalone versions open and running in the background? Does it make any difference to the CPU / memory usage?

Sometimes apps running in the background can crash / close, so I am looking into using an AUv3 host, but I wasn't sure if that would make any difference (as in instead of closing, it would say 'AUv3 invalidated').

I know using AUv3 has other advantages over standalone mode e.g it is easier for workflow than switching midi channels on the keyboard. But it is just the stability side of things I was unsure about. Any thoughts gratefully received!

Many thanks,
Adam

Comments

  • I'd say the main advantage of using AUv3, vs stand-alone background apps, is that the AUv3 host manages running the apps within the required time frame (one audio buffer). Background apps are just fighting for time in the typical Unix time-sharing fashion; the foreground app gets priority, and others can be starved.

    Memory usage will be about the same. AUv3 allows loading multiple instances of the same app, subject to a maximum total memory limitation, which is not possible with stand-alone.

    You can save a host session (preset), containing all the AUv3 apps, and loading that session restores everything; no messing around with individual app presets.

    You have much more control over audio and MIDI routing in a host. And you can MIDI Learn that control, so you can operate it from a controller.

  • Thanks very much for taking the time to answer, that is a big help. It sounds like the apps should run better within a host due to the sharing of the time you mention. Best wishes

  • This is going to depend very much on what the application is doing. An AUv3 on iOS is a standalone application. The AU is running in its own process space and there is a context switch at the OS level for every chunk of data that is processed through each AU. The main iOS audio thread is going to be running the part of the app that gets executed to produce the audio pretty much the same way for both cases. The dev can do lots of other processing off the audio thread in both cases if they choose.

    There are differences though.

    The memory limits are lower for AUv3.

    You can run multiple AUv3 instances, making a standalone app be able to handle multiple I/O ports with MIDI would be much more difficult.

    A non-AUv3 app can include the use of AUv3 apps. This could be useful even if the end user doesn't see the AU because it allows for the use of the builtin iOS AU's.

    The biggest pain for me in developing an iOS AU versus a standalone app is knowledge about, and control of, how the UI is going to be presented to the enduser. Just dealing with the fact that you can't handle text entry in your AU well makes designing an AU interface more difficult. This is much easier to deal with in plugins on the desktop.

    The only reason I can think of that would possibly make a standalone app more likely to crash in the background is that it might be more likely that iOS will ask for memory back and the app to respond poorly to this and be shutdown.

    So, it depends, for most use cases I think that it is going to be better to go with using an app as an AUv3 in a host. But, for those cases where there are reasons to use the software as a standalone app, it shouldn't be less stable unless there are bugs in the app.

  • Thanks, that makes sense. I only really use 3 apps for practicing and playing live music - Hammond B-3X, Korg Module and more recently SWAM tenor saxophone. I used to be able to use B-3X and Module fine running together as standalones with the ipad in flight mode, but adding the SWAM has made them more unstable and occasionally to close in the background. So I was looking at using a host, and this is why I was wondering about the stability of those running together in a host. Otherwise I would need to change which apps I was using (e.g organ sounds from Module instead of B-3X) if 3 apps are simply too much for my ipad to cope with at once. Hope that makes sense, I'm not much of an expert! Appreciate the help so far.

  • @Adamcw89 said:
    Thanks, that makes sense. I only really use 3 apps for practicing and playing live music - Hammond B-3X, Korg Module and more recently SWAM tenor saxophone. I used to be able to use B-3X and Module fine running together as standalones with the ipad in flight mode, but adding the SWAM has made them more unstable and occasionally to close in the background. So I was looking at using a host, and this is why I was wondering about the stability of those running together in a host. Otherwise I would need to change which apps I was using (e.g organ sounds from Module instead of B-3X) if 3 apps are simply too much for my ipad to cope with at once. Hope that makes sense, I'm not much of an expert! Appreciate the help so far.

    When running standalone apps, there are times where if the OS needs resources and an app has been in the background for a while the OS may crash them/force them to quit if it decides they are idle. I rarely have multiple standalone music apps running with background apps idle but when I do, things aren’t reliable for me.

  • Thanks, that's useful to know as to why they just close in the background sometimes. Much appreciated

  • @Adamcw89 said:
    Thanks, that's useful to know as to why they just close in the background sometimes. Much appreciated

    Yes, and I believe that should not happen when apps are loaded as AUv3, since iOS knows that they're being actively used, even though they are not receiving screen input.

Sign In or Register to comment.