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 Store

Audiobus is the app that makes the rest of your setup better.

(Fixed!) Audiobus 2 runs way smoother than 3

245

Comments

  • Ahh it’s a rod I made for my own back =)

  • @Michael said:
    Anyone who isn’t @supadom: have you tried out @supadom’s suggestion from the Loopy state saving thread? This is potentially significant because of the way AB3 (currently: I’m changing this soon) tries to keep apps in the session alive if they crash (or are quit manually, which to AB3 is the same thing). So quitting AB3 first might make a difference.

    Quoting here for convenience:

    @supadom said:
    Ok, I think I’ve made a small but ‘monumental’ discovery for my music making with AB3.

    I know it is probably common knowledge but to me it came through dots and dabs from different posts I’ve read recently.

    Anyway, here it is:

    I used to go nuts clearing sessions by soft and hard resets and god knows what else. About 20 minutes ago I

    1 cleared the session in Audiobus

    2 double tapped and closed all of the apps, AUDIOBUS LAST!

    That’s all.

    Every time I started Audiobus again all problematic apps (in my case Loopy hd and ToneStack) started in a flash.

    Now, I’m not saying this is a cure for crackles and anything else. This is my second Air 2 that I mostly use for music. For whatever reason it’s been quite stable and crackle free and syncing perfectly. I’ll report back.

    I‘m doing this after every Audiobus session. It works for me.

    I don‘t have much knowledge about the technical side, but could it be that the „launch into background“ thing is the major cause of all problems, because (if you don’t make sure that EACH APP you used is closed after your session) it creates IAA zombies that eat up CPU? Apps launched into the background and not opened into the foreground during an Audiobus session stay open in the background even after hitting „clear session“ and keep using CPU. Just an idea, but maybe the „launch into background“ routine of AB3 could be made optional? That would mean having the „wants to launch“ pop up again but not running the risk of IAA zombies.

  • @Martinj said:
    I don‘t have much knowledge about the technical side, but could it be that the „launch into background“ thing is the major cause of all problems, because (if you don’t make sure that EACH APP you used is closed after your session) it creates IAA zombies that eat up CPU? Apps launched into the background and not opened into the foreground during an Audiobus session stay open in the background even after hitting „clear session“ and keep using CPU.

    Yes, this is what happens. Personally, I always make a habit of foregrounding each IAA app at least once, as soon as possible after loading it (or loading a session with multiple apps).

    However, a problem with the current AB3 implementation is that it auto-relaunches IAA apps into background if you swipe them away while AB3 is still running! I bet this happens to a lot of users, and they wonder why there's still IAA zombies.. That's the reason one must always swipe away AB3 itself first, before the others.

  • Question: does rebooting truly kill zombie apps or it is more like they are still there in the background but they need to be fired up to access resources?

  • @j_liljedahl said:

    @Martinj said:
    I don‘t have much knowledge about the technical side, but could it be that the „launch into background“ thing is the major cause of all problems, because (if you don’t make sure that EACH APP you used is closed after your session) it creates IAA zombies that eat up CPU? Apps launched into the background and not opened into the foreground during an Audiobus session stay open in the background even after hitting „clear session“ and keep using CPU.

    Yes, this is what happens. Personally, I always make a habit of foregrounding each IAA app at least once, as soon as possible after loading it (or loading a session with multiple apps).

    However, a problem with the current AB3 implementation is that it auto-relaunches IAA apps into background if you swipe them away while AB3 is still running! I bet this happens to a lot of users, and they wonder why there's still IAA zombies.. That's the reason one must always swipe away AB3 itself first, before the others.

    My exact routine is:

    • make sure all used apps have been open in the foreground once
    • Hit „clear session“ in Audiobus
    • Go to the used apps, check if the Transport control of AB is gone and if so, swipe them up
    • Close Audiobus

    I guess this makes sure that all apps are REALLY closed. If you want to look for IAA Zombies it‘s a possibility to go to any MIDI Settings tab and check if there are any apps available that should be closed.

  • @j_liljedahl said:
    However, a problem with the current AB3 implementation is that it auto-relaunches IAA apps into background if you swipe them away while AB3 is still running! I bet this happens to a lot of users, and they wonder why there's still IAA zombies.. That's the reason one must always swipe away AB3 itself first, before the others.

    I think we really needed to have this conversation and I’m glad it is happening. Especially with the involvement of both you mr liljedahl and @michael.

    In the end it is in everybody’s interest so we can all move on: us to making music and you to your other projects.

    I personally wouldn’t mind if apps came to the foreground at launch if that’s the cure. The speed at which apps load in AB2 is at least twice as fast then AB3. The AB3 waiting time that I mostly spend worrying whether all of the loopy inputs will load and if not consequently stop other apps like ToneStack from loading correctly. Sometimes they do, sometimes they don’t without any apparent reason. This is why the ‘swipe AB3 first’ rule is helpful and I’ll definitely give it a try. In fact my ‘swipe AB last’ rule came from having read your post and not remembering whether it was first or last. I stand corrected.

    Anyway, when it works it works beautifully!

    Here’s last nights jam

  • wimwim
    edited November 2017

    @Martinj said:

    @j_liljedahl said:

    @Martinj said:
    I don‘t have much knowledge about the technical side, but could it be that the „launch into background“ thing is the major cause of all problems, because (if you don’t make sure that EACH APP you used is closed after your session) it creates IAA zombies that eat up CPU? Apps launched into the background and not opened into the foreground during an Audiobus session stay open in the background even after hitting „clear session“ and keep using CPU.

    Yes, this is what happens. Personally, I always make a habit of foregrounding each IAA app at least once, as soon as possible after loading it (or loading a session with multiple apps).

    However, a problem with the current AB3 implementation is that it auto-relaunches IAA apps into background if you swipe them away while AB3 is still running! I bet this happens to a lot of users, and they wonder why there's still IAA zombies.. That's the reason one must always swipe away AB3 itself first, before the others.

    My exact routine is:

    • make sure all used apps have been open in the foreground once
    • Hit „clear session“ in Audiobus
    • Go to the used apps, check if the Transport control of AB is gone and if so, swipe them up
    • Close Audiobus

    I guess this makes sure that all apps are REALLY closed. If you want to look for IAA Zombies it‘s a possibility to go to any MIDI Settings tab and check if there are any apps available that should be closed.

    This is my routine as well, except that I add add at the end:

    • When all apps have been quit, hold down the power button until the power off slider shows up, then press the home button until returned to the home screen.

    I almost never run into weird issues on my iPad Air 2 like I hear so much about here. I believe this, and religiously checking and disabling background app refresh, location services, and siri suggestions after every upgrade, are the reasons.

    [edit] oh ... and turning notifications off, except for a few cases, and Turning on "Reduce Motion" in the accessibility settings.

  • I'm on a 6s Plus with my issues and its odd because I don't think it's a lack of cpu power. I definitely can run all these apps individually outside of audiobus fine. I usually don't run more than tonestack/a resource light synth --> loopy and another chain with vocals -> aufx:space -> loopy. Ran fine back on audiobus 2

  • @Panthemusicalgoat said:
    I'm on a 6s Plus with my issues and its odd because I don't think it's a lack of cpu power. I definitely can run all these apps individually outside of audiobus fine. I usually don't run more than tonestack/a resource light synth --> loopy and another chain with vocals -> aufx:space -> loopy. Ran fine back on audiobus 2

    Interesting! I’ve had a rough time trying to diagnose because I’ve always thought it was super complex setups. If yours is doing it with just a couple, that’s definitely of interest

  • edited November 2017

    Yeah. It's really odd. Also of interest and I think I mentioned. Audiounits run better when open (the user interface) and get crackley as soon as the audiounit UI is closed. May be an entirely seperate issue tho

    Still managing to make lots of music but it is frustrating for live setups

  • edited November 2017

    @j_liljedahl said:

    @Martinj said:
    I don‘t have much knowledge about the technical side, but could it be that the „launch into background“ thing is the major cause of all problems, because (if you don’t make sure that EACH APP you used is closed after your session) it creates IAA zombies that eat up CPU? Apps launched into the background and not opened into the foreground during an Audiobus session stay open in the background even after hitting „clear session“ and keep using CPU.

    Yes, this is what happens. Personally, I always make a habit of foregrounding each IAA app at least once, as soon as possible after loading it (or loading a session with multiple apps).

    However, a problem with the current AB3 implementation is that it auto-relaunches IAA apps into background if you swipe them away while AB3 is still running! I bet this happens to a lot of users, and they wonder why there's still IAA zombies.. That's the reason one must always swipe away AB3 itself first, before the others.

    I did try to swipe up Audiobus first after clearing the ab session. It did seem to work for a bit but then today I found AUM zombie greeting me when I returned home in the afternoon.

    I only use this iPad for music and despite this I still get different behaviour almost every time I open the same session. It is mind boggling to me so I imagine it must be a nightmare for developers.

    @Michael maybe it would be better to make every app to come to the foreground at launch like it did in AB2? I know it wouldn’t be as sexy as just icons turning on but if that’s the reason for the troubles. I have to say that Loopy loads ok 65% of the time. When it doesn’t it normally gives me tap to fix on just one or 2 Loopy inputs. This in turn causes ToneStack to hang with tap to fix. When I tap it it goes to TS and then goes back to home screen (!). Then when I tap on Audiobus I see TS finally loading.

    The thing is that when there’s loading issues and I eventually manage to get it all working I’m always a bit worried there’s something not quite right with audio and don’t really trust it anymore.

    Coule there be an option in settings to load apps manually with state saving?

  • Option to switch between audiobus 2/3 loading style and a hidden UI (invisible) to cure the audiounit priority issue?

  • edited November 2017

    It just occurred to ma @j_liljedahl that indeed i hardly ever foreground AUM in my sessions as I have stuff mapped out to controllers. Maybe that’s the reason why I sometimes have a zombie issue.

    I’ll do more testing/noting in the next few days.

  • @supadom said:
    It just occurred to ma @j_liljedahl that indeed i hardly ever foreground AUM in my sessions as I have stuff mapped out to controllers. Maybe that’s the reason why I sometimes have a zombie issue.

    I’ll do more testing/noting in the next few days.

    Well, yes :) If you don't foreground an app, it will become a zombie.

  • @supadom said:
    @Michael maybe it would be better to make every app to come to the foreground at launch like it did in AB2? I know it wouldn’t be as sexy as just icons turning on but if that’s the reason for the troubles. I have to say that Loopy loads ok 65% of the time. When it doesn’t it normally gives me tap to fix on just one or 2 Loopy inputs. This in turn causes ToneStack to hang with tap to fix. When I tap it it goes to TS and then goes back to home screen (!). Then when I tap on Audiobus I see TS finally loading.

    Actually there’s an easy way to find out if it’ll help: reboot before using AB3. I’d like to hear from those having trouble - if this is enough to solve performance and setup problems, I have some ideas about how to solve the issue once and for all, without having to sacrifice the background launching.

  • @Michael said:

    @supadom said:
    @Michael maybe it would be better to make every app to come to the foreground at launch like it did in AB2? I know it wouldn’t be as sexy as just icons turning on but if that’s the reason for the troubles. I have to say that Loopy loads ok 65% of the time. When it doesn’t it normally gives me tap to fix on just one or 2 Loopy inputs. This in turn causes ToneStack to hang with tap to fix. When I tap it it goes to TS and then goes back to home screen (!). Then when I tap on Audiobus I see TS finally loading.

    Actually there’s an easy way to find out if it’ll help: reboot before using AB3. I’d like to hear from those having trouble - if this is enough to solve performance and setup problems, I have some ideas about how to solve the issue once and for all, without having to sacrifice the background launching.

    The normal 'swipe to off' or hold power and home until off?

  • @supadom said:

    @Michael said:

    @supadom said:
    @Michael maybe it would be better to make every app to come to the foreground at launch like it did in AB2? I know it wouldn’t be as sexy as just icons turning on but if that’s the reason for the troubles. I have to say that Loopy loads ok 65% of the time. When it doesn’t it normally gives me tap to fix on just one or 2 Loopy inputs. This in turn causes ToneStack to hang with tap to fix. When I tap it it goes to TS and then goes back to home screen (!). Then when I tap on Audiobus I see TS finally loading.

    Actually there’s an easy way to find out if it’ll help: reboot before using AB3. I’d like to hear from those having trouble - if this is enough to solve performance and setup problems, I have some ideas about how to solve the issue once and for all, without having to sacrifice the background launching.

    The normal 'swipe to off' or hold power and home until off?

    The former is fine, yup

  • @Michael I've tried restart and it does work.

    I also removed AUM from the input slot so I'm forced to foreground it on load

    So the list keeps growing ;) :

    BEFORE

    1 restart iPad
    2 load audiobus
    3 foreground problematic apps

    AFTER

    1 clear session
    2 swipe up audiobus, then all other apps

    AMEN

  • Nice. Everyone else? How’s that work for you?

    If this is truly it, then I’m going to figure out how to make sure apps shut down when removed from an AB session, and issue an SDK update. It’ll require cooperation from app developers of course, so it wouldn’t be an instant fix though.

  • edited November 2017

    Yea because I've had it work flawlessly before but I can't figure out the steps. Its too in the background without enough feedback to diagnose. I suspect apps hogging memory not getting closed or not making it into a priority audio thread or something. I dont know enough to say but sometimes model 15 works perfect with no problems at 128 but other times its all crackles. Seems super random but I know there must be a cause

    I wonder if there's a nice way to clear ram on a new session or something

  • @Michael said:
    Nice. Everyone else? How’s that work for you?

    If this is truly it, then I’m going to figure out how to make sure apps shut down when removed from an AB session, and issue an SDK update. It’ll require cooperation from app developers of course, so it wouldn’t be an instant fix though.

    As we've talked about long time ago, one can easily make this generic for any IAA host, not only AB: If the app has not been in foreground, let it kill itself when disconnected from host by calling exit(0). AUFX has had this trick implemented for a year now, would be interesting to hear if people experience IAA zombies with my AUFX apps or not?

  • @Panthemusicalgoat said:
    Yea because I've had it work flawlessly before but I can't figure out the steps. Its too in the background without enough feedback to diagnose. I suspect apps hogging memory not getting closed or not making it into a priority audio thread or something. I dont know enough to say but sometimes model 15 works perfect with no problems at 128 but other times its all crackles. Seems super random but I know there must be a cause

    I wonder if there's a nice way to clear ram on a new session or something

    Easy way to find out: reboot before every session. If glitches become a thing of the past: then we know

  • edited November 2017

    Damn. Just tried clearing session and closing model 15 (IAA not audiounit since that's a seperate issue). Didn't work so I cleared session and closed audiobus and rebooted. Still having crackles on 6s Plus :-(

    Really seeming random at this point because sometimes it works flawlessly. Ios is driving me crazy. Wish there was an OS dedicated to music and stability. That's what I'd drop money on

  • @Michael said:
    Nice. Everyone else? How’s that work for you?

    If this is truly it, then I’m going to figure out how to make sure apps shut down when removed from an AB session, and issue an SDK update. It’ll require cooperation from app developers of course, so it wouldn’t be an instant fix though.

    NB I've done this on one of my air 2s, the one without audio crackles but just loading and zombie issue. I'll try this on my other one that has been crackly.

  • edited November 2017

    I feel like plus phones might have some issue. Also diagnosing this problem is difficult since people have different settings on their phones but I'm trying to figure it out. Most of it is just beyond my tech understanding.

    However I've been so pleasantly surprised how much is possible on ios and it fits in my pocket. I support this platform and I'm going to continue to support audiobus since it's a hub that my music making hangs off of. To be fair tonestack (which I use mostly in live show) runs flawlessly on audiobus 3 as well. Model 15 is demanding so it's a good Stress test. Jim yonac has done a great job of optimizing his apps. I wonder if a quality option would help. I can run a bunch of pitch shifting algorithms and a tube amp sim at 64 buffer because there's a medium quality option in his app.

    I'm not sure if there's a way to include optimization options for people who want latency > sound quality. I like the audiobus 2 loading style option. Hide it in the advanced options as "manual loading (cpu efficient)" and its basically a switch to audiobus 2 code plus audiounits

  • edited November 2017

    Bangs head on desk

    Okay, so, something weird about the 6S Plus then. Fortunately I have one of those handy so I can do some experimentation when I get a second.

    Regarding disabling background launching: sadly it's not quite that simple. That will resolve the whole IAA zombie problem, but AB3 still needs to do what it does so that it can route MIDI around, and support AUv3 audio units - it won't make it into AB2. Besides, I'd prefer to try to get to the bottom of whatever's happening here, if at all possible.

    Trying to put together a summary of what we know so far:

    1. Audiobus 3 seems to exhibit some crackle-n-pop in certain situations where Audiobus 2 did not
    2. Rebooting addresses these performance issues for @Martinj, @wim and @supadom (on one of his iPad Air 2s)
    3. Rebooting doesn't solve the issues on @Panthemusicalgoat's iPhone 6S Plus

    Things still to find out:

    1. Whether rebooting solves performance problems for @Ben, @OscarSouth, @RUST( i )K', @Janosax and on @supadom's second iPad Air 2
    2. What particular issues @Zen210507 is seeing

    Updates:

    • @OscarSouth: Rebooting doesn't solve performance problems
    • @Ben: Performance problems were resolved without rebooting, but by letting session run for 5 minutes. Remained resolved after clearing and rebuilding session. (I have NFI what's going on here)
  • edited November 2017

    For myself it’s not so much a ‘problem’ that I can temporarily fix as that I can just run a decently amount less in parallel in AB3 as with 2. I figured it was the kind of thing that’d just incrementally improve.

    I’ve not had much time to use AB recently but I’ll explore with the newest versions when I get the chance.

  • @Michael
    I'm going to restore contents of air 2 16gb (no crackles) to air 2 64gb to see if it might be a hardware issue.

  • @OscarSouth said:
    For myself it’s not so much a ‘problem’ that I can temporarily fix as that I can just run a decently amount less in parallel in AB3 as with 2. I figured it was the kind of thing that’d just incrementally improve.

    I’ve not had much time to use AB recently but I’ll explore with the newest versions when I get the chance.

    Okay, so that implies that at least for you the problem is greater than IAA zombies hanging around the background taking up resources...

  • ^ @Michael - especially the MidiFlowAdapter app will remain in background regularly, even after deleting and clearing an ab3 session.

Sign In or Register to comment.