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.

CLAP plugins on the iPad?

You probably have heard about CLAP, the ambitious new open source audio plugin format driven by U-He and Bitwig. If not, it’s currently on the news:

https://www.synthanatomy.com/2022/06/bitwig-and-u-he-clap-a-new-open-standard-for-audio-plugins-and-hosts-now-in-beta.html

At Superbooth I discussed the matter with the Bitwig guys and they are very determined. The format is definitely superior. Multi-core support, non-destructive modulation, Midi 2.0 and last but not least vendor independent. Of course it won‘t be easy, if not impossible, to convince the owners of the current formats to integrate CLAP into their DAWs - that includes Apple.

Being usually all AUv3 on the iPad it feels a bit like „splendid isolation“ and DAWs often not supporting AUv3. So what do you think? Will we see CLAP on the iPad at some point in time? Will developers embrace it? Is there any reason CLAP plugins would be banned from the AppStore?

CLAP on the iPad
  1. Will we see CLAP on the iPad55 votes
    1. Never ever
      18.18%
    2. Apple wouldn’t allow them on the AppStore
      21.82%
    3. Only if Bitwig and U-he land on the iPad
      25.45%
    4. Maybe if they succeed on the desktop
      27.27%
    5. For sure
        7.27%
«13

Comments

  • Didn’t I read that multitrack studio is supporting it on its desktop version? That’d be the obvious first place to look, but I have a feeling that App Store nonsense may make distribution of the plugins themselves (at least outside of walled IAP shops) a nonstarter.

    Excited to see where this goes, nonetheless.

  • Would absolutely make no sense on iOS/iPadOS if there's no host with native support for them!

    So yeah, bring on BitWig for iPad or something but even then I feel they would keep the 'CLAP Store' inside the App just like what Roland does with ZenBeats...

    I won't CLAP for this one as I feel it's going to fail miserably...
    ...but we'll see in 4-5 years or so.

    As long as the iPadOS can't run native macOS apps I feel the 'big boys' will just ignore the platform.

    macOS Touch would be the next logical step but I don't think Apple will ever do that...

  • Unless you can offer CLAP plugins as isolated containers, distributing them on the iOS App Store won't happen.

    But regarding desktop, I'm cautiously optimistic that can replace VST as the standard. It's even possible to develop your plugins in CLAP, and then create VST containers.

    Also, Urs from U-he is incredibly confident about Avid adopting CLAP:

    There is even speculation about Avid ditching AVX, embracing CLAP as the new default standard for Pro Tools.

    They have been struggling to port the AVX framwork to Apple Silicon Macs. Due to how old the code is, it's an immense task.

    They can have the opportunity or getting a new format with a minimal investment in development, and thanks to its MIT license, they are still free of including their privative modifications.

    To put this on context, Pro Tools doesn't support VST.

    Honestly, if Pro Tools embraces CLAP, you can say hello to a new industry standard.

  • By the way, @krassmann . When you talked with the Bitwig team, do you asked them for AUv3 support? Interested in knowing their answer.

    I have already wrote an email to Bitwig, saying them why AUv3 support, contrary to Audio Units in the past, it's an important feature. And how they are losing a lot of competitiveness with Ableton due to this.

    Desktop plugins are in a 99% of the cases offered with VST3 versions on Mac, so having Audio Units support wasn't as important, and there are Audio Units wrappers such as Bluecat's Patchwork.

    But AUv3 support open the possibility of using tens of exclusive iOS synths and effects on Bitwig, that can run on MacOS and aren't available on desktop.

    For people heavily invested on the iOS ecosystem, it can be a defining feature to choose Ableton instead. I myself I'm thinking in getting an Ableton Live Suite license due to the AUv3 support.

    Also it will be great if more people writes to Bitwig support, requesting AUv3 support. They tend to listen to user request features. And at least in the answer to my email, they haven't said "No", like other times in which people requested Audio Unit support.

  • @Samu said:
    Would absolutely make no sense on iOS/iPadOS if there's no host with native support for them!

    So yeah, bring on BitWig for iPad or something but even then I feel they would keep the 'CLAP Store' inside the App just like what Roland does with ZenBeats...

    I won't CLAP for this one as I feel it's going to fail miserably...
    ...but we'll see in 4-5 years or so.

    As long as the iPadOS can't run native macOS apps I feel the 'big boys' will just ignore the platform.

    macOS Touch would be the next logical step but I don't think Apple will ever do that...

    Do boys get bigger than ImageLine and Steinberg?

  • @Pynchon said:
    By the way, @krassmann . When you talked with the Bitwig team, do you asked them for AUv3 support? Interested in knowing their answer.

    Yes, I did and I also asked about any plans for an iPadOS release. To both questions I earned a rather cheesy smile that actually said more than the actual words in the answer. The bottom line is that the dev team is rather small what I think directly correlates with Bitwig‘s market share. According to research in their user base windows is dominant. The representative who was more of a product owner or sales person does not believe in it.

    They rather want to push CLAP and invest the resources into features. Although I think Bitwig’s plugin sandboxing makes it the best plugin host on the planet.

    I have already wrote an email to Bitwig, saying them why AUv3 support, contrary to Audio Units in the past, it's an important feature. And how they are losing a lot of competitiveness with Ableton due to this.

    Look how long it took Ableton to support AUv3 and they have a much bigger team and sales.

  • @BiancaNeve said:

    Do boys get bigger than ImageLine and Steinberg?

    Judging by their existing iOS efforts they are both still 'iOS Babies' :sunglasses:
    Until we have 'pro-level' Music apps on iPad the choice between a MacBook and iPadPro is easy.

    We do have some nice apps for the iPad but every single time I get back to my Mac with Logic I just get sad considering what the iPad could do if it just had...

    ...and Logic is not even close to perfect but it's 'Good Enough' for handle most task without too much frustration.

    The iPad is perfect as a 'sketchpad' and 'sound module' no doubts about that!

  • I've played with this a little and I like it. Seems simple, but powerful. Unfortunately I suspect VST3 isn't going anywhere because Steinberg are unlikely to support this. Though maybe the obvious performance advantages of this new format will force their hand.

  • edited June 16

    last year I asked Urs if it’s possible to implement it on iOS:

    response:

    I honestly have no idea if that makes sense. It's certainly possible in some way, but I think iOS has a very established AU ecosystem that is hard to beat.

    https://www.kvraudio.com/forum/viewtopic.php?t=574861&start=180

  • I voted "never," but that's not quite true. The issue for CLAP on iOS is that each plugin would have to be sandboxed and deliverable as an app extension. I've only started looking at the CLAP source, but it looks to me like it is based on a dynamically loaded/shared lib approach that runs the plugin in-process. That would have to be changed for an iOS version and you'd have to do this while getting around Apple's blocking of inter-process communication on iOS. So, my real vote is probably never, but a couple of changes in iOS and the App Store might make it possible.

  • edited June 16

    @krassmann said:

    @Pynchon said:
    By the way, @krassmann . When you talked with the Bitwig team, do you asked them for AUv3 support? Interested in knowing their answer.

    Yes, I did and I also asked about any plans for an iPadOS release. To both questions I earned a rather cheesy smile that actually said more than the actual words in the answer. The bottom line is that the dev team is rather small what I think directly correlates with Bitwig‘s market share. According to research in their user base windows is dominant. The representative who was more of a product owner or sales person does not believe in it.

    They rather want to push CLAP and invest the resources into features. Although I think Bitwig’s plugin sandboxing makes it the best plugin host on the planet.

    I have already wrote an email to Bitwig, saying them why AUv3 support, contrary to Audio Units in the past, it's an important feature. And how they are losing a lot of competitiveness with Ableton due to this.

    Look how long it took Ableton to support AUv3 and they have a much bigger team and sales.

    I think that the opinion about Mac has drastically changed over the last year for the Bitwig team.

    They were clever enough of releasing a native ARM version months before Ableton. So a lot of users at that time, doubting between Ableton and Bitwig, finally chose Bitwig.

    There was a second factor. Bitwig user base is heavily invested in modular workflows, so VCV Rack 2 is an essential tool. Currently, VCV Rack 2 Pro is only available as a VST. So Mac users using ARM processors can't run VCV Rack 2 Pro inside Ableton, without running the entire session under Rosetta.

    These two factors have expanded the Mac market share of Bitwig in the last months.

    And from there, for the first time, if you see the recent updates, the Bitwig team has showed a commitment for the platform, allocating resources for MacOS specific features.

    An example, finally they are using MacOS buttons in the window frames interface. They also added support for trackpad gestures. And now, in every new update, you see MacOS specific features.

    Not supporting Audio Units wasn't as much a question of a heavy load of work, but of commercial viability. The Mac user base back then was small, and at the end of the day, all the major plugin manufacturers release VST3 versions. They simply were demanding to its users to install an additional plugin format with each installer.

    They are a small team, but also the Cockos team is small, and they included AUv3 support before any other DAW. The workload is small in comparison to develop a new plugin format, or including ARM support. It's a matter of if it makes sense for the users. In the same moment in which a lot of plugins coming from iOS doesn't have VST3 versions, and only AUv3 versions, the story changes.

    And let's not forget that the attachment rate of Bitwig among iOS users is surprisingly high. Because the modular workflow in Bitwig fits well with the modular workflow used in applications such as AUM or Drambo.

    The Bitwig team is really good looking to attract small niche markets, to compete with Ableton. While they don't give a shit about feature equality with other DAWS. They always try to differentiate. And I think that they are aware of its implantation among iOS users jumping to desktop. And the risk of a lot of these users jumping into Ableton, nor renewing their licenses, to have AUv3 support.

  • JUCE seems more promising to me.

  • @FastGhost said:
    JUCE seems more promising to me.

    JUCE isn't a plugin format.

  • @FastGhost said:
    JUCE seems more promising to me.

    Juce is a framework to create plugins, not a plugin format. Indeed, there are already external extensions to export Juce projects to Clap.

    Also, the Juce future is currently uncertain, because it was purchased by Pace, the company involved in iLok.

    And some of the original creators of Juce are now working in a new framework for Sounwide, the union of Native Instruments, iZotope and Plugin Alliance.

    While other is working at Tracktion, trying to create a framework similar to the original Juce, without relying in a big corporation, like Juce now.

  • @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

  • Sorry, posted half an opinion and then buggered off. The more rounded opinion was that I'm pulling for JUCE to reach a point where developers can output their plugins in whatever format they want (including CLAP, hadn't spotted that @NeonSilicon, thanks) as easily as possible, which would make support for CLAP or any other open format on iOS a lot less relevant as devs could just build all the formats including AUv3.

    Disclaimer: I've never even tried building a plugin so I may have completely misunderstood all of this

  • Here is an impressive video of Polarity, using Hive and Diva in Bitwig, driven by A SINGLE NOTE, plus tens of modulators in each single voice (something that currently can only be done using CLAP).

    https://twitter.com/polarity/status/1537098011947433991?cxt=HHwWjoCwse-f79QqAAAA

    So it's not only about a more open standard, nor relying in a corporation. This thing is vastly more powerful that the VST format, and it takes MIDI to another level. And we're still on beta.

  • @FastGhost said:
    Sorry, posted half an opinion and then buggered off. The more rounded opinion was that I'm pulling for JUCE to reach a point where developers can output their plugins in whatever format they want (including CLAP, hadn't spotted that @NeonSilicon, thanks) as easily as possible, which would make support for CLAP or any other open format on iOS a lot less relevant as devs could just build all the formats including AUv3.

    Disclaimer: I've never even tried building a plugin so I may have completely misunderstood all of this

    JUCE already does all those things. But not everyone wants to use JUCE for a variety of reasons.

    What this plugin format promises is performance advantages and playability flexibility that are not possible with existing plugin formats. Also its an open standard, which I think given the high handed way both Steinberg and Apple have behaved is a good thing.

  • edited June 16

    @NeonSilicon said:

    @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

    So there's no credible free open source alternatives to these licensed products?

  • @Pynchon said:

    They are a small team, but also the Cockos team is small, and they included AUv3 support before any other DAW. The workload is small in comparison to develop a new plugin format, or including ARM support. It's a matter of if it makes sense for the users. In the same moment in which a lot of plugins coming from iOS doesn't have VST3 versions, and only AUv3 versions, the story changes.

    Even if implementation would be not so much work, I think acceptance testing of new releases would be significantly more effort if they include AUs.

    And let's not forget that the attachment rate of Bitwig among iOS users is surprisingly high. Because the modular workflow in Bitwig fits well with the modular workflow used in applications such as AUM or Drambo.

    I think this is a very good point. I think Bitwig is the DAW that matches best the modular workflow of AUM and Drambo users. That’s probably the reason why I chose Bitwig. Also MPE is very much loved by the iOS crowd and I believe CLAP and MPE are a match in heaven given the modulation features of CLAP.

    Honestly when I did something great with Drambo on my iPad I always wished I could transfer it to Bitwig to develop it further. Imagine you could export a Drambo project to a Bitwig project with the modular setup of each track converted to a Bitwig Grid 😍

    The Bitwig team is really good looking to attract small niche markets, to compete with Ableton. While they don't give a shit about feature equality with other DAWS. They always try to differentiate. And I think that they are aware of its implantation among iOS users jumping to desktop. And the risk of a lot of these users jumping into Ableton, nor renewing their licenses, to have AUv3 support.

    There is the https://bitwish.top/ website for creating wishlists to Bitwig. I never really dug into it but it would probably a good place to make statement.

    @Pynchon said:
    Here is an impressive video of Polarity, using Hive and Diva in Bitwig, driven by A SINGLE NOTE, plus tens of modulators in each single voice (something that currently can only be done using CLAP).

    https://twitter.com/polarity/status/1537098011947433991?cxt=HHwWjoCwse-f79QqAAAA

    So it's not only about a more open standard, nor relying in a corporation. This thing is vastly more powerful that the VST format, and it takes MIDI to another level. And we're still on beta.

    Wow, just wow. What a cool demo of CLAP‘s capabilities. True game changer.

  • By the way, ChowDSP (maker of many fine "free" plugins) has been doing work in this arena, so if you're open to beta testing:

    https://chowdsp.com/nightly.html

  • @NeuM said:

    @NeonSilicon said:

    @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

    So there's no credible free open source alternatives to these licensed products?

    iPlug2 is an open source framework that is similar to JUCE, but not quite at the same level of polish. It is for building a plugin.

    CLAP is an open standard for plugins that is an alternative to VST3/AU. It defines how the plugin works, so that hosts/plugins have a common standard.

    Both are free in all senses of the word.

  • @NeuM said:
    By the way, ChowDSP (maker of many fine "free" plugins) has been doing work in this arena, so if you're open to beta testing:

    https://chowdsp.com/nightly.html

    Very cool. I will check it out. I love the Chow stuff.

  • @NeuM said:

    @NeonSilicon said:

    @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

    So there's no credible free open source alternatives to these licensed products?

    That depends on what you want to do with the code you build with it. JUCE and VST3 both have a dual commercial and GPL3 license. If you are going to license your software as GPL3, then this would be fine. I still wouldn't use them though to do open source software because I think the way they are using the GPL license isn't really in the spirit of what the GPL is about. Note that even if you aren't going to charge for your software, GPL3 is incompatible with distribution on the App Store.

    Faust generates perfectly good plugins in a variety of formats. But, I don't think anyone would release the generated code without significant changes to the UI portion of the plugin.

    LV2 has a good license, but I don't know of anything that supports it outside of Linux/BSD.

    Another thing to consider is that the plugin formats don't all do the same thing. AUv3 (and v2) does a whole lot more than just being a plugin for DAW's. LV2 needs to be able to solve problems that really only show up on Linux and BSD to any large degree (mostly to do with how host UI lib choice can impact the plugin UI). CLAP itself may have some issues with how its multithreading support interacts with the threading model on macOS (or iOS if that ever becomes a consideration). There are good reasons that Apple did their workgroup threading model for audio software to enable the scheduling of threads to happen at the OS level.

    Personally, I don't think that a cross platform library is a very good solution for the audio plugin space. But, that's not what CLAP is trying to do. They are trying to become a cross platform plugin specification. That has a whole lot more potential. I have some pretty strong doubts that they'll succeed, but I hope they do and I am definitely going to look into writing some plugins this way and see how it works.

  • @Zhuangzi said:

    @NeuM said:

    @NeonSilicon said:

    @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

    So there's no credible free open source alternatives to these licensed products?

    iPlug2 is an open source framework that is similar to JUCE, but not quite at the same level of polish. It is for building a plugin.

    CLAP is an open standard for plugins that is an alternative to VST3/AU. It defines how the plugin works, so that hosts/plugins have a common standard.

    Both are free in all senses of the word.

    I hadn't ever hear of iPlug2. Now that's a proper liberal license! I wish they hadn't based it on C++. One of the things I think is a very good choice by the CLAP folks is making the base API at the C level. It will make using it from various languages and environments much better.

  • @NeonSilicon said:

    @Zhuangzi said:

    @NeuM said:

    @NeonSilicon said:

    @FastGhost said:
    JUCE seems more promising to me.

    JUCE is a very different thing than CLAP. It's licensing is no better than VST3, so it doesn't solve the main issue that CLAP is trying to fix. With that said, there is already a JUCE plugin to build CLAP plugins with JUCE in the works. It's linked in the GitHub repository README, https://github.com/free-audio/clap

    So there's no credible free open source alternatives to these licensed products?

    iPlug2 is an open source framework that is similar to JUCE, but not quite at the same level of polish. It is for building a plugin.

    CLAP is an open standard for plugins that is an alternative to VST3/AU. It defines how the plugin works, so that hosts/plugins have a common standard.

    Both are free in all senses of the word.

    I hadn't ever hear of iPlug2. Now that's a proper liberal license! I wish they hadn't based it on C++. One of the things I think is a very good choice by the CLAP folks is making the base API at the C level. It will make using it from various languages and environments much better.

    Agreed. The Rust community has this framework:
    https://github.com/robbert-vdh/nih-plug

    I wrote a couple of toy plugins in it and it was quick and easy.

  • @NeonSilicon said:
    Personally, I don't think that a cross platform library is a very good solution for the audio plugin space. But, that's not what CLAP is trying to do. They are trying to become a cross platform plugin specification. That has a whole lot more potential. I have some pretty strong doubts that they'll succeed, but I hope they do and I am definitely going to look into writing some plugins this way and see how it works.

    Please, start porting CuSnP. Is one of the iOS FX plugins that I miss more on Bitwig :)

  • edited June 16

    @NeonSilicon said:
    Personally, I don't think that a cross platform library is a very good solution for the audio plugin space. But, that's not what CLAP is trying to do. They are trying to become a cross platform plugin specification. That has a whole lot more potential. I have some pretty strong doubts that they'll succeed, but I hope they do and I am definitely going to look into writing some plugins this way and see how it works.

    I think that’s a very valid point of view from the perspective of a developer and I can imagine that many other devs share this opinion. I also hope they succeed with CLAP. As a consumer all I can do is buying CLAP plugins, but that‘s probably more powerful than many people might think.

  • @Zhuangzi said:
    [...]

    Agreed. The Rust community has this framework:
    https://github.com/robbert-vdh/nih-plug

    I wrote a couple of toy plugins in it and it was quick and easy.

    I saw the link to the Rust support. That's definitely interesting. It's good to hear that you've tried it and that it works. I do have a library of already written C++ for audio processing. It would be hard to convince myself to redo all that (even though I really dislike C++). On the UI side of things, the C based architecture will really help with getting it working with Swift on the Mac.

    @Pynchon said:
    [...]

    Please, start porting CuSnP. Is one of the iOS FX plugins that I miss more on Bitwig :)

    Interesting. CuSnP is the plugin of mine that I use the most, but it's the least downloaded of all my plugins. It would definitely need a UI overhaul while doing a port to CLAP. I wrote the original UI using the gaming centric SpriteKit from Apple (weird choice, but I was interested in learning SpriteKit at the time). It could make for a good test case for me to see how things go with CLAP and porting plugins I already have.

    @krassmann said:
    [...]
    I think that’s a very valid point of view from the perspective of a developer and I can imagine that many other devs share this opinion. I also hope they succeed with CLAP. As a consumer all I can do is buying CLAP plugins, but that‘s probably more powerful than many people might think.

    Yeah, in the end, it's got to look profitable for the devs to support a new format.

  • @NeonSilicon said:
    Interesting. CuSnP is the plugin of mine that I use the most, but it's the least downloaded of all my plugins. It would definitely need a UI overhaul while doing a port to CLAP. I wrote the original UI using the gaming centric SpriteKit from Apple (weird choice, but I was interested in learning SpriteKit at the time). It could make for a good test case for me to see how things go with CLAP and porting plugins I already have.

    CuSnP plus Blackhole Reverb was always one of my secret sauces for creating textures.

    The thing is, I found a desktop equivalent, free, which its own flavour, that it does marvelously the combination of added harmonics plus reverb. It's HarmonicReverb by ChromaDSP. Sadly, it's not M1 native.

    Now that I have a second installation of MacOS in an USB-C external disk, only intended for testing plugins without filling the hard disk of my working system with impossible to catch hidden files after uninstallation, I also dowloaded the demo of Superchord. In theory, it works like CuSnP. But honestly, it was a disappointment. In the presets that I tried, it was far of the musicality of CuSnP and HarmonicReverb. I was willing to pay 99 dollars to have a M1 native, compatible with Bitwig equivalent.

Sign In or Register to comment.