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.

2020 iPad Air Review ๐Ÿคฏ| From a music producers perspective! ๐ŸŽน

24

Comments

  • 'it's like body-shaming in the computer world', nice, really enjoying your commentary ๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ‘๐Ÿ‘๐Ÿ‘

  • @Samu said:
    As long as BT Latency is as sucky as it is for anything even remotely close to real-time I will miss the 3.5mm jack since I can't charge and listen at the same time without getting into dongle hell. Thankfully the iPad 8 is still there as an option...

    Is it likely that bt latency will ever be good enough?

  • wimwim
    edited September 2020

    @Gavinski said:

    @Samu said:
    As long as BT Latency is as sucky as it is for anything even remotely close to real-time I will miss the 3.5mm jack since I can't charge and listen at the same time without getting into dongle hell. Thankfully the iPad 8 is still there as an option...

    Is it likely that bt latency will ever be good enough?

    No.

    Nothing official, it this is one of the better explanations Iโ€™ve seen:
    https://electronics.stackexchange.com/questions/354458/why-bluetooth-audio-works-at-so-high-latency

  • @wim said:

    @Gavinski said:

    @Samu said:
    As long as BT Latency is as sucky as it is for anything even remotely close to real-time I will miss the 3.5mm jack since I can't charge and listen at the same time without getting into dongle hell. Thankfully the iPad 8 is still there as an option...

    Is it likely that bt latency will ever be good enough?

    No.

    That's what I thought ๐Ÿ˜‰

  • edited September 2020

    @ipadbeatmaking
    So would you go for this one or wait on the next Pro?

    Definitely going for this one - 12.9" is too big for me and 11" doesn't have any advantages for me compared to new Air, plus it has disadvantage it starts on 128 gigs which is wasting for me, i can't fill even 64 gigs on my mini :))

  • edited September 2020

    @Gavinski said:

    @Samu said:
    As long as BT Latency is as sucky as it is for anything even remotely close to real-time I will miss the 3.5mm jack since I can't charge and listen at the same time without getting into dongle hell. Thankfully the iPad 8 is still there as an option...

    Is it likely that bt latency will ever be good enough?

    not with current BT standards, it's technically impossible to go significantly bellow 50ms with audio stream ...

    i don't see usb/lightning to jack dongle as issue at all ... i have lightning to jack dongle almost permanently attached to my headphones because of iPhone 7 and i started to use it also with min 2019 mini, even through it has also jack..

  • I personally love a bigger screen. I was playing with my older 2016 10.5 ipad Pro last night and I really missed the size of the 12.9 2018 ipad Pro. I had to scroll in Yukawa, for example, super sucky experience.

  • @dendy said:

    @Gavinski said:

    @Samu said:
    As long as BT Latency is as sucky as it is for anything even remotely close to real-time I will miss the 3.5mm jack since I can't charge and listen at the same time without getting into dongle hell. Thankfully the iPad 8 is still there as an option...

    Is it likely that bt latency will ever be good enough?

    not with current BT standards, it's technically impossible to go significatnly bellow 50ms with audio stream ...

    honestly i really don't understand how the usb-c to jack dongle is problem for somebody - i have lightnig to jack dongle permanently attached to my headpohones because of iPhone 7 and i started to use it also with min 2019 mini, even through it has also jack.. i almost forgot it is dongle, it started to be integral part of my headphones cable :lol:

    It's a problem for people who use different devices. I have two ipads, one needs a dongle and the other doesn't. To make matters worse, I have an android phone that is also USB C but which requires a different dongle from my USB C ipad. Sometimes I leave the house with the wrong dongle and it's a serious f*ing pain in the arse. PLUS, it's a problem for people who want to charge while using. The lack of 3.5mm headphone jack is something that annoys the shit out of me on a regular basis. Not to mention that Bluetooth is a battery drain, even the newer version of Bluetooth.

  • @wim said:
    Imma hold off on getting excited until it's clear they didn't muff it with the audio stuff like they did when they introduced the Pros. That was a nightmare ... and I didn't even own one. :D

    Excellent video btw @ipadbeatmaking.

    god yeah, I remember... it was months after my first pro before stuff started working properly

  • One solution to the 48k issue is to get something like a Dragonfly Black, which gives you a headphone out and also lets you control the sample rate.

    The Apple headphone dongle locks the sample rate to 48k.

  • >

    So you would pick an iPad 8 over the new air due to the lack of headphone jack/dongles etc? Is the new 8 better than the performance of the new air?

    It's more all about practicality than performance. Sometimes I need to charge the iPad while it's hooked to a PA and the less dongles to worry about the better.

    We don't even have a proper USB-C Audio Interface that provides PD pass thru to keep the iPad charged while using the audio interface, no we need to get into dongle hell to get there...

    Just because Apple had the 'courage' to remove the 3.5mm jack doesn't mean it's worthless or redundant...
    ...It's just Apple being Apple. I would not be surprised if they use the UWB chip to transmit low latency audio to their new 'AirPods Studio' but that remains to be seen and that would require everyone to get new hardware too that has the UWB chip.

    Time will tell where things go, USB-C is fine but not at the expense of removing other stuff.
    Apple could do it if they wanted but I guess they just don't want to...

    It was 'super lame' to see the DJ Pro dude at the keynote 'Playing DJ' with no cables hooked to the PA, not even power to the speakers LOL.(And nope, those were not 'battery power speakers just there to decorate the scene).

    Apple tries so hard to be 'Hip' but I ain't falling zombie blue-eyed for their sh*t anymore...

    Cheers!

  • edited September 2020

    To anyone considering to buy a usbC iPad, stay away (for now) if you only use apogee one or duet.
    Apple hasnโ€™t released drivers to make them work since 2018.

  • I'm reading this thread from the post office, where I'm picking up a 2020 ipad pro 11' I just bought used. Should I hate myself, the world an apple?. Is my iPad pro better in any way than the new air?. I can't see it is, and I can't see who'd buy the 2020 pro (256gb or under) for a higher price. Will the pro price drop?.
    Aghgghggh.
    BTW I got a big "I told you" from my wife. Like she knew this was coming ๐Ÿ™„. From what rumors I read this was supposed to be out in March.

  • @Paa89 said:
    To anyone considering to buy a usbC iPad, stay away (for now) if you only use apogee one or duet.
    Apple hasnโ€™t released drivers to make them work since 2018.

    Its that a general problem with other usb audio cards or only a specific Apogee thing?

  • edited September 2020

    @jassy said:

    @Paa89 said:
    To anyone considering to buy a usbC iPad, stay away (for now) if you only use apogee one or duet.
    Apple hasnโ€™t released drivers to make them work since 2018.

    Its that a general problem with other usb audio cards or only a specific Apogee thing?

    all iPads (lightning/usb) are compatible with all sound cards which are fully USB class compliant, which is public standard. To me it looks like this Apogee is probably not corretly implementing USB Class compliance. Becassue there are no actually card-speciffic drivers, if card is USB Class compliant. My bets are this is something which needs to be fixed on apogee's side ...

    edit: quickly checked Duet's manual and USB Class compliance is mentioned just in realtion with MIDI. So probably there is issue, maybe compliance is not fully implemented, just for MIDI not for audio

  • If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances? But multithreaded apps would be additionally great for complex plugins which could then run different processes over different threads also.

    @wim said:
    Only after developers modify their apps to take advantage of it. It's not trivial and not even all that beneficial for all types of apps. Don't hold your breath for anything dramatic any time soon.

  • edited September 2020

    @Carnbot
    If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

    In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

    Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

  • @dendy said:

    @Carnbot
    If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

    In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

    Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

    Ok I see, thanks :)

  • If an audio interface class compliment it will work on iOS.
    Apogee was always positioning their hardware to be used with Apple devices, so they offered some extra functionality. Apple's insistence to reinvent the wheel every 3-5 years always made a lot of hardware obsolete. All they can do is to move on and release the next gen. Patching these things is never profitable and many times impossible task.

  • I agree with @Samu , removing headphones jack is pain in the ass for music production, period. The beauty of iPad is that you lay in a couch with only headphones on a make music. Or bring it outside, sit below the tree and enjoy the inspiration from different environment...
    ... and then you find out you forgot the goddamn USB-C -> 3,5mm jack dongle!
    I switch between using headphones on computer (3,5mm jack) or DJ console (also 3,5mm jack) and iPad (currenlty 3,5mm jack, in the future, I'll probably need a dongle :disappointed: ), which makes it easier to forget about it. Putting it on and off is also annoying, the chance you forget it occasionally is pretty high. I even made a keychain from old earbuds jacks where I keep my lightning -> USB-C dongle because of iPhone to carry it always with me :smiley:
    Yes, I use Bluetooth speakers and BT headphones for regular music listening but these are not usable for music production or DJing.
    So for us, it's bad news. I could understand the argument for iPhones: it's a small device, space is precious asset, so anything non-essential can be stripped away. Also, it's not that great device for music production or gaming as iPad. But for iPad I can't understand it that much...

  • if this is the new air, cant wait to see whatโ€™s coming for the next ipad pro. in the meantime, I bought a doqo keyboard/hub that has closed the gap and made creating on ipad so much easier. the switch to USB-C was the smartest change apple made. just need the ipad to get up to 16GB ram next.

  • @Paa89 said:
    To anyone considering to buy an Apogee One or Duet, stay away (for now) if you only use an iPad Pro with USB-C.

    >

    Fixed that for you. ๐Ÿ™‚๐Ÿ‘

  • @dendy said:

    @Carnbot
    If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

    In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

    Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

    Dont know in IOS side, but in the pcs (mac and win) the Daw (hosts) is the responsible of distribute the plugins (their own or third party plugins) between cores/threads, maybe in IOS is different but the Carnbot question, front this point of view, makes perfect sense to me.

  • edited September 2020

    @jassy said:
    Dont know in IOS side, but in the pcs (mac and win) the Daw (hosts) is the responsible of distribute the plugins (their own or third party plugins) between cores/threads, maybe in IOS is different but the Carnbot question, front this point of view, makes perfect sense to me.

    Not sure how it works on desktop (especially on windows) but on iOS it works like i described .. I'm seriously in doubt even on desktop is much different.

    Of course - there is one small difference on MacOS compared to iOS - on iOS all plugins are running "off thread" which means theyir thread(s) are independent from host thread and they really can communicate with houst exclusively just using API provided by OS. This costs a little but of CPU but increases it stability and decreases chance that when plugin crashes, it takes down whole host (of course this can still happen but from different reasons)

    On MacOS there is posibility (it must be supported by HOST and allowed by plugin) to run plugin "in thread" - which means plugin UI thread is executed as part of host application thread .. This has a little bit better performance but also a bit bigger risk of plugin taking down whole host.

    I'm not completely sure how this work and if this related just to UI thread or also to audio (realtime safe) thread of plugin (maybe it does).

    Probably this is what you mean with "hosts being responsible of distribute plugins between cores" (which is not precisely true anyway, because app never can decide which physical core to use - app can just create some thread, and then it's on operating system to decide which core is processing which thread) -app can create even more threads than number of physical cores .. for audio there are of course strict rules what you are alloed to do on such thread, and what not, but this is topic on it's own .. What is important before iOS14 this was very complicated and risky business, starting iOS14 there is solid straigntforward API for creating multiple audio realtime safe threads .. which is very cool :)

  • edited September 2020

    @richardyot said:
    One solution to the 48k issue is to get something like a Dragonfly Black, which gives you a headphone out and also lets you control the sample rate.

    The Apple headphone dongle locks the sample rate to 48k.

    How exactly does the 48k problem effect things? Certain apps just sound out of tune because they think only in 44k and iOS isnt smart enough to just interpolate something something etc etc?

  • @AudioGus said:

    @richardyot said:
    One solution to the 48k issue is to get something like a Dragonfly Black, which gives you a headphone out and also lets you control the sample rate.

    The Apple headphone dongle locks the sample rate to 48k.

    How exactly does the 48k problem effect things? Certain apps just sound out of tune because they think only in 44k and iOS isnt smart enough to just interpolate something something etc etc?

    Yeah some apps are out of tune, but also you have absolutely no control over sample rates if you use the Apple headphone dongle, it's 48khz or nothing.

    With a Dragonfly (or similar) you are free to set whatever sample rate you like. I tend to stick to 44.1khz because you're far less likely to run into issues with instruments or samples being out of tune.

  • @jassy said:

    @Paa89 said:
    To anyone considering to buy a usbC iPad, stay away (for now) if you only use apogee one or duet.
    Apple hasnโ€™t released drivers to make them work since 2018.

    Its that a general problem with other usb audio cards or only a specific Apogee thing?

    Apogee uses the MFi protocol which is lightning only at the moment. I really donโ€™t see why they canโ€™t create firmware update that allows you to use it on usb-c iPad, but it would require a complete reworking of the devices software because youโ€™d need 48v, etc directly into the knob controls without maestro software.

    Most other interface devices didnโ€™t commit this hard to Apple exclusively, so this isnโ€™t a general issue. If itโ€™s class compliant, itโ€™s gonna work.

  • @dendy said:

    @Carnbot
    If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

    In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

    Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

    So is this a good thing? Does this mean each plugin does its own thing regardless of the host or other plugins.

    Not a 1:1 example: but is it Unlike MPE for instance where the host has to support it for it to be used even if the plugin supports it?

  • @0tolerance4silence said:
    If an audio interface class compliment it will work on iOS.
    Apogee was always positioning their hardware to be used with Apple devices, so they offered some extra functionality. Apple's insistence to reinvent the wheel every 3-5 years always made a lot of hardware obsolete. All they can do is to move on and release the next gen. Patching these things is never profitable and many times impossible task.

    Exactly.

Sign In or Register to comment.