Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Comments
I believe 10 instances is the limit of any given AUv3. Which is fine. If you're using more than 10 instances of any given plugin, the project would have brought the iPad to its knees long before you got there.
Anyone had a chance to test the weird AU instances / performance bug on the 2017 pros now that ios 11 beta 7 is out?
That would ensure sequential loading of the plugins, but is only a partial solution to the problem. Even loading several instances with seconds of delay in between leads to trouble - unless the user opens the UI of each instance. The issue is related to RAM allocation in the UI.
BTW, wouldn't a simpler way to ensure sequential loading be to use a dispatch_group_t that we enter before making the instance and leave in the completion proc?
Oh, forgot to mention that AUM already does sequential loading of both IAA and AU plugins. (the completion handler calls a block that loads the next one in queue, essentially). But apparently this hasn't helped much.
Do the GUIs really have to be opened or would requesting a pointer to the viewController (I forgot the precise name of the method) be sufficient? I haven't tried the latter yet, but it feels like this should trigger allocation of the necessary resources.
I have eight instances of audiomod playing at the same time in AUM without any problems. This is on a 2017 12.9 with latest iOS 11 beta. Not sure if that helps but thought I saw a post earlier if someone having issues >3 multiple instances of that plug-in in AUM.
So here is my theory... One thing that to my surprise has not been mentioned here is that each AU only gets one process per host. So multiple instances of a AU in a host all run in the same process. I ran into this early on when I started working on mine and I was working on the assumption that each instance had its own process so I didn't have to worry about sharing resources. This is NOT the case.
A misunderstanding of this fact can explain all the problems I have seen in this thread. The big main problem that is easily reproduced is the loading of a project. Loading a project loads all the instances in a smaller time frame and thus multiple instances are more likely instantiating at the same time. This also explains why there is more problems on the higher spec machines. They are probably loading things overlapping more.
Using singletons while not knowing this can cause havoc.
The one that I think is getting most of the problematic AUs here is the fact that the AU memory limit applies to the process not the AU instance. So using my app as an example I can reliably crash all my instances by adding 52 instances to one host. 51 can run just fine with no issues. My AU uses just under 7MB per instance so: 7*52=364 which is over the limit and the system kills. This is why high end pianos can only load one or two instances without getting killed.
Personally I think this is the wrong way to do it. They should create a new process per instance even if it takes more resources. And if not they need to be way more communicative about how it actually works.
Relevant Apple dev forum post: https://forums.developer.apple.com/thread/65909
This is the most probable explanation so far...and I prefer this one to the "screen taking all the memory" one that would have involved hardware problems...
Actually it goes hand in hand with the screen taking memory theory. Each AU instance needs more memory due to the higher res gui and faster refresh rate. It even explains why the 10.5 can run more instances than the 12.9 since it has a lower res display.
Hah yeah.. when I was first turning my Ruismaker engine into an AUv3 last year I had a massive WTF moment when I found out (the hard way) that resources were shared between instances. A lot of my nicely optimized C code had to be turned into C++ to overcome this.
I've now tried lots of possible workarounds in AUM. Adding a delay in between loading each instance made no effect. Accessing the UI of the plugin without showing it had no effect either, unfortunately. The only workaround I've found that has no weird side-effects is to actually show the UI of each instance and then close it after a very short while.
Now, all this could be done off-screen and not be visible to the user. But it's an ugly hack just to work around a bug in iOS! Might need to keep it though until Apple fixes it.
Hah ugly indeed. But do it for the Music!
I'm so glad the developers of apps are here to actually explain this stuff. I'm not much of a programmer but I understand the process a bit and I always wondered why these extremely powerful devices sometimes struggle with multiple but seemingly low resource intensive tasks
Thanks for explaining!
@j_liljedahl @brambos
hello guys, sorry for exhumation this old thread but i wanna ask if issue you discussed here is already solved in iOS or potentially it is still sleeping inside..
cause i'm experiencing some issues which coincidently looks exactly like this (not in aum, not with bram plugs - but asking because i did found this thread)