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.

The 27th Instance. A novel way of crashing AB

In theory, I should be able to put at least 26 different Streambyter instances in a session, indexed from A to Z. In practice, AB will usually crash at number 20.

My questions: is there some documentation in place for a case like this? How does AB handle a many-instance AU? Should there be some error thrown? Should 27 instances be avoided at all cost?

Just wondering what is in place currently...

Comments

  • Hmm, yeah it shouldn’t crash in any of those conditions... I’ll check it out

  • edited October 2019

    The one app that consistently gives up with multiple instances for me (usually >5) is @blueveek midi clone and filter MIDI FX app. It'll spontaneously give up the ghost in all instances and I have to reload. Pretty annoying in the middle of a tune.... Happy to send crash logs @Michael as it happens frequently enough that it's easy to capture. It's a really handy utility though--so great for filtering out MIDI channels with ease!

  • @lukesleepwalker said:
    The one app that consistently gives up with multiple instances for me (usually >5) is @blueveek midi clone and filter MIDI FX app. It'll spontaneously give up the ghost in all instances and I have to reload. Pretty annoying in the middle of a tune.... Happy to send crash logs @Michael as it happens frequently enough that it's easy to capture. It's a really handy utility though--so great for filtering out MIDI channels with ease!

    Does the same happen in AUM?

  • @wim said:

    @lukesleepwalker said:
    The one app that consistently gives up with multiple instances for me (usually >5) is @blueveek midi clone and filter MIDI FX app. It'll spontaneously give up the ghost in all instances and I have to reload. Pretty annoying in the middle of a tune.... Happy to send crash logs @Michael as it happens frequently enough that it's easy to capture. It's a really handy utility though--so great for filtering out MIDI channels with ease!

    Does the same happen in AUM?

    Good question but I don't know because I don't use AUM for my live setup. So, I never load up more than 5 instances of any app in AUM.

  • @wim
    @lukesleepwalker

    The same thing happens in BM3 so I don't think
    it's an AB specific issue and with less instances.
    I use the 'midi route', section specifically.
    It could be with the Auv3 itself.

  • Yes, that’s just what I’m asking. Is this an AU issue, a host-app issue, where can we learn about the limitations of multiple instances? Are there guidelines for developers and users?

  • @Zetagy : what iOS device and what OS version? Every AU instance "group" has a shared memory limit and all of them will crash when the shared memory limit is exceeded. With 20+ instances you might be hitting that.

  • edited October 2019

    iPad Pro 12.9, second gen. iOS 13.1.2, AudioBus 3.4.11. Where can be found more info about this shared memory limit, and is there a way besides overloading the device to find out when I’m hitting it?

    An idea for a new app: An AU plug-in that monitors all the other plug-ins and the health of the host app-! Is that the way to go with this? Like a midi monitor, but another monitor to view the system under the hood...

  • edited October 2019

    @espiegel123 said:
    @Zetagy : what iOS device and what OS version? Every AU instance "group" has a shared memory limit and all of them will crash when the shared memory limit is exceeded. With 20+ instances you might be hitting that.

    i'm suspicious there isn't this memory limit in iOS13 anymore.. memory heavy apps like Ravenscroft or iSymponic which were crashing on iOS12 are now stable and capable run more instances on iOS13

    or maybe they just increased that limit...

  • @dendy said:

    @espiegel123 said:
    @Zetagy : what iOS device and what OS version? Every AU instance "group" has a shared memory limit and all of them will crash when the shared memory limit is exceeded. With 20+ instances you might be hitting that.

    i'm suspicious there isn't this memory limit in iOS13 anymore.. memory heavy apps like Ravenscroft or iSymponic which were crashing on iOS12 are now stable and capable run more instances on iOS13

    or maybe they just increased that limit...

    Is the reduced crashing incidence true in iOS 13 across devices or only across devices with lots of RAM?

    It seems like the evidence is that the RAM limit was raised in iOS 13 (at the very least) but all the reports I've seen about better experiences have been from people with higher RAM devices.

  • @Zetagy said:
    iPad Pro 12.9, second gen. iOS 13.1.2, AudioBus 3.4.11. Where can be found more info about this shared memory limit, and is there a way besides overloading the device to find out when I’m hitting it?

    An idea for a new app: An AU plug-in that monitors all the other plug-ins and the health of the host app-! Is that the way to go with this? Like a midi monitor, but another monitor to view the system under the hood...

    Not sure of a central repository of information about the memory limit info for iOS 13.

    If you search here or on Google for AUv3 memory limit, you will probably turn up some information.

  • wimwim
    edited October 2019

    @Zetagy said:
    An idea for a new app: An AU plug-in that monitors all the other plug-ins and the health of the host app-! Is that the way to go with this? Like a midi monitor, but another monitor to view the system under the hood...

    Would be great, but impossible on iOS for an AU plugin. Apps don't have any access to resource usage information of other apps. Hosts themselves barely do. I've read that even hosts can't measure this. They may be able to detect if it has happen and give a more graceful exit than they do, but from what I've read, there's no way of measuring or predicting when it will happen.

    I'm not a developer, I'm just paraphrasing developer comments and discussions that I've read. The part about it being impossible for an AU app to monitor other app and system resource usage is definite though.

    iOS isn't like other more open operating systems like Linux that expose more system level information to apps. Apps run in a a closed and very sandboxed environment. AU apps even moreso.

    There are no definitive manuals or guides for predicting what your system can handle. The only way to achieve a reliable setup is to test it over and over, then to change as little as possible about it.

  • Well, yes. I’d like to know more about my own device’s host app capability, as it’s running. Wishing for an AU that monitors my setup

  • wimwim
    edited October 2019

    @Zetagy said:
    Yes, that’s just what I’m asking. Is this an AU issue, a host-app issue, where can we learn about the limitations of multiple instances? Are there guidelines for developers and users?

    There are the barely even guidelines for developers. None for users. Experimentation is the only practical solution. This forum is a great place to come for troubleshooting help though.

  • @Zetagy said:
    Well, yes. I’d like to know more about my own device’s host app capability, as it’s running. Wishing for an AU that monitors my setup

    As @wim said, the sandboxing (which is there for security reasons: to prevent viruses, malware, exploits, etc) on iOS limits the information that AUs can gather about other AUs and apps and limits what info apps can access, too.

Sign In or Register to comment.