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
Very good to know/hope for...
Hi @Bon_Tempi, Hi@musikeer,
Thanks for your message.
Cubasis 3 should run fine with iOS 15, the reported Perforator and Envolver issues should be resolved in the upcoming update release.
Important:
We are unaware of dedicated Cubasis 2 issues with iOS 15!
If possible, please provide me with detailed bug reports asap, in order to have the team look at these issues.
Thanks
& stay safe,
Lars
I've been testing both Cubasis 2 and 3, Neo-Soul Keys 1 and 2, Perforator and Envolver, iPadOS 15, 15.01, 15.02 over and over for many days. It's a little mind-numbing trying to track down where the errors are. Cubasis 2 did in fact freeze constantly on an Air 3. Finally, NSK said that NSK2 isn't supported on the Air 3.
But what I believe I've narrowed down, are the constant freezes in Cubasis 2. I use Perforator and Envolver in many projects. It seems that even though Perforator and Envolver weren't working, they adversely affected the whole project(s). I re-imported some archived Cubasis 2 files, a lot with over 30-40 tracks, MIDI and audio, and the ones WITHOUT using the two MIDI apps seem to play back with no freezes.
I could never be sure whether 15.X, Neo-Soul Keys, Cubasis or the MIDI apps were the culprit. But as I said, it seems to all be centered around the MIDI apps not working. iOS 15x has been known to cause the screen freezes as well. 15.0.2 supposedly has corrected/addressed that. I haven't noticed any freezes since updating to that OS. This is all very confusing, making it difficult to pin down the reasons for freezing and unresponsiveness.
The point is, Cubasis 2 seems to be working fine in at least iPadOS 15.0.2. It’s been a fantastic app, hence my worries when things seemed to be going haywire. Technical term.
So you have CB 2 working fine on iOS 15, 15+?
One of the main reasons I’m still on 14.8 is because of some issues mentioned here about CB2.
So anyone on iOS 15. 15+ out there, that is having issues, please report your here or DM them to @LFS so they can figure it out. Thanks.
If you don’t have to update, no real need. But Cubasis 2 seems to be working fine in 15.0.2, except for the MIDI problems with Perforator and Envolver. Soon to be fixed in an update says Steinberg.
Bugs for me so far are Moog Model D graphical interface messed up, and Ravenscroft locking up when accessing the config menu. That's for the standalones, AUs fine in AUM.
I just got this in iPadOS 15.0.2:
What I did was:
I've not encountered this error in ages and I guess it could partially be the way I usually install apps...
...I always close all apps before installing any new apps or app-updates and then launch the stand-alone app first.
Good tip 👍 I will try to remember to close all apps the next time I install and update apps 😊
It's been working for me...
...my reasoning behind this is that apps on launch get a cached copy of AUv3/Extension list and when the list is updated in the background the app keeps on using the 'cached' list and since the cache is flushed/updated when installing apps the previously cached list is 'out dated'. (I don't know if developers have a way to monitor changes to the AUv3 cache or what ever it's called).
This was a problem with Logic way back when plug-ins requested a reboot so the caches could be updated.
I encountered this 'bug' the first time on iPadOS14.x or something (I had auto update enabled) and only a handful of times but after I disabled auto-update and started to manually close apps before installing or updating apps I've not seen it even once...
Thankfully a simple reboot solves the issue if/when it happens...
...and on reboot iOS/iPadOS automatically rebuilds the cache files...
I believe what you are referring to is called “garbage collection” in programming (not a joke).
Could be...
Don't really know what's causing it in practice but it something is fishy...
...I mean no one 'sane' would try to update an app that is already running and expect it to 'just work' without issues or?!
(Ie. Apple could take precaution and alert the user that the app/instance they are trying to update is in currently in use).
Updates to apps that do not rely on extensions, run in the background and do proper state-saves are not affect as much as they just reload the last saved states when the user launches the app after update. (This is pretty evident when updating some social media apps, they just 'relaunch/reload' after the update even if they were already running).
AppleTV takes this a notch further it just jettisons (ie. hard terminate) memory hungry apps when it does it's background app updates.
So for me I've ended up disabling auto-update and closing all apps before I download new or update existing apps and the 'issue' has not popped up even once.
And I have a hunch that since the 'problem' can be solved by a simple reboot Apple doesn't put too much effort into troubleshooting it...
Cheers!
I'm frustrated with iOS 15.
After the update, there are two virtual midi ports that will appear without opening any music app.
One is called Streambyter, and logically, it's tied to the Streambyter app. The thing is, even after uninstalling the Streambyter app, and rebooting my iPad Pro M1, the virtual port will continue appearing in the list of midi devices after some time.
The other port is named AK Virtual Midi, and I don't have any idea of what application is creating this.
So I tried to restore the iPad to the factory settings.
After an entire evening reinstalling each app, the Streambyter port is no longer appearing if I don't have the app installed.
But the AK Virtual Midi port will continue appearing in AUM after some time.
Just guessing here, something to do with AudioKit?
The AudioKit apps I have create virtual ports with their own names. The AK port may come from 3rd party apps implemented using AudioKit.
Thanks @NeonSilicon and @uncledave for the advice.
I tried all the AudioKit apps without luck.
At the end, I have found the solution via brute force.
Trying to uninstall every app one by one, and looking if the ghost midi port disappeared
At the end, the responsible was Spliqs.
https://apps.apple.com/us/app/spliqs/id1459170646
After uninstalling this, the port stopped appearing, even without having opened the app.
I updated from 13.7 to 15 recently and suddenly my AUM sessions now often won’t auto load the IAA apps unless I reboot- pretty annoying-
We do. The system sends a notification when the AUv3/IAA list was updated, that host apps can (and does) listen to. So the problem seems iOS sometimes breaks this list and makes it appear empty.
I noticed this today as well, but found a simpler fix. In both AUM and Audiobus, I saw virtual MIDI ports for StreamByter and MIDIFire. Now, I have run StreamByter stand-alone recently, but have not run MIDIFire since updating from iPadOS 14.8 to iPadOS 15.1, and both were not running at the time. I loaded SB, force-quit it, and the port was gone. I restarted AUM for good measure. So I loaded MIDIFire, and it gave an error "Could not initialize Core MIDI", probably due to these orphan ports. Force-quit MIDIFire, and its ports were gone as well.
So, you may just need to start the source app and force-quit it to erase these orphan virtual MIDI ports. And I'm not sure that they're actually a problem, in any case.
Yeah, opening and quitting the app will make the ports disappear.
And they will not appear again... until you restart your iPad. After powering off the device, I have found that the ports will return without opening the apps.
At least I have a solution to make the ports disappear, knowing from which app was the elusive AK Virtual Midi. This bastard drove me crazy.
Right. Sounds like there are bugs in certain apps, where the system queries them for something and they create their virtual ports, as if they were going to run, then they fail to close them down. If it's repeatable, we should maybe let the devs know, since there's no error logged.
You're a genius, @uncledave . Thinking in your explanation of the system requesting some services of the app, and opening the MIDI ports, I have finally find a solution that doesn't involve to delete the apps.
It was the damn Siri.
If you go to the Siri option in the control center app, you can see the individual options for each app.
I first deactivated the learning from this app option in Spliqs, the port continued appearing after some time.
So I also turned off the last two options, I don't know how they are named in English, but here is a screenshot:
And the ghost port is no longer appearing!
The last two are the "Show on Home Screen" and "Suggest App" options I think.
If you launch and then close one of the apps with the Search settings the way you have them now, does the port shutdown when the app closes?
This is good, but I'm sceptical. I saw these ports, probably after a restart, as you suggest. But I've always turned off all search options, except "Show app in search", the second of the five options. And they've been off for the apps I saw. We'll see how this works out.
@NeonSilicon @uncledave The port has appeared again, so it wasn’t Siri. Having the options activated or deactivated won’t affect the possibility of erasing the MIDI bus when you close the app.
The problem is that the ports will eventually return without opening the apps after a few hours.
I have disabled the other two remaining options in Siri, related with Search. But I’m skeptical. I think that the only solution now is Apple fixing this new iOS 15 bug in future updates.
nic, the author of StreamByter has an explanation in this post. Apparently iOS is trying to pre-start "frequently-used" apps, and some of them are not prepared to be launched in the background like this. So it's really something for the devs and Apple to straighten out.
Argh. It would be really helpful if everyone would stop trying to make everything "smart." Prelaunching and suspending to get faster launch times is silly if you ask me. Launching apps doesn't take much time at all as it is and I'd really like to be in control of what I have in memory and using resources.
Aum engine cut out. With a message to do with backround apps or magnetic cases ( from ios 14.5 ) onwards. What is all that about. Hope it isnt because of ipad stands. Might need background audio sometimes also.
Some ipad models have a problem with some magnetic cases, which interrupts the audio session due to some magnetic sensor in the motion co-processor. So if you have this problem, try getting rid of any magnets near the device. It's not related to AUM or any other specific app, it's an iOS/hardware/firmware issue.
What do you mean?