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.

Audio Unit container app usefulness

I'm looking for some input from users of AU's on iOS about the usefulness of the containing app for the AU's.

I've released a couple of AU's for iOS through the app store and when I started developing them, I decided that I didn't want to do the thing of making it so the containing app for the AU presented the AU as an application that was available through the mic, or IAA or Audiobus. My reasoning was that these are really best used as AU's and that having them available through IAA or Audiobus would more-or-less degrade the namespace for those features in hosts. Basically, I thought it would be confusing for the names of the AU's to show up three different ways when only one of them is actually useful.

So, I decided to make the containing app the manual for the AU. To be honest, I was kinda surprised when this worked and the AU's were accepted on the App store. Well, there is a significant bug in the UI code for my LRC5 AU, and when I released what I hope is a fix the app was rejected because it doesn't provide any functionality. (If anyone wants to try the AU with the bug hopefully fixed, the link to the public beta is https://testflight.apple.com/join/PyNtum5r .)

I've communicated a bit with the review team and it seems that they don't consider the AU to be part of the functionality of the app, so I'm going to have to change the container app. My current plan is to make the AU available in the app to a mic (or interface) but not include IAA or Audiobus connectivity.

So, my question is, am I wrong about the thought of not having the AU work as an app with mic, Audiobus, and IAA connectivity? Do you find these features useful even from a small AU? Do you ever even open the app for an AU? Would there be something else that you'd like to see as a feature in an AU containing app?

Thanks for any input you have,
Rob

«1

Comments

  • edited March 2019

    do you think that this is a new policy? - Chris Randall (Audio Damage) has been complaining of the same. Seems like a big step backwards for developers.

    Maybe us developers could make a standard AU container app - perhaps open source it so we can all share it. dunno.

  • Ewww, if this is really the case now, I'll think twice about developing more AUs! The review process is frustrating enough as it is. And the risk of hundreds of hours of lost development time, essentially worth tens of thousands of dollars, is also a factor!

  • @pagefall said:
    do you think that this is a new policy? - Chris Randall (Audio Damage) has been complaining of the same. Seems like a big step backwards for developers.

    Maybe us developers could make a standard AU container app - perhaps open source it so we can all share it. dunno.

    I think it is an application of the already existing policy. It may be part of a new focus or something, but I don't know. I think the base cause is that the reviewers don't understand what an AU is and don't have sensible guidance on how to review them. That's just my feeling from the communication I've had so far.

    This could be caused by the way I did the container app as a manual too. Although, I don't really know of any more useful way of doing it.

    I'd certainly be open to contributing to an open source container for AU's. My plan right now is to take some of the code I have from my little internal AU host for testing and use that to host the AU in the container app.

  • Now to contribute something useful to the discussion: ;) -- I think the best way to handle this really is to simply make the container app the most basic AU host possible, and then (a) for audio AUs: connect the AU to the mic / speaker, and (b) for MIDI AUs: offer an interface for connecting to a CoreMIDI destination and listening for a CoreMIDI source.

    It actually always was Apple's official policy to reject "empty" container apps -- it's in the review guidelines. But it seems like it was never enforced until now. For example, @brambos' Rozeta suite is the same as mine (Xequence AU), the container apps are totally empty and all they do is present a screen that says that they're empty :)

  • Apple approving AU only apps has always surprised me to be honest. I realize that having a working standalone version is some extra work but I think not having one is just bad UX and confusing for users. So hate me if you want but I'd say this was to be expected. :#

    BTW, with JUCE you get the AU container for free, not sure about AudioKit tho, does it have one as well?

  • I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

  • @ka010 said:
    Apple approving AU only apps has always surprised me to be honest. I realize that having a working standalone version is some extra work but I think not having one is just bad UX and confusing for users. So hate me if you want but I'd say this was to be expected. :#

    BTW, with JUCE you get the AU container for free, not sure about AudioKit tho, does it have one as well?

    Why do you think that it is a bad user experience? One of the reasons I didn't want to include the AU in the app is that I think that will lead to bad user experience. I didn't want users opening the app and causing any possible clashes with other running audio applications.

  • @Samu said:
    I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

    I agree.

  • edited March 2019

    @NeonSilicon said:

    @Samu said:
    I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

    I agree.

    I put mine in folders to avoid the clutter.

    If the container app does not provide any further functionality than the AU, and if anything created in the container can be loaded inside an AU instance (via preset save) then no, no exposure via IAA or AB is really needed...BUT...if the container app adds anything, like Zeeon with the sequencer as part of the container but not the AU then having AB/IAA exposure would elliminate this issue
    https://forum.audiob.us/discussion/31736/em-bar-rass-ing-ly-simple-question-about-recording-zeeon-iaa-answered

  • @NeonSilicon said:

    @ka010 said:
    Apple approving AU only apps has always surprised me to be honest. I realize that having a working standalone version is some extra work but I think not having one is just bad UX and confusing for users. So hate me if you want but I'd say this was to be expected. :#

    BTW, with JUCE you get the AU container for free, not sure about AudioKit tho, does it have one as well?

    Why do you think that it is a bad user experience? One of the reasons I didn't want to include the AU in the app is that I think that will lead to bad user experience. I didn't want users opening the app and causing any possible clashes with other running audio applications.

    Well, in all of iOS there never has been a thing where you open an App to find an empty window, hence it's not something users expect to happen. Auv3 is a very special thing in iOS and most certainly not something everyone is aware of. Just imagine someone buys an AUv3 only app but has no idea what AUv3 is, he'll open it once then leave a bad review and request a refund.

    As for clashes with other applications, this shouldn't actually be an issue as audio session management will handle mixing or muting when setup properly.

  • @AndyPlankton said:

    @NeonSilicon said:

    @Samu said:
    I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

    I agree.

    I put mine in folders to avoid the clutter.

    If the container app does not provide any further functionality than the AU, and if anything created in the container can be loaded inside an AU instance (via preset save) then no, no exposure via IAA or AB is really needed...BUT...if the container app adds anything, like Zeeon with the sequencer as part of the container but not the AU then having AB/IAA exposure would elliminate this issue
    https://forum.audiob.us/discussion/31736/em-bar-rass-ing-ly-simple-question-about-recording-zeeon-iaa-answered

    I use Zeeon with for example Rezeta Cells in AUM. (The new AUv3 piano-roll sequencer discussed in another thread will most likely replace the other AUv3 sequencers if it doesn't get stuck in the review-process).

    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

  • @ka010 said:

    [...]

    Well, in all of iOS there never has been a thing where you open an App to find an empty window, hence it's not something users expect to happen. Auv3 is a very special thing in iOS and most certainly not something everyone is aware of. Just imagine someone buys an AUv3 only app but has no idea what AUv3 is, he'll open it once then leave a bad review and request a refund.

    I'd agree with it being a totally blank app. But mine has the manual for the AU in it. First thing I explain is that it's an AU.

  • @Samu said:

    @AndyPlankton said:

    @NeonSilicon said:

    @Samu said:
    I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

    I agree.

    I put mine in folders to avoid the clutter.

    If the container app does not provide any further functionality than the AU, and if anything created in the container can be loaded inside an AU instance (via preset save) then no, no exposure via IAA or AB is really needed...BUT...if the container app adds anything, like Zeeon with the sequencer as part of the container but not the AU then having AB/IAA exposure would elliminate this issue
    https://forum.audiob.us/discussion/31736/em-bar-rass-ing-ly-simple-question-about-recording-zeeon-iaa-answered

    I use Zeeon with for example Rezeta Cells in AUM. (The new AUv3 piano-roll sequencer discussed in another thread will most likely replace the other AUv3 sequencers if it doesn't get stuck in the review-process).

    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    If someone is new to iOS music, they buy a synth for example..then cannot use it because they don't have a host..and don't understand what AU even is, have never heard of Audiobus so don't know that this place even exists for help....they'll just ask for a refund.
    It also creates ease of use when you just want to mess about, not having to open a host, add a track, load an AU

  • @Samu said:
    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    Interesting, where exactly do you see this adding complexity?

    @NeonSilicon said:
    I'd agree with it being a totally blank app. But mine has the manual for the AU in it. First thing I explain is that it's an AU.

    Sure, I get that. I've had more than enough ridiculous app rejections so I know the feeling... just saying, if you look how Apple approaches UX, this one should not come as a surprise.

  • @AndyPlankton said:

    It also creates ease of use when you just want to mess about, not having to open a host, add a track, load an AU

    That's true, but then come the 'requests' to the developers to add audio-export, recording, midi in & out support etc. etc. which most of the 'hosts' already supply.

    On the desktop most plug-ins do not come with a stand-alone version but require the use of a host.

    In short AppStore should have a 'Audio Plug-In' category to make things more clear.

  • [...]

    If someone is new to iOS music, they buy a synth for example..then cannot use it because they don't have a host..and don't understand what AU even is, have never heard of Audiobus so don't know that this place even exists for help....they'll just ask for a refund.
    It also creates ease of use when you just want to mess about, not having to open a host, add a track, load an AU

    I can see this as being a possible issue. I actually mention it in the marketing material on the App Store. But, is this really unique to iOS? The same situation could occur with VST or macOS AU's. In all the years I had OS X AU's for sale I never had a single user ask a question about what an AU was or how to use it.

  • @ka010 said:

    @Samu said:
    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    Interesting, where exactly do you see this adding complexity?

    For example users starting to request added features to the stand-alone app that are already provided by the 'hosts' and other plug-ins.

  • @ka010 said:
    Sure, I get that. I've had more than enough ridiculous app rejections so I know the feeling... just saying, if you look how Apple approaches UX, this one should not come as a surprise.

    Yeah, I agree with you. Like I said above, I was surprised I got away with it to begin with. But, I did have hope that using it as a manual was going to work.

  • @NeonSilicon said:

    [...]

    If someone is new to iOS music, they buy a synth for example..then cannot use it because they don't have a host..and don't understand what AU even is, have never heard of Audiobus so don't know that this place even exists for help....they'll just ask for a refund.
    It also creates ease of use when you just want to mess about, not having to open a host, add a track, load an AU

    I can see this as being a possible issue. I actually mention it in the marketing material on the App Store. But, is this really unique to iOS? The same situation could occur with VST or macOS AU's. In all the years I had OS X AU's for sale I never had a single user ask a question about what an AU was or how to use it.

    If there's one thing I learned in all the years doing iOS stuff it's that people don't ever read anything, so I don't expect them to. When I started doing iOS plugins I also looked at them like VSTs but I think the ecosystems are in fact very different as are the people using it. Like you said, on the Mac you can expect a customer to know about the concept of plugins but on iOS that's not the case just yet I think.

  • @Samu said:

    @ka010 said:

    @Samu said:
    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    Interesting, where exactly do you see this adding complexity?

    For example users starting to request added features to the stand-alone app that are already provided by the 'hosts' and other plug-ins.

    Oh, yes from the dev-side sure, I was thinking from the users point of view.

  • My app descriptions immediately start with:

    IMPORTANT: This app is targeted at music production enthusiasts and requires an AUv3 Audio Unit Host to run! It does not do ANYTHING on its own!

    I wonder if that's enough? :)

  • @ka010 said:

    @Samu said:

    @ka010 said:

    @Samu said:
    When an app or extensions has multiple points of entry (ie. stand-alone and plug-in) it just creates confusion, that's how I see it.

    Interesting, where exactly do you see this adding complexity?

    For example users starting to request added features to the stand-alone app that are already provided by the 'hosts' and other plug-ins.

    Oh, yes from the dev-side sure, I was thinking from the users point of view.

    I'm thinking as an 'end-user' here. I seldom use stand-alone apps (with Gadget being the exception).
    Most of the time I just launch a host ApeMatrix, AUM, Cubasis or BM3 etc and continue from there...

    Hosts make it easier to 'find' a plug-in instead of having to traverse thru pages of apps on the home-screen.

  • @NeonSilicon said:

    [...]

    If someone is new to iOS music, they buy a synth for example..then cannot use it because they don't have a host..and don't understand what AU even is, have never heard of Audiobus so don't know that this place even exists for help....they'll just ask for a refund.
    It also creates ease of use when you just want to mess about, not having to open a host, add a track, load an AU

    I can see this as being a possible issue. I actually mention it in the marketing material on the App Store. But, is this really unique to iOS? The same situation could occur with VST or macOS AU's. In all the years I had OS X AU's for sale I never had a single user ask a question about what an AU was or how to use it.

    I think this is because it is a different set of users plus the AppStore itself...people buying synths on a Desktop are generally already invested in music making, and with the higher costs they do more investigation up front, or have used free or cracked VST/AU's already...with iOS and the millions of phone users and cheap app prices you are far more likely to encounter a complete beginner as the app store is in your hand, you don't have to go looking for the software like you do on desktop, it can just appear as App of the day.

  • @AndyPlankton said:
    [...] it can just appear as App of the day.

    I've got to admit that I hadn't actually considered that as a possible occurrence with my AU's :D.

  • @Samu said:
    I would much rather have all the 'AUv3 Extensions' as a 'List' in the Settings.app rather than 'app icons' to be honest...
    ...as they just clutter the home-screens.

    This is the way forward for Apple if they are serious about their own standards.

  • @ka010 said:

    [...]

    As for clashes with other applications, this shouldn't actually be an issue as audio session management will handle mixing or muting when setup properly.

    Is this really the case now? I've had clashes with different audio apps open and causing issues with glitching. I think it was due to sample rate differences.

  • @SevenSystems said:
    My app descriptions immediately start with:

    IMPORTANT: This app is targeted at music production enthusiasts and requires an AUv3 Audio Unit Host to run! It does not do ANYTHING on its own!

    I wonder if that's enough? :)

    No, you need to put in the notes to reviewers section in itunes connect.
    I’d put a one liner in the app description, but reviewers dont read it!

  • @midiSequencer said:

    @SevenSystems said:
    My app descriptions immediately start with:

    IMPORTANT: This app is targeted at music production enthusiasts and requires an AUv3 Audio Unit Host to run! It does not do ANYTHING on its own!

    I wonder if that's enough? :)

    No, you need to put in the notes to reviewers section in itunes connect.
    I’d put a one liner in the app description, but reviewers dont read it!

    I have my doubts that this would help. The reviewers don't seem to have read anything I've said in my appeal of the rejection or my questions asking for clarification.

  • @NeonSilicon Im now churning out AUv3 midi apps, which have the added problem of no sound.
    You need the standalone version to manage documents (openUrl) so that ppl can open your app with just a file.
    You may not have this yet, but you cannot yet access the appGroup directories from any other way from outside.

    imo, Apple reviewers are allocated on a random basis and run through a set of standard tests (eg is the submitters name Chris, if so reject giving random reason!!).

  • edited March 2019

    @NeonSilicon said:

    @midiSequencer said:

    @SevenSystems said:
    My app descriptions immediately start with:

    IMPORTANT: This app is targeted at music production enthusiasts and requires an AUv3 Audio Unit Host to run! It does not do ANYTHING on its own!

    I wonder if that's enough? :)

    No, you need to put in the notes to reviewers section in itunes connect.
    I’d put a one liner in the app description, but reviewers dont read it!

    I have my doubts that this would help. The reviewers don't seem to have read anything I've said in my appeal of the rejection or my questions asking for clarification.

    Yep, that's the case. I've even been asked to attach a video showing my app in action, and after doing exactly that, I got rejected again, saying that I "should attach a video showing my app in action".

    I also put very friendly, exhaustive explanations into the "Review notes" box in iTunes Connect every time (trust me, even though I'm a total ass on this forum, I'm extraordinarily professional in my business communications!). It doesn't help and I doubt anybody reads it.

    It's of course not nice of me to generalize this much. There's also been very, very good experiences with reviewers. It seems just the "quality bandwidth" there is rather high and Apple should try to get that under control. Maybe they should take it to their HR department.

Sign In or Register to comment.