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.

What Are Users Expecting From Your Music Apps?

Did you ever download a new music app and think hey...why doesn't it have this very obvious feature? Well in this video we'd like to highlight some make or break functionality most music app users are expecting so devs can be prepared.

AUv3 Support (1:58)
Audiobus / AUM Support (4:01)
Multi DAW Optimization Support (5:54)
Drag & Drop Support (7:00)
Nice Preset Browser (8:56)
Audio / MIDI Auditioning (10:40)
Audio Visualization (12:12)
Smooth Dials / Mouse Support (13:04)

UPDATE:
We've compiled a full list based on everyone's comments in a new blog post here -> https://mobilemusicpro.com/blogs/news/what-are-users-expecting-from-music-apps

«1

Comments

  • I’m expecting them to work as advertised. When expectations fail to be met, the app gets no further use or becomes a target to be refunded.

  • @NeuM said:
    I’m expecting them to work as advertised. When expectations fail to be met, the app gets no further use or becomes a target to be refunded.

    Hah I think that's a given NeuM. I was thinking about perhaps specific features that most apps should come standard with in 2022 and beyond.

  • ...to make music in a stable environment. If I can make music in an app w/o it crashing, that's all I care about. The weekend is here, and Drambo 2 experimentation time is almost upon me!!! 😈

  • C H A O S

  • @jwmmakerofmusic said:
    ...to make music in a stable environment. If I can make music in an app w/o it crashing, that's all I care about. The weekend is here, and Drambo 2 experimentation time is almost upon me!!! 😈

    Yeah stability is about the most important thing to me. I want to be able to trust things for live use.

  • Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

  • @iOSTRAKON said:
    C H A O S

    👍

  • @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

  • @robosardine said:

    @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

    Yes it appears not enough apps have thorough manuals that's certainly a must.

  • edited May 14

    @MobileMusicPro said:

    @robosardine said:

    @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

    Yes it appears not enough apps have thorough manuals that's certainly a must.

    The tutorial scene on Youtube seems to have taken up the slack here. I think it may be a case where, given the sales outlook, maybe the ROI isn't there to start writing full-blown manuals. Maybe a “quick start guide” until the tuts start showing up on YT. And I’m not sure we should hassle the devs about this until the app store business model is more favourable towards them.
    We’ve already lost future development on a couple of crucial apps. I went all-in and spent a small fortune when I discovered a couple of months ago just how good the apps had become over the past 5-6 years or so - only to discover the best devs are so frustrated they’re walking away.

    To me the only “non-negotiable” should be AUv3 and maybe MIDI learn features right in the app for us plebs who might prefer to work in DAWs other than AUM.

    At the risk of sounding like a simp I think we should be asking the devs what they need from us, given the limitations of the app store, to keep them motivated. Theres probably no good answer.
    We’re all in the same boat I guess…

  • @BroCoast said:

    @jwmmakerofmusic said:
    ...to make music in a stable environment. If I can make music in an app w/o it crashing, that's all I care about. The weekend is here, and Drambo 2 experimentation time is almost upon me!!! 😈

    Yeah stability is about the most important thing to me. I want to be able to trust things for live use.

    And me for production use. :) Either live or production, it simply must work. Nothing worse than a massive crash harshing the flow.

  • I would think a Randomize button would make the list, at least around here.

  • @BirbHope said:

    @MobileMusicPro said:

    @robosardine said:

    @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

    Yes it appears not enough apps have thorough manuals that's certainly a must.

    The tutorial scene on Youtube seems to have taken up the slack here. I think it may be a case where, given the sales outlook, maybe the ROI isn't there to start writing full-blown manuals. Maybe a “quick start guide” until the tuts start showing up on YT. And I’m not sure we should hassle the devs about this until the app store business model is more favourable towards them.
    We’ve already lost future development on a couple of crucial apps. I went all-in and spent a small fortune when I discovered a couple of months ago just how good the apps had become over the past 5-6 years or so - only to discover the best devs are so frustrated they’re walking away.

    To me the only “non-negotiable” should be AUv3 and maybe MIDI learn features right in the app for us plebs who might prefer to work in DAWs other than AUM.

    At the risk of sounding like a simp I think we should be asking the devs what they need from us, given the limitations of the app store, to keep them motivated. Theres probably no good answer.
    We’re all in the same boat I guess…

    Documentation as an IAP?

  • Universal and proper AU scaling are so important to me.

  • It would be interesting to list apps that fail in this regard but are frequently used.

    For me it would be in the category of MIDI generator apps. For example:

    • Piano Motifs
    • Suggester
    • Stravinski

    There's a category of developer that creates products using Apple's Swift language. They focus on user interface and MIDI output. I'm not sure Swift supports a lot of these capabilities and Objective C or C++ is required. That's a big jump in programming skill to make and integrate but a programer could speak to these requests from experience. Sometimes @NeonSilicon weighs in with his experience.

    I get your point @MobileMusic but I suspect the economics of app development will always be at odds with achieving profitable apps that comply. Not enough Return to justify the Investment. It's never a bad idea to ask.

    I'm always impressed with the solo developer that creates an IOS masterpiece and keeps it maintained. Harry Gohs of @Virsyn was pushing out multiple updates of AudioLayer while working on Tera Pro in parallel. He gets a lot of pushback about documentation but has written here that it's had to justify the effort in a financial sense.

  • @MadGav said:

    @BirbHope said:

    @MobileMusicPro said:

    @robosardine said:

    @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

    Yes it appears not enough apps have thorough manuals that's certainly a must.

    The tutorial scene on Youtube seems to have taken up the slack here. I think it may be a case where, given the sales outlook, maybe the ROI isn't there to start writing full-blown manuals. Maybe a “quick start guide” until the tuts start showing up on YT. And I’m not sure we should hassle the devs about this until the app store business model is more favourable towards them.
    We’ve already lost future development on a couple of crucial apps. I went all-in and spent a small fortune when I discovered a couple of months ago just how good the apps had become over the past 5-6 years or so - only to discover the best devs are so frustrated they’re walking away.

    To me the only “non-negotiable” should be AUv3 and maybe MIDI learn features right in the app for us plebs who might prefer to work in DAWs other than AUM.

    At the risk of sounding like a simp I think we should be asking the devs what they need from us, given the limitations of the app store, to keep them motivated. Theres probably no good answer.
    We’re all in the same boat I guess…

    Documentation as an IAP?

    Could work. :-)
    I can just see the whiny app store reviews though…

  • @BirbHope said:

    @MadGav said:

    @BirbHope said:

    @MobileMusicPro said:

    @robosardine said:

    @ehehehe said:
    Good sound, interface and stability with announced features available is all i expect. I do read manuals so not a common problem, except for stability sometimes.

    Talking about manuals - I would expect one of them instead of just the ‘tap for help’ buttons - or as is often the case nothing at all.
    I also expect some sort of demo prior to purchase in order that I can hear what the app sounds like instead of just buying on the description alone.

    Yes it appears not enough apps have thorough manuals that's certainly a must.

    The tutorial scene on Youtube seems to have taken up the slack here. I think it may be a case where, given the sales outlook, maybe the ROI isn't there to start writing full-blown manuals. Maybe a “quick start guide” until the tuts start showing up on YT. And I’m not sure we should hassle the devs about this until the app store business model is more favourable towards them.
    We’ve already lost future development on a couple of crucial apps. I went all-in and spent a small fortune when I discovered a couple of months ago just how good the apps had become over the past 5-6 years or so - only to discover the best devs are so frustrated they’re walking away.

    To me the only “non-negotiable” should be AUv3 and maybe MIDI learn features right in the app for us plebs who might prefer to work in DAWs other than AUM.

    At the risk of sounding like a simp I think we should be asking the devs what they need from us, given the limitations of the app store, to keep them motivated. Theres probably no good answer.
    We’re all in the same boat I guess…

    Documentation as an IAP?

    Could work. :-)
    I can just see the whiny app store reviews though…

    No one reads the manuals. Why would they pay extra for them? Seriously. Most of the (unavoidable) one star reviews of my apps come in the form "it's just a manually, useless ripoff." Well if they read the first paragraph of the manual, they would see it's a plugin and they need a host. But, "it's just a manual", so they aren't going to read it.

    I understand this to a degree. People want their apps to be discoverable in the app. This isn't always going to work though, especially in iOS with touch control settings where gestures are used.

  • @McD said:
    [...]

    There's a category of developer that creates products using Apple's Swift language. They focus on user interface and MIDI output. I'm not sure Swift supports a lot of these capabilities and Objective C or C++ is required. That's a big jump in programming skill to make and integrate but a programer could speak to these requests from experience. Sometimes @NeonSilicon weighs in with his experience.

    There's some MIDI stuff that's perfectly fine from Swift. There's some other applications that definitely need at the least a C layer. MIDI AUv3 plugins have the same restrictions as audio plugins. The MIDI is output through the callback/block in the audio processing and must be RT safe, so no Swift allowed.

  • My general thoughts on the points:

    The only way for a developer to avoid 1-star reviews and ratings is to not release an app (see my reply above about the 1-stars I get because the app is just a manual).

    I don't understand what you mean by AUM or DAW support. A plugin can only follow the spec. To kinda make a point, I don't know of any host that supports asking the plugin for the UI sizes (the supportedViewConfigurations and selectViewConfiguration calls on the AU interface).

    Presets belong mainly in the host. AUv3 has a nice spec for the interaction between the host and the plugin. Last I checked, only AUM supports this. There are some plugins that have a complex enough preset setup that they need a preset browser. But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    This last one is going to be contentious I'm sure, but I get asked about it fairly regularly. EQ's should not have spectrum analyzers builtin. You need to learn to hear your EQ. The visualizer is flat out lying to you. The frequency resolution is too low. Seeing a peak does not mean you hear a peak and the converse. Most of the time the thing you are looking for that is sticking out in a mix is going to be 6 or 12 dB down on the edge of a peak. (It could actually be all the way down in a valley if the freq. resolution is low enough.)

    As an experiment, take white noise signal run it through an EQ with a good Q control on a peaking filter. (Logic's builtin EQ is good for this.) Now lift it about 1dB and sweep it slowly. What do you see and what do you hear? Play with this at different Q settings. Your ears are better than your eyes. If you train them a bit, your ears will be better than your eyes in a mix for sure. That white noise signal is about the best case for your eyes and the worst case for your ears.

    This YT channel https://www.youtube.com/c/TheHouseofKushTV/videos has several vids where he talks about hearing your moves and learning to hear what EQ you need to play with before you reach for the knob. It's a great channel in general too.

    If you are going to use a spectrum visualizer, it should be on the output of the channel or even better, on the final mix. Every effect you have after the EQ is going to change where the frequency peaks are going to be. The mix is going to make much of what you think you are looking for in the EQ spot way up the chain completely different. If you are going to use a visualizer, the place for it is not in the EQ.

  • Besides AU, Multiout, good ui, clean preset browser

    All parameters exposed for cc
    Light (as possible) on cpu
    Midi in/out
    Random button is always fun
    Decent amount of presets
    Depending on the app - export - both audio and midi
    State saving of parameters
    Preset saving, as well as import and export for sharing
    Manual or video tutorials

  • edited May 14

    @NeonSilicon said:

    But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    In terms of mapping external controllers, Cubasis for one only allows for mapping their own components. To map an AUv3 it needs to have MIDI Learn built in. Like with Zeeon for example. If your Plugin doesn't have MIDI learn built in, no mapping in Cubasis.
    Also, with NS2, they have a macro setup where you can map about 8 controls to a kind of shell with 8 knobs and 2 xy pads. Not a bad solution really. Its something anyway.
    It seems only AUM and probably Apematrix have the functionality to map pretty much anything.

  • @BirbHope said:

    @NeonSilicon said:

    But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    In terms of mapping external controllers, Cubasis for one only allows for mapping their own components. If your Plugin doesn't have MIDI learn built in, no mapping.
    Also, with NS2, they have a macro setup where you can map about 8 controls to a kind of shell with 8 knobs and 2 xy pads.
    It seems only AUM and probably Apematrix have the functionality to map pretty much anything.

    Yes, and that's a problem with the DAWes not the plugins. The AUv3 API supports detailed exposure of parameters to the host. MIDI mapping to the parameters in a plugin is more limited. If a host enables OSC or some MIDI 2.0 features, the mapping to the plugins would come for free to every plugin that exposes its parameters correctly.

    I understand that some hosts don't do this well, but in terms of who to put pressure on to get the best outcome it should be on the host developers. If an AU doesn't support mapping their parameters correctly, then they should get the emails.

  • I really dislike the feature where the app plays 4/4 only, or is otherwise extremely inflexible. It’s nice to have 3/4 and 6/8 in addition, but why do almost all the apps have almost no options. I don’t need anything overly complex. Just 9/8 or maybe 7/8 or 7/4, etc. Many just cannot do such a thing. Change time signature mid song? I’m sorry most can’t do any such thing.

  • I won’t even consider buying synths (samplers, etc) that don’t have AUv3 support at this point.

  • edited May 15

    Recently I have opened a bunch of older projects in Auria Pro and Cubasis 2 and 3. Spanning about the last two years.

    Hardly a single project did not have auv3 problèmes.

    • Au not found. But it is still installed.
    • Au instruments not loading sounds (Beathawk)
    • Au effect settings completely gone. (Toneboosters Eq and comp. Auria )

    I would not expect after such a short time to have most of my projects with problems.

    I would expect not too happen.

  • The only things that will keep me from buying a new app is lack of AUV3 support and instability. Everything else is entirely dependent on what kind of app it is and what it’s supposed to be doing.

  • edited May 15

    @NeonSilicon said:

    @BirbHope said:

    @NeonSilicon said:

    But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    In terms of mapping external controllers, Cubasis for one only allows for mapping their own components. If your Plugin doesn't have MIDI learn built in, no mapping.
    Also, with NS2, they have a macro setup where you can map about 8 controls to a kind of shell with 8 knobs and 2 xy pads.
    It seems only AUM and probably Apematrix have the functionality to map pretty much anything.

    Yes, and that's a problem with the DAWes not the plugins. The AUv3 API supports detailed exposure of parameters to the host. MIDI mapping to the parameters in a plugin is more limited. If a host enables OSC or some MIDI 2.0 features, the mapping to the plugins would come for free to every plugin that exposes its parameters correctly.

    I understand that some hosts don't do this well, but in terms of who to put pressure on to get the best outcome it should be on the host developers. If an AU doesn't support mapping their parameters correctly, then they should get the emails.

    I’m sure you’re right. Sadly, in our discussions, Steinberg has said flat out they don’t support it and if its something I want I should request MIDI learn from the plugin devs. So right or wrong, if, on such an issue, its a standoff between the plugin devs and DAW company, I will be forced to work in AUM or chose plugins with MIDI learn if I just want to get work done in the interim. Enough plugins have it.

  • @BirbHope said:

    @NeonSilicon said:

    @BirbHope said:

    @NeonSilicon said:

    But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    In terms of mapping external controllers, Cubasis for one only allows for mapping their own components. If your Plugin doesn't have MIDI learn built in, no mapping.
    Also, with NS2, they have a macro setup where you can map about 8 controls to a kind of shell with 8 knobs and 2 xy pads.
    It seems only AUM and probably Apematrix have the functionality to map pretty much anything.

    Yes, and that's a problem with the DAWes not the plugins. The AUv3 API supports detailed exposure of parameters to the host. MIDI mapping to the parameters in a plugin is more limited. If a host enables OSC or some MIDI 2.0 features, the mapping to the plugins would come for free to every plugin that exposes its parameters correctly.

    I understand that some hosts don't do this well, but in terms of who to put pressure on to get the best outcome it should be on the host developers. If an AU doesn't support mapping their parameters correctly, then they should get the emails.

    I’m sure you’re right. Sadly, in our discussions, Steinberg has said flat out they don’t support it and if its something I want I should request MIDI learn from the plugin devs. So right or wrong, if, on such an issue, its a standoff between the plugin devs and DAW company, I will be forced to work in AUM or chose plugins with MIDI learn if I just want to get work done in the interim. Enough plugins have it.

    I don't use Cubasis, so I don't know their workflow really. They don't have any method to map MIDI controllers to plugin parameters? Do they have plugin parameter automation? I ask because that's basically the same kind of thing. Expecting every plugin to implement parameter automation is kinda silly because you want this at the level of the project.

    Practically, it's going to be really difficult to get every plugin to implement MIDI mapping when most don't do any MIDI processing at all.

    It sucks that Steinberg doesn't want to implement this. I'd still keep bugging them about it. It wouldn't hurt to ask for the feature from the plugins that you really want it from. But, it's going to be a lot more work for all of the devs out there to start processing MIDI in their plugins than it would be for Steinberg to add the feature once.

  • edited May 15

    @NeonSilicon said:

    @BirbHope said:

    @NeonSilicon said:

    @BirbHope said:

    @NeonSilicon said:

    But, for the most part, your plugin should be able to do everything through a host UI with the plugin UI closed. This enables mapping external controllers and hosts like MainStage.

    In terms of mapping external controllers, Cubasis for one only allows for mapping their own components. If your Plugin doesn't have MIDI learn built in, no mapping.
    Also, with NS2, they have a macro setup where you can map about 8 controls to a kind of shell with 8 knobs and 2 xy pads.
    It seems only AUM and probably Apematrix have the functionality to map pretty much anything.

    Yes, and that's a problem with the DAWes not the plugins. The AUv3 API supports detailed exposure of parameters to the host. MIDI mapping to the parameters in a plugin is more limited. If a host enables OSC or some MIDI 2.0 features, the mapping to the plugins would come for free to every plugin that exposes its parameters correctly.

    I understand that some hosts don't do this well, but in terms of who to put pressure on to get the best outcome it should be on the host developers. If an AU doesn't support mapping their parameters correctly, then they should get the emails.

    I’m sure you’re right. Sadly, in our discussions, Steinberg has said flat out they don’t support it and if its something I want I should request MIDI learn from the plugin devs. So right or wrong, if, on such an issue, its a standoff between the plugin devs and DAW company, I will be forced to work in AUM or chose plugins with MIDI learn if I just want to get work done in the interim. Enough plugins have it.

    I don't use Cubasis, so I don't know their workflow really. They don't have any method to map MIDI controllers to plugin parameters? Do they have plugin parameter automation? I ask because that's basically the same kind of thing. Expecting every plugin to implement parameter automation is kinda silly because you want this at the level of the project.

    Practically, it's going to be really difficult to get every plugin to implement MIDI mapping when most don't do any MIDI processing at all.

    It sucks that Steinberg doesn't want to implement this. I'd still keep bugging them about it. It wouldn't hurt to ask for the feature from the plugins that you really want it from. But, it's going to be a lot more work for all of the devs out there to start processing MIDI in their plugins than it would be for Steinberg to add the feature once.

    If you twiddle a knob on a plugin using the touchscreen during recording it will record it. Then you can go back and edit it. Or, obviously, if the plugin has MIDI learn it will record it. But otherwise, nope.
    This alone has made me seriously consider doing everything in either NS2 or AUM (but I’m a little discouraged about investing a lot of energy into NS2 since the dev has basically walked away from the app). Maybe BM3 for some stuff. I havent been at this iOS music for more than a couple of months. I might eventually warm up to adding a bunch of 4Pockets apps to get timelines and midi automation and audio recording in AUM (although NS2 has no audio recording either, but I dont do too much of that). In fact it seems inevitable.

  • Really blown away by the discussion here! Can't wait to write a blog post based on all this feedback.

Sign In or Register to comment.