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.

Swift for Android!?!?

I was reading Brambos’s excellent essay and found this linked at the bottom of the site:

https://blog.readdle.com/why-we-use-swift-for-android-db449feeacaf

This is some crazy exciting news for me. I always have a low-level dread running through me for the day when this great iOS music scene/experiment dies and is no more. My predictions usually revolve around Apple being responsible for the demise of iOS music, and all of these amazing apps will stop being created and evolving. This article brings me hope that we may never have to see the day when Apple kills all of our fun. Also, this could mean an additional revenue stream for the developers. I know many developers stay far away from Android, but if the money is calling you you may want to take another look. This Swift development seems like it could save a lot of the pain of going cross-platform.

(Apple’s next move will be to change Swift to put the kibosh on this cross-platform nonsense, for sure.) :D

Comments

  • edited June 2018

    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

  • @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

  • I thought swift isn´t the best for audio anyway?

  • edited June 2018

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

  • @Cib said:
    I thought swift isn´t the best for audio anyway?

    I have no idea really. I am pretty sure AudioKit uses it, and that is what has me somewhat excited about this news. I will wait for more developments, it seems at least a year away still.

  • @realdawei said:

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

    Latency hasn’t been an issue for me for many years now. That shit is a myth.
    And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    I wouldn’t expect you to be supportive of anything other than Apple anyway. :D

  • @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

    Latency hasn’t been an issue for me for many years now. That shit is a myth.
    And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    I wouldn’t expect you to be supportive of anything other than Apple anyway.

    How Cool that people have expectations of me :D

  • @Cib said:
    I thought swift isn´t the best for audio anyway?

    Not yet. Hopefully next year

  • @realdawei said:

    @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

    Latency hasn’t been an issue for me for many years now. That shit is a myth.
    And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    I wouldn’t expect you to be supportive of anything other than Apple anyway.

    How Cool that people have expectations of me :D

    I always expect you to champion Apple and promote GarageBand, based on your previous posts. ‘Tis all. :D

  • edited June 2018

    @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

    Latency hasn’t been an issue for me for many years now. That shit is a myth.
    And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    I wouldn’t expect you to be supportive of anything other than Apple anyway.

    How Cool that people have expectations of me :D

    I always expect you to champion Apple and promote GarageBand, based on your previous posts. ‘Tis all. :D

    In this context yes. I’m tryna make music the way it flows for me. GB is the closest to the vision of how I want to work. Cubasis almost there has more power. but MIDI resolution keeps me at bay. If they fix that I’m all in. BM3 crazy powerful but that GUI workflow is offensive. Auria Pro, no.

    Apple? Well what’s the alternative for mobile? I was a Windows/SONAR snob for 15 years and all I got was this lousy t-shirt.

  • @realdawei said:

    @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:

    @CracklePot said:

    @realdawei said:
    Developers have always had a strong cross platform option by using Juce. https://juce.com

    Swift is not needed for this.

    Ok. The people taking the time to develop this seem to think otherwise.

    Many if not most devs of the Apps we use are already using Juce: Audio Damage, Klevgrand, Korg etc

    The issue with Android right now is audio latency (but Google is fixing this) and an even higher aversion to people actually wanting to pay for apps.

    Also Android tablet form factor never took off — failed it’s primarily phones. To the point now that Google removed the tablet section from the Android website and now seem to begin pushing ChromeOS for tablets.

    That said I’m a huge fan of Swift and have been experimenting with it on Linux servers.

    Latency hasn’t been an issue for me for many years now. That shit is a myth.
    And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    I wouldn’t expect you to be supportive of anything other than Apple anyway.

    How Cool that people have expectations of me :D

    I always expect you to champion Apple and promote GarageBand, based on your previous posts. ‘Tis all. :D

    In this context yes. I’m tryna make music the way it flows for me. GB is the closest to the vision of how I want to work. Cubasis almost there has more power. but MIDI resolution keeps me at bay. If they fix that I’m all in. BM3 crazy powerful but that GUI workflow is offensive. Auria Pro, no.

    Apple? Well what’s the alternative for mobile? I was a Windows/SONAR snob for 15 years and all I got was this lousy t-shirt.

    I have to admit...
    iPad is the only game in town for mobile, for me.
    I just hope that isn’t the case for too much longer.
    Otherwise we all may end up with just another lousy t-shirt.
    Peace. B) <3

  • And they are integrating Android and Chome OS, so the tablet fail isn’t a big deal since there are Chomebooks already taking over that niche market.

    >

    I find this very interesting and have been tempted to pick up a Chromebook to try out G-Stomper Studio as it looks interesting, however I’ve found little info online to recommend one with a view to music creation and with the wide choice available I’ve been unable to narrow it down to a couple of ideal candidates.

  • @CracklePot said:

    @Cib said:
    I thought swift isn´t the best for audio anyway?

    I have no idea really. I am pretty sure AudioKit uses it, and that is what has me somewhat excited about this news. I will wait for more developments, it seems at least a year away still.

    You mean @analog_matt?

    They use C++ and left Swift, IIRC!

  • I am interested to start programming for mobile.
    But I would like to be able to produce cross-platform.
    And also, I would like to use a high performance language.

    So, C++ is the way to go?

    That juce website does not state, which language is used.

  • C++ is the safest bet for anything. You can make it as low-level as you want and it typically compiles on anything from phones to supercomputers to toasters.

  • edited June 2018

    All real-time audio processing has to be done in C or C++ to prevent locks on the audio thread that can cause glitches. Swift is not (currently) suitable for this. It is used in Audiokit but the core processing is done in C++. JUCE is a library built with on for use with C++. It is cross platform as it uses OpenGL, which Apple has now said is being deprecated :/

  • edited June 2018

    @Cib said:
    I thought swift isn´t the best for audio anyway?
    I am pretty sure AudioKit uses it

    Swift is great for experimenting and learning audio programming. Many pro-level audio apps use Swift for the app UI and C/C++ for the engine. LayR, AudioKit Synth One, etc are built like that.

    FM Player uses Swift all the way through. On, the downside, it doesn't run well on early iPads. And, doesn't allow for AUv3 or accurate real-time audio sequencing that is "pro" level. On, the positive side, the code is easy to understand and it was quick to develop.

  • @Mark B said:
    All real-time audio processing has to be done in C or C++ to prevent locks on the audio thread that can cause glitches. Swift is not (currently) suitable for this. It is used in Audiokit but the core processing is done in C++. JUCE is a library built with on for use with C++. It is cross platform as it uses OpenGL, which Apple has now said is being deprecated :/

    OMFG.

    Apple continues to not only disappoint me.
    I spare you my concrete thoughts.

  • @analog_matt said:

    @Cib said:
    I thought swift isn´t the best for audio anyway?
    I am pretty sure AudioKit uses it

    Swift is great for experimenting and learning audio programming. Many pro-level audio apps use Swift for the app UI and C/C++ for the engine. AudioKit Synth One, LayR, etc are built like that.

    FM Player uses Swift all the way through. On, the downside, it doesn't run well on early iPads. And, doesn't allow for AUv3 or accurate real-time audio sequencing that is "pro" level. On, the positive side, the code is easy to understand and it was quick to develop.

    Ah, thanks.

    So, you are not using OpenGL and will not run into problems with Apple's new ideas. Right?
    That sounds good, one reason more to have a look at your code :smile: :smile: :smile:

  • @analog_matt said:

    @Cib said:
    I thought swift isn´t the best for audio anyway?
    I am pretty sure AudioKit uses it

    Swift is great for experimenting and learning audio programming. Many pro-level audio apps use Swift for the app UI and C/C++ for the engine. LayR, AudioKit Synth One, etc are built like that.

    FM Player uses Swift all the way through. On, the downside, it doesn't run well on early iPads. And, doesn't allow for AUv3 or accurate real-time audio sequencing that is "pro" level. On, the positive side, the code is easy to understand and it was quick to develop.

    So the new FM Player 2 is mostly C/C++ then? Is this one of the main reasons you made FM Player 2, to ditch the early experimental version and make it superior from the get-go with a fresh start?

  • @brambos said:
    C++ is the safest bet for anything. You can make it as low-level as you want and it typically compiles on anything from phones to supercomputers to toasters.

    This great bit of advice comes with mucho experience to back it up. Words to live, no doubt. B)

  • I gotta say if most these apps I use would go android I would gladly switch and never look back.. I got given a Samsung tablet years ago and found caustic the run quite well, with caustic 3.2 I noticed very little latency. I love androids file system way better then the way iOS does it, things are more open the way they would be on a computer, plus you can have a memory card slot with all your shit right there in your tablet....only reason I keep an iPad is for all these sweet music/synth/DAW apps..if you got an android tablet that was the same $$ as the iPad you are using now, you would have a beast...I miss using android, but I love these apps on iOS...

  • Sorry, Android is still far, far away from being a viable platform for audio apps. And that's just the technical limitation, not even touching on the fact that Android users are extremely reluctant to paying for apps. :#

    Source: http://www.synthtopia.com/content/2018/02/17/10-years-later-android-audio-quality-still-lags/

  • My god, only the Pixel 2 comes close to the Apple HW in this chart.
    Maybe Google is just as closed door as Apple after all. Only they know how to leverage the full power of their OS, it seems. :D

  • I use an android phone, s7 edge.
    Love it
    Love having a memory card, easy file system, great screen , fast charging wireless for last 2 years etc
    But
    2 iPads as nothing comes close to iOS music apps .
    So I think I will always use android as a phone, and iPads for music,
    I am happy with this, and don't really see android anytime soon for music production.
    That's life I guess

  • edited June 2018

    @brambos said:
    Sorry, Android is still far, far away from being a viable platform for audio apps. And that's just the technical limitation, not even touching on the fact that Android users are extremely reluctant to paying for apps. :#

    Source: http://www.synthtopia.com/content/2018/02/17/10-years-later-android-audio-quality-still-lags/

    Yup and now we have the A11 Bionic chip that’s yet to make it to iPad. my 2017 iPad Pro is keeping up well with all the real time AUv3’s I personally want to throw at it — still with low latency. I can imagine this years iPad Pro could create even more head room

  • edited June 2018

    @CracklePot said:

    @analog_matt said:

    @Cib said:
    I thought swift isn´t the best for audio anyway?
    I am pretty sure AudioKit uses it

    So the new FM Player 2 is mostly C/C++ then? Is this one of the main reasons you made FM Player 2, to ditch the early experimental version and make it superior from the get-go with a fresh start?

    Good question. FM Player 2 isn't a re-write as much as a free upgrade to FM Player with a lot more features (dual layers, keyboard splits, sweet chorus, more effects, more sounds). It's still written Swift. It won't be AUv3. And, will continue to be a live music tool. Sorry to disappoint anyone expecting it to be AUv3 next month. On, the positive side, it really shows how much one can do with Swift.

Sign In or Register to comment.