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.
So iOS 14.2 and we still don’t see AU icons ...
![[Deleted User]](https://secure.gravatar.com/avatar/c1241fab1c3f179c559cb7bebf8a037d/?default=https%3A%2F%2Fvanillicon.com%2F8c4a4f5f2b4b040423d945ff430cbe39_200.png&rating=g&size=200)
The user and all related content has been deleted.
Comments
Yep, have had that. Feel like there’s something deeper and broken with AUV3 in iOS 14. Maybe something to do with new security features they implemented. I’m getting icons not appearing, a few times when reopening sessions message that all my auv3 aren’t installed. Touch not being registered when it works fine in standalone apps. WTH
Yep, you're right, they've not fixed it after all. I've let the Core Audio guys know.
Not fixed indeed. All AUv3s are disappearing from plugin lists in all my hosts (NanoStudio2, Cubasis3, GarageBand). Only a device restart will bring them back. That until they disappear again , usually not before long.
They still actually have a Core Audio team?
I figured it was one grumpy old guy working part time close to retirement (think Danny Glover in Lethal Weapon)
😁
iOS14 is the mobile equivalent of the Catalina dumpster fire they unleashed on desktop.
Yeah, I guess if it goes on like this, soon the best environment for music production will be Ubuntu 😂 (not even joking.)
Hope one of you smart devs in here can see, or think of how in the #$# hosts would suddenly say “no auv3 installed” after a period of time. And @god damn you’re right about a restart fixing it.
About went nuts going through tiers of support to get to someone who could even understand the issue. Can’t imagine the dark arts required for audio developers, but thanks for doing what you do, really.
Breaking news: Big Sur is now the desktop equivalent of the iOS 14 dumpster fire.
Got mail from lots of music software manufacturers warning users and recommending not to update to Big Sur.
This is pretty much on the software and hardware manufacturers. They've had since June to get this stuff working and since around 2 years ago to make any major changes they've needed for this macOS release. They just haven't been doing the work.
Having said that, if you need the tool for your job, you can't update when the new software is released. And even then, you've got to have snapshots of your entire environment for projects that need this kind of thing. That's one of the reasons that Apple's way of handling iOS updates makes it hard for me to see it as usable in a professional setting. You've got to be able to rollback to known previously good/working states.
FWIW, on desktop it has been the case on MacOS for all the big OS releases that audio apps lag in compatibility even on decent releases because audio
/music-related system calls get less testing on Apple’s side than other OS stuff...so the betas tend to be so buggy that a lot of developers don’t bother testing till late stage betas...and it takes a lot of time for Apple to then act on the feedback.
The problem has been exacerbated by the low profit margins on software development. Developers used to have devote more resources to testing and compatibility testing than they do now...and they would always have a machine or machines running whatever development release came out. That doesn’t happen so much any more. A lot of music developers (understandably) wait till release or near release of the OS to assess compatibility and whether or not to address compatibility.
And on Apple’s side, they also have fewer resources devoted to testing music and audio apps during OS development than they used to. So, Apple is less aware of the impact of OS bugs and changes.
In the 80s and 90s and early early aughts, Apple had evangelists inside Apple that advocated internally and externally for music software developers. I worked for a number of small developers during that period doing cool apps, and they would check in with us about OS betas and what problems there were. Those days are long gone.
These days, whether with iOS or MacOS, I assume that any major release is going to break things that might eventually require a paid upgrade. The bigger the OS change, the more fraught the release news will be on the music app side.
Any iOS 14.3 beta testers in this forum can confirm that any of the issues has been resolved?
@god curious about this too. I just looked at feedback I submitted when I was on beta. Saying similar reports “none” on both. Jonatan implemented some trickery in AUM and that seems to have fixed the icon thing for me, in AUM only. Hope everyone that experiences this submits. https://feedbackassistant.apple.com/
TBH, I have no idea where this type of bug should be reported and also since I can not reliably reproduce it not sure they will be much interested in fixing it. Like if you don’t explicitly tell them what x is causing bug y they will scratch their heads and toss the report back at you.
With few reports it’s not going to get any traction and you’re right if it’s submitted in GarageBand they would pay more attention. My SO is a project manager on something audio related there and she’s telling me it is a long shot, but worth a shot. Best bet is to have a DAW maker open a radar.
@god regarding the disappearing auv3. Do you have any TestFlight apps installed? I stopped testing all but a few today and still got that issue. One thing I did notice is opening TestFlight, a few of the apps said “renew” as if they weren’t installed and then a second later they changed to “open” since they are installed. Not sure if that’s common or has something to do with it?
I only have one TestFlight app installed which is not even a music-related app. I’ve been trying to pinpoint what exactly is triggering the AUv3 nuking and have been completely unsuccessful at that. This might be our best hope.. finding out what is causing this whole mess. From there it might be easier because we will know what to avoid doing and also will be easier to let Apple know how to recreate the bug.
I'd like to help trying to figure out what's happening here, but I haven't had this happen since I went to the 14.2 betas. I'm holding off installing the new beta (14.3) for awhile, so if you do get some hints about what triggers it, I can try and test it.
We already know that the AU icons will appear blank after a reboot (and reappear once you load any IAA icon); is this different?
Glad I’ve stayed on iOS13. I’m drivin’ this bish til the wheels fall off.
I've discovered that I do have one AU where the icon disappears after a reboot. So, I moved to the 14.3 beta. The issue still exists there.
Ugh.
I have just reported another major issue with AUv3 which has existed at least since iOS12... where newly installed AU plugins sometimes don’t show up until the device is restarted.
It’s super painful, because it makes AU-based apps appear broken and it has caused me a lot of refunds, 1-stars and support load over the years.
In some cases iOS simply doesn’t register new plugins until it is forced to do so by a restarts. Meh.
This has also been the case on macOS for ages. Many plug-in installers even have a note saying that a restart may be needed if the plug-in isn't available to the host...
The irony here is that manually installed plug-ins seem to be scanned more reliably than those installed using an installer.
(Ie. when manually dragging a plug-in to the plug-in folder a password is needed and thus any changed to the folder are scanned by the system).
The Renoise developers solved this issue by adding a plug-in scan that is done on each app launch and if new plug-ins are added while the app is running the folder can be manually re-scanned without having to restart the app.
I do feel part of the problem is that insane used of caches by the system and those caches are only flushed or updated/rebuilt when the system boots, there's no easy way to manually trigger the rebuild of the caches. (Ok, one can do terminal diving and delete some files and kill the responsible processes but it's faster to do a reboot).
Hopefully Apple listens to reason!
Cheers!
I have filed the Radar and then immediately escalated it to my contact in CoreAudio team's management. First time I've played that card, but it was beginning to hurt too much now.