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
Sorry. My bad. It's at the default as well. 44100.
Sounds all like a cheaper non pro iPad 2017 is the better choice.
But maybe they update the 12.9" this fall again?
They might remove the headphone jack as a "fix"
Some developers (e.g. brambos) already reported this bug in may, but there is no answer yet from apple.
https://forums.developer.apple.com/thread/77255
I'll look into this and see if there's any workaround possible in AUM, but most probably it's yet again buggy internals of iOS, and/or bad code in the failing plugins.
It seems that Auria pro can run upto 20 instances of quatromod while Aum fails after 4. So might be something in Aurias code that is missing in your implementation that the pros need to run. Just thought this might help
BTW, I think the batch-instantiation issue is another one than mentioned here. I can reproduce the issue with manually starting too many instances on my ipad pro 12.9". I tried Eos2 by AudioDamage. I had 6 instances running fine, but adding the 7th made all instances crash out at once. Reloading them manually one at a time, they all crashed out at the 6th, etc..
I'm 99% sure this is a RAM issue. The device console log gets flooded with "Eos 2(UIKit)[581] : Received memory warning." right before it crashes.
The fix is sad but simple: Use apps that require less RAM, or use less apps/instances, or get an iPad with more RAM.
Did you test this multiple times, rebooting the device between each round? Is this when creating the instances manually or when reloading a project? (reloading a project might involve state restoring, which does not happen when creating new instances manually). Just as with IAA, there's simply not much that can be done differently when hosting a plugin, so I'd be surprised if there was any "missing code" in my implementation
(It would rather be the other way around, maybe AUM does extra things like state restoring and enumeration of AUv3 plugin parameters for MIDI automation, that Auria does not?)
Well, the thing is that I am using an ipad pro 12"9 2017 and there is no ipad with more RAM ;0)...and I can start more instances of the same AU on my old ipad4
Don't own the new pro so can't really comment on that tbh. Aum works flawlessly on my air2. @skiphunt is your man
Then perhaps something in iOS are using up more RAM on the new pro than on the ipad4? For some reason, you clearly have more RAM available on your ipad4. However, this reason might just as well be that a bug in some framework that AudioDamage uses in their plugins causes a memory leak on newer models, wasting a lot of RAM and thus causing the iOS to kick out (crashing) the processes. (or, of course, bugs in iOS itself)
I'm sorry, but I'm not going to get too deep into beta testing right now. I set up a test at @gonekrazy3000 's request and I've already regrettably got more time in this request than I'd bargained for.
To answer your questions: I tested about 6 times. I rebooted 3 times with one hard reset and a couple memory resets. I also tested BM3 twice and Modstep twice. These were NOT restored projects in AUM. They were set up manually from scratch each time. The AUs in AUM get unloaded and turn red after 4 instances. Once I was able to get 5 AUs loaded.
That's all I'm in for on this today. Hope it helps.
Here's one more quick test... then I have to bow out of this testing for the day.
Set up one AUM channel. Did a restart first. ISEM AU was the input instrument.
I was able to load 6 instances of ApeDelay before it failed to load more, I added more AU fx to the reloaded 6 apeDelays on the same channel. Can seemingly load many instances of frekvens AU and Mani AU (stopped after 20 each but could've kept adding). To all this added SquashIt AU, but could only load 4 before failure. Reloaded the 4 SquashIt AUs to the growing chain. Same behavior with Quatromod, i.e. 4 instances. Loaded RF11 AU, but it capped out at 3 instances in this long chain.
This was all that would play because the DSP was then reading 99-105% DSP.
Seems specific AUs have specific total allowed instances in AUM. I found similar results in BM3 and Modstep. However, I was able to load 20 instances AU tracks of Phasemaker in AuriaPro with 20 instances of Quatromod (1 per 20 midi tracks) and then play the keyboard and record it with no issue.
CPU usage in this AP setup bounced around from 23-55% usage while playing and recording.
I'm on a new 10.5in iPad Pro with 256GB, running 10.3.3
At the moment, not running any beta apps.
Hope this helps.
Sounds about right. The Steinberg guys reported a similar figure with Phasemaker. I've optimized heavily to keep the plugins usable on iPad 4 and similar low-resource devices.
I could've added even more I think, but at that point it was starting to get a little ridiculous.
Ok I think I have found a workaround. You have to open the AU instance (and then close it) before loading a second instance. Doing this, I have been able to load 12 Quatromod without any problem...
But then, there is still a problem in AUM because I have saved my session, quit and restarted AUM...and reload the session and here, it will automatically add and load all the instances and of course it is crashing after the third instance...
Hope this help move everything forward
Well, how to explain this? I've NOW got 13 instances of Quatromod running in AUM without any issues. I could add more I think. @gonekrazy3000 @j_liljedahl
No crashing, stuck loads, or glitches at all.
The ONLY thing that's changed or that I'm doing different this time... is that I'm adding the Quatromod AU instances one-by-one to input that's generating audio, rather than adding the instances first with no audio being generated.
If I then quit out of this, and then relaunch AUM and reload last session, it gets stuck loading after the 5th instance of Quatromod. I did a memory reset and hard restart, then tried to reload last session and it gets stuck at the same place as before.
I'm pretty sure that if you install iConsole on your computer and connect it, you'll see a lot of "Memory warning" in the logs before the AUs crashes. There's no specific total allowed number of instances involved. iOS simply kicks out the processes when they don't respond properly to memory warnings (by freeing up some memory).
I wonder how many Phasemaker + Quatromod you're able to get running in AUM (no other AUs or IAAs)? I'd be surprised if AuriaPro uses a lot less RAM than AUM, but anything is possible in this world
(I'll definitely do some measurements)
Wow, this is really interesting! I can reproduce this workaround in AUM here. As far as I can see, this points in the direction of iOS bugs, again. Something in the AUv3 system makes RAM stuck until a plugins UI is opened. I'll make sure to check if any workaround is possible to build into AUM (except automatically open all plugins UI windows, which I rather not!)
Sounds exactly like the issue @mathieugarcia and I discovered while figuring out the issue with loading multiple instances in BM3. There's something really odd going on with AU instantiation in iOS pertaining to the state of the AU's viewcontroller.
I'm beginning to look in to this later today (I'm actually going to go buy a 12.9 this morning, which I'm really not happy about, because in my opinion that particular iPad is a dog with fleas, but I'll take one for the team), but I think we're getting in to some interesting RAM allocation issues that Apple really didn't prepare for when creating the AUv3 spec.
In reading all the test cases above, I'll note that most of the problems are happening with delay-based plugins. In a plugin that has interpolated delays, at instance we set aside the maximum RAM that the delay will need, at its longest setting, at its highest possible sample rate. For something like QuatroMod, there are four delays for the flanger, 14 for the chorus, and 18 for the diffusor. (The frequency shifter is not a delay-based effect, or at least not for the purposes of this conversation.) That's a total of 36 delay lines, and we allocate the RAM for them based on a maximum sample rate of 192kHz. Obviously, an iOS device can't do 192kHz today, but we learned the hard way that assuming everyone is going to run at 48kHz until the end of time will bite us in the ass a few months down the road when Moore's Law iterates.)
So, if you instance 6 QuatroMods, that's 216 modulated, interpolated delay line allocations. The people that came up with iOS's RAM management were probably Stassi interrogators in the 80s, and "heavy-handed" would be an understatement. When you couple that with the all the video vampire action going on in an iPad Pro 12.9 (which has to push twice as many pixels with the same graphics hardware as a 10.5) you get in to some weird situations.
Apple, despite all their "totally pro!" market-speak, really only expects you to do one thing at a time with your iPad. Doing 216 things at a time, as is the case with the six QuatroMod instances above, isn't really something iOS is happy about.
Why can an iPad Air 2 or Mini 2 do it when an iPad Pro can't? Simple: neither of those has to do 3-million-plus pixel screen redraws 120 times a second. The timed-loading method detailed above forces a more stately and robust RAM allocation that muscles its way in to the system than blasting that huge allocation at something that would really rather be making nice screen animations.
That's my opinion on the matter, anyhow. I am literally talking out my ass here until I get to look at things in a debugger and see what the hell's going on.
@Chris_Randall my tests suggest thay it's not just what (or how much) you're allocating, but also when you do it in the instantiation process.
Oh great! Looks like at least someone is getting some use out of those tests from yesterday.
I was mostly doing the tests to verify there's nothing wrong with this new 10.5 that I recently purchased, while I could still return it. There's another thread here implying there might be something wrong with the new hardware, and a growing rumor mill churning.
Thus far, I don't believe there's any hardware failure here. All appears to be software solvable at this point IMHO
I can run a couple more or so tests if needed later today... Especially if if prevents any developer from having to go buy another machine they really don't need or want.
Just outline specifically what you'd like me to try.
Cheers
Using JUCE, I don't really have control over that. Watching the stack, it looks like they blast the main thread and the UI thread at the same time. Obviously, we're allocating the delays in the main thread. One thing that might bear mentioning for these discussions, and maybe some of the people above who have been diligently testing can look for this:
Some of our products have a larger graphics allocation because they have an SVG background, whereas others are purely procedural, and have no binary include at all. For instance, the only thing in the Eos resources folder is an OTF font. But QuatroMod has several SVGs, including the background. In pondering it, I think that Rough Rider, FuzzPlus3, Dubstation, and Eos are 100% procedural (except for the font) while the rest all have at least a background SVG, if not several.
EDIT: I'm definitely going to have to get a 12.9 to test, I think. But yeah, I agree with @skiphunt that this can be solved either by Apple firmware or host timed loading.
If I do go grab a 12.9, I'll make a special plug where I can throw mutex locks at various parts and see if I can solve it at the JUCE level. But this would be best solved by either Apple or the hosts, I think. The plugin shouldn't have to know about the metal.
https://forum.audiob.us/discussion/20114/new-ipad-pro-12-9-2017-problem-with-latency-and-digital-noise-temporarily-solved/p12
are these issues unrelated?
Only inasmuch as the new gen iPads are a bit hinky in general, in everyone's experience.
To answer your question, I can only run 4 instances of Phasemaker + Quatromod in AUM (one instance of Phasemaker + Quatromod per channel) before getting a load failure. No other AUs or IAAs running.
In contrast to the 20 tracks in Auria Pro, each with a single instance of Phasemaker + Quatromod without failure.
Is there a resource bug that only comes into play when mult-instancing? I’ve only ever experienced this issue when using the same plugin.
If I instead mix and match the plethora of AU plugs on my iPad it seems I can get much more mileage out of the available system resources.
In simple terms, the first instance of an AU is never an issue. But if the host loads the next instance of the same plugin too quickly, iOS bombs out with weird symptoms.
Strangely enough, even though the framework is set up to encourage asynchronous (concurrent) loading of multiple instances, this is a big no-no. The host needs to carefully make sure that all instances are loaded sequentially instead or things may go pear shaped.
Which explains why mixing lots of plugins (or manually loading several instances) results in fewer issues than automatically loading multiple instances of the same plugin.
There are also some weird resource management shenanigans, but I'm not fully sure when they occur. They seem to be related to handling a plugin's viewcontroller (GUI).
Thanks for this very clear explanation. I hope the iOS Audio team is at least aware of it.