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.

X (was about programming AU and which language to use)

13

Comments

  • @clowm That confused me too at first. You’re correct – just use the fullState properties.

  • @clowm said:
    or do we simply need to use fullState fullDocumentState?

    Yes: just add the data to the dictionary you create in fullState / fullDocumentState to save it as part of a preset.

    You can also save data outside of the presets by putting the AU and containing app into an app group and using NSUserDefaults initWithSuiteName to create the defaults.

  • @clowm said:
    One thing is that I don't understand from documentation and examples, what is the way to store for example MIDI data in AudioUnit parameters like Atom do. Can we add nodes and parameters to the tree dynamically? (it seems there are no methods for it). Or do we destroy and create again _parameterTree object when we need to allocate more nodes? Or I dunno

    You can alter the structure of the parameterTree after it has been created and hosts will get a notification that it has been altered, but I doubt if all hosts would work with this usage pattern. (Note that changing the parameterTree is specifically called out as not real-time thread safe.) Remember that observing on the parameter values in the parameterTree is meant to be the way that hosts, the AU, and even your own UI are kept in-sync.

    The fullState property is the way to pass any data that you would need configuring the running state of the AU. Basically any data that a host would need to pass you to implement a preset change. So, you would save parameter state and any other data that your AU needs in this structure. You need to make sure that everything you put in here is done in a serializable format. FullStateForDocument is meant for adding in any other data that a host might need to pass you beyond what a preset recall using fullState would store. You might use it in a host for Set change documents or something. I doubt if very many AU's actually use this one. It's helpful to remember that AU's are designed to be used in a much broader setting than plugins. You can pretty much write entire programs just out of AudioUnits. All sorts of programs and frameworks use them in non-music production settings. So, the spec is actually pretty broad and deep. It makes it more of a pain to figure out what to do in a plugin type setting.

    I'd recommend not using the base class version of fullState that Apple provides. I was doing this before the iOS 14 update and Apple broke things badly with this. I actually don't need anything beyond what the base class implementation provides but I've changed to my own code now. When researching the problem that iOS 14 caused, it became pretty clear that Apple doesn't consider using the base class implementation the right way to do this. That's fine, but they really shouldn't provide a default implementation in that case.

  • edited December 2020

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

  • @WizardQuestion said:

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

    I can think of other reasons that someone might be compelled to go back and delete their interactions with the world that are not motivated by selfishness. But, the result isn't good in a community context. There certainly wasn't anything wrong with the question or comments that would drive someone to need to delete them.

  • @WizardQuestion said:

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

    He deleted all of his posting, in any thread.

    We already had someone doing this, years ago - same behavior.
    Same person?

  • edited December 2020

    Apps4iDevices? iOSMusicAppsInfos? :D (he's the one who keeps threatening developers, including myself, with negative reviews when they don't comply with his requests for promo codes, etc...)

  • @NeonSilicon said:

    @WizardQuestion said:

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

    I can think of other reasons that someone might be compelled to go back and delete their interactions with the world that are not motivated by selfishness. But, the result isn't good in a community context. There certainly wasn't anything wrong with the question or comments that would drive someone to need to delete them.

    Paranoia? Low-self esteem? Making of a fake mysterious persona with the same nickname?

  • @WizardQuestion said:

    @NeonSilicon said:

    @WizardQuestion said:

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

    I can think of other reasons that someone might be compelled to go back and delete their interactions with the world that are not motivated by selfishness. But, the result isn't good in a community context. There certainly wasn't anything wrong with the question or comments that would drive someone to need to delete them.

    Paranoia? Low-self esteem? Making of a fake mysterious persona with the same nickname?

    Yeah, could be, or maybe crushing self-doubt or just confusion about proper forum etiquette. It's hard to tell what someone's motivation might be and I can't tell from this context. I do understand that some people get perverse pleasure out of messing with forums, but that doesn't seem to fit with this thread at least. The original question was reasonable and didn't have anything in it that was flamebait.

  • @NeonSilicon said:

    @WizardQuestion said:

    @NeonSilicon said:

    @WizardQuestion said:

    @tja said:
    For what reason did you destroy this topic by renaming it to "X" and replacing all of your texts by "X" too, @mercurialization

    This is an affront to all other members of the forum!

    He is selfish. Look his others posts and threads...

    He wants his answers, but nobody can't have it.
    Because he is oh so mysterious and oh so special.
    What an artist...

    I can think of other reasons that someone might be compelled to go back and delete their interactions with the world that are not motivated by selfishness. But, the result isn't good in a community context. There certainly wasn't anything wrong with the question or comments that would drive someone to need to delete them.

    Paranoia? Low-self esteem? Making of a fake mysterious persona with the same nickname?

    Yeah, could be, or maybe crushing self-doubt or just confusion about proper forum etiquette. It's hard to tell what someone's motivation might be and I can't tell from this context. I do understand that some people get perverse pleasure out of messing with forums, but that doesn't seem to fit with this thread at least. The original question was reasonable and didn't have anything in it that was flamebait.

    Fair enough.
    It is just strange to deprive another users from the question being answered.
    But like you said, since it lacks context, I can't assume nefarious reasons.

  • Interesting thread here. Too bad about the Xs, but never mind.

    The reason I popped by is that I've been thinking hard about a tech stack that would allow me to create the DSP part of both AUv3 extensions and a rendering synth (running locally or in the cloud) with something else than C++. (Not going too deep into the reasons why, but let's just say I thought I got rid of C++ in 1995; it's OK but I'd rather use something else, and as Swift is still not an option, here we are).

    Case in point: Rust. I've sort of glossed it over until now, but I got some sort of epiphany and spent a weekend learning the basics. So far I'm kind of liking it.

    What's more, I just did a walkthrough where a library was created in Rust and then linked into an iOS app written in Swift. (Just a "Hello, world!" but proves the point in practice.) That got me thinking it would probably be feasible to use a DSP engine written in Rust, compiled to a static library, and linked to an AUv3 app extension. Of course it's probably not that straightforward, but it's worth a shot, I think.

    I haven't found a lot of specific material on the web about this; some Rust/audio/AU stuff is out there but it's more about accessing the AU APIs, whereas I'm thinking of replacing the current C++ based "DSPKernel" stuff with Rust. You really only have to provide a buffer of samples when it is requested, so the Swift/Objective-C/Rust interface is rather light, I think.

    So I would appreciate any further pointers, and would like to trade notes if anyone has been working in this area. (This thread is in a weird category, but I fearlessly resurrected it anyway.)

  • What you are looking to do should be possible. It may be a bit of a pain though. This is primarily going to be coming from tool integration issues and a little bit from the library side.

    The main thing with the tool aspect is that Rust really likes its build/package system and Xcode really likes its build/package system. Personally, I don't like either of them. You can get outside of both of them and build your own workflow, but Xcode's connection to Instruments, simulators, and debugging on device is really nicely integrated and would be hard to work without. Xcode is pretty Swift/Objective-C/C/C++ centric. I don't think it even has any of the older Java stuff left in it.

    I recently made a try at doing a Swift and C only AUv3. It almost worked very easily. It's only almost because I ran into one issue where there is something in the AVFoundation stuff that I assume is C++ based. This didn't play well with the C I was using to do the DSP kernel. I assume that you would be able to isolate the C++ out of the way. But, there is a bit of an issue lurking there. It's a bit weird too, because almost all of Apple's foundation layer stuff is pure C.

    There are other paths you can try to do this too. The interface into the AUv3 from the host/OS side is really two classes/interfaces that can be implemented in Swift. These are the AUAudioUnit and the factory protocol. These could be done lots of ways. I just noticed a couple of days ago that the VST3 SDK has means of wrapping a VST3 into an AUv3. I'm thinking of checking this path out now as it has several advantages for code reuse.

    With all that said, the DSP world pretty much talks in C++. It's very basic simplistic C++ for the most part and avoids most of the C++ garbage and baggage so it isn't too bad to use and it is some work to take a different path.

  • edited February 2021

    Hey, thanks for your response. Certainly I have no expectation of Xcode doing anything for me here, if not actively working against me. But it seems that a static library created in Rust, for the right architecture, linked with the app, and with the help of a bridging header, seems to work OK (details here; works mostly the same today, Xcode UI has just changed a bit: https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-06-rust-on-ios.html. EDIT: A newer treatise with some of the ideas I outlined below: https://visly.app/blogposts/rust-on-ios)

    I was thinking that I could add the Rust library build as a build phase in my Xcode project, and then maybe add some tests to see that the integration is still working. Any debugging and testing of the Rust code itself would happen outside of Xcode, probably editing too (VSCode). Also, I'm looking at making a library that can also be used from a standalone Rust app and an AWS Lambda function.

    There's definitely C++ in AVFoundation, that much is obvious from the AVAudioEngine error messages I got around the release of iOS 13. I'll need to see what kind of interface would actually be required to interface the Rust code with the AUAudioUnit parts. I'm aware that they can be done in Swift, even if Xcode 12 still generates those parts in the AUv3 app extension as Objective-C code.

    The part about the VST3 SDK and AUv3 wrapper is interesting. I played with the VST3 SDK some time ago but had issues in macOS, and on Windows I kind of switched gears to look for alternatives to C++.

    I realize that in the audio/DSP world C++ is the most common language. So it would be the path of least resistance just to embrace it. But I guess I'm stubborn enough to see if I can actually come up with something that works in Rust. I wanted to look into the AUv3 + Rust integration just to see if it was feasible, and most likely I will concentrate on the DSP outside of AU first.

  • @coniferprod Please keep us updated! I've done some similar integrations (like Python bindings for C and C++ DSP code), but this is a bit further off the beaten track and I'm interested to see how it works out for you.

  • I spent the last couple of days with some time to waste, so I tried to see if I could strip all of the C++ and Objective-C/C++ out of an AU I've been working on. In short the answer is yes.

    I've built and tested an AU built with only Swift and C. It would be possible to avoid even the C, but I think this would be risky right now because of some screwy copying that happens with some of Swift's UnsafePointer classes. Basically, the only C that I have is a couple of bridges to avoid this possibility.

    I'm not trying to suggest that writing an AU in pure Swift is advisable (it isn't at this point). But, using this path it would be pretty easy to bridge the Swift with a minimal C layer to any language you wanted to use that was compatible with C.

    I may pull out a simple example of how it works if anyone is interested.

  • @NeonSilicon said:

    I may pull out a simple example of how it works if anyone is interested.

    Yes please, yes please, yes please 😅🤗

  • @NeonSilicon said:

    I may pull out a simple example of how it works if anyone is interested.

    That would be really nice ™

  • I'm not sure how to present this without making it seem more complicated than it is. It is pretty simple to do, but slotting it in to the AU code structure makes it look more confusing. I'll start out by making a volume control AU or something. I'll follow up here when I have the presentation sort of figured out and posted up somewhere.

  • I've put up a repository on GitHub with the demo AUv3 of how I think this can work to merge doing DSP in other languages with the AU code in Swift. The link is here, https://github.com/NeonSilicon/Demo_Volume_AUv3

    To try and get around the whole issue of having to have a dev team and a signing key for iOS dev, I've set the project up as Mac Catalyst enabled. This should allow building and testing the iOS AUv3 directly on the Mac. If you do want to build it and try it on iOS, you'd need to take the steps to sign it.

    Take the warning in the section of the readme on the state of the code to heart. This really isn't production ready code. It's been put together pretty fast. But, I think it's interesting as an experiment and point of exploration.

  • @NeonSilicon said:
    I've put up a repository on GitHub with the demo AUv3 of how I think this can work to merge doing DSP in other languages with the AU code in Swift. The link is here, https://github.com/NeonSilicon/Demo_Volume_AUv3

    To try and get around the whole issue of having to have a dev team and a signing key for iOS dev, I've set the project up as Mac Catalyst enabled. This should allow building and testing the iOS AUv3 directly on the Mac. If you do want to build it and try it on iOS, you'd need to take the steps to sign it.

    Take the warning in the section of the readme on the state of the code to heart. This really isn't production ready code. It's been put together pretty fast. But, I think it's interesting as an experiment and point of exploration.

    Awesome, thanks @NeonSilicon
    Actually didn't think of the potential of testing iOS apps directly on Mac. This is great.

  • @coniferprod said:
    The reason I popped by is that I've been thinking hard about a tech stack that would allow me to create the DSP part of both AUv3 extensions and a rendering synth (running locally or in the cloud) with something else than C++. (Not going too deep into the reasons why, but let's just say I thought I got rid of C++ in 1995; it's OK but I'd rather use something else, and as Swift is still not an option, here we are).

    Case in point: Rust. I've sort of glossed it over until now, but I got some sort of epiphany and spent a weekend learning the basics. So far I'm kind of liking it.

    It's a good language with excellent tooling and community. Definitely one of the harder languages to learn, but then compared to C++ (been using it for 20 years and still don't really feel like I know it) it's not so bad. I think in the long term it will probably become the language of choice for new projects because it's easier to use, has fewer issues than C++ and is generally more productive. But that's probably the next 10-20 years.

    There are various approaches to this varying from quite easy, to a lot more difficult. The easiest way would be to write a Rust DSP engine in Rust, and provide a C FFI for it (Rust makes this very easy, and a lot of libraries are starting to be written this way). Then your glue code (presumably C++, but maybe Swift?) could call your DSP library.

    The more difficult way would be to write a Rust library that takes your code and makes it into an AUv3. This is kind of how JUCE works, and there's been quite a bit of work over the past 2 years to do this in Rust for VST2/3 and a couple of other formats. Nobody has done this for Apple, because none of the developers working on this seem very interested in IOS. The VST code isn't mature, but people have written VSTs (including a couple of commercial ones with it) and it's pretty close to being viable imho. Look up the Rust Audio group - best way to contact them is on Discord. If you google Rust Audio Discord you should find a link.

  • @NeonSilicon said:
    I've put up a repository on GitHub with the demo AUv3 of how I think this can work to merge doing DSP in other languages with the AU code in Swift. The link is here, https://github.com/NeonSilicon/Demo_Volume_AUv3

    To try and get around the whole issue of having to have a dev team and a signing key for iOS dev, I've set the project up as Mac Catalyst enabled. This should allow building and testing the iOS AUv3 directly on the Mac. If you do want to build it and try it on iOS, you'd need to take the steps to sign it.

    Take the warning in the section of the readme on the state of the code to heart. This really isn't production ready code. It's been put together pretty fast. But, I think it's interesting as an experiment and point of exploration.

    As I have a new Mac, I will try to compile this.

    Many thanks for you work!!! 🤗🤗🤗

  • @NeonSilicon said:
    The main thing with the tool aspect is that Rust really likes its build/package system and Xcode really likes its build/package system. Personally, I don't like either of them.

    What's wrong with Rust's build package systems. I've used... a lot of different systems and Rust is easily one of the best I've dealt with. Most of the time it just works without me really have to put a lot of thought into it, which certainly has not been my experience with CMake (or C/C++ equivalents), or indeed any of the JavaScript, Python ones I've had to use either. Even when I had to do something complicated involving code generation, compiling a C library with a make file and something else - it took me about 20 minutes to get it working. Honestly I don't think I've ever heard anyone really complain about cargo, even people who hate the language.

    With all that said, the DSP world pretty much talks in C++. It's very basic simplistic C++ for the most part and avoids most of the C++ garbage and baggage so it isn't too bad to use and it is some work to take a different path.

    I doubt most of the current generation of DSP people will change, but I suspect you'll see a lot of the next generation switch to Rust because it is so much easier to work with. I can also see Rust being used as a teaching language for systems courses because again it's a lot easier to teach than C++, in the same way that Python ended up being a language that colleges taught.

    There are a few early signs of change currently. There's a push internally by a couple of engineers at Ableton to use Rust, but I still think we're a few years off (at least) before using Rust is the easy option. I think the biggest block is probably that everyone's got used to writing stuff with JUCE, and until Rust has something that can compete with JUCE (which is easier than it sounds, because the Rust ecosystem actually takes care of a lot of what JUCE offers), C++ will continue to dominate among plugins.

  • edited March 2021

    This thread is extremely interesting. I’m gonna read it a couple of times.
    I work in web dev, mainly PHP, JavaScript, Typescript... I had a look at some Objective-C code that Michael posted in the Loopy Pro thread and I have to say I found it cryptic and hard to read. Not a good first impression for the curious.
    This was the actual snippet he posted.

    How hard is it?.

  • @NeonSilicon said:
    Javascript: https://www.destroyallsoftware.com/talks/wat
    The JS part starts about a minute and a half in or so.

    Man , this is pure gold!! 😂😂🤣😂
    I ❤️ this forum.

  • @tahiche said:
    This thread is extremely interesting. I’m gonna read it a couple of times.
    I work in web dev, mainly PHP, JavaScript, Typescript... I had a look at some Objective-C code that Michael posted in the Loopy Pro thread and I have to say I found it cryptic and hard to read. Not a good first impression for the curious.
    This was the actual snippet he posted.

    How hard is it?.

    Objective-C is pretty easy in my opinion. Many people find its syntax cryptic. Once you get used to it, it is easy to read. More importantly, Objective-C is easy to reason in. It isn't as easy as it used to be, but it still isn't bad compared to some languages. There are many more "magic" things that happen now then there were when I first learned it decades ago. It is still a pretty straight forward language though.

    The main thing is that it really isn't worth investing time in anymore unless you already know it. Apple platforms have been the main use of Objective-C for a long time, and that is going away for nearly all new development. Apple is moving to Swift. Swift is pretty good. There's no reason not to go along for the ride if you want to develop for macOS and iOS.

  • @NeonSilicon said:

    @tahiche said:
    This thread is extremely interesting. I’m gonna read it a couple of times.
    I work in web dev, mainly PHP, JavaScript, Typescript... I had a look at some Objective-C code that Michael posted in the Loopy Pro thread and I have to say I found it cryptic and hard to read. Not a good first impression for the curious.
    This was the actual snippet he posted.

    How hard is it?.

    Objective-C is pretty easy in my opinion. Many people find its syntax cryptic. Once you get used to it, it is easy to read. More importantly, Objective-C is easy to reason in. It isn't as easy as it used to be, but it still isn't bad compared to some languages. There are many more "magic" things that happen now then there were when I first learned it decades ago. It is still a pretty straight forward language though.

    The main thing is that it really isn't worth investing time in anymore unless you already know it. Apple platforms have been the main use of Objective-C for a long time, and that is going away for nearly all new development. Apple is moving to Swift. Swift is pretty good. There's no reason not to go along for the ride if you want to develop for macOS and iOS.

    I peeked at the GitHub project you posted demonstrating Swift (thanks for that!) and I find it a lot easier to understand. A lot closer to what I’m used to. Cheers!

  • @cian said:

    @NeonSilicon said:
    The main thing with the tool aspect is that Rust really likes its build/package system and Xcode really likes its build/package system. Personally, I don't like either of them.

    What's wrong with Rust's build package systems. I've used... a lot of different systems and Rust is easily one of the best I've dealt with. Most of the time it just works without me really have to put a lot of thought into it, which certainly has not been my experience with CMake (or C/C++ equivalents), or indeed any of the JavaScript, Python ones I've had to use either. Even when I had to do something complicated involving code generation, compiling a C library with a make file and something else - it took me about 20 minutes to get it working. Honestly I don't think I've ever heard anyone really complain about cargo, even people who hate the language.

    With all that said, the DSP world pretty much talks in C++. It's very basic simplistic C++ for the most part and avoids most of the C++ garbage and baggage so it isn't too bad to use and it is some work to take a different path.

    I doubt most of the current generation of DSP people will change, but I suspect you'll see a lot of the next generation switch to Rust because it is so much easier to work with. I can also see Rust being used as a teaching language for systems courses because again it's a lot easier to teach than C++, in the same way that Python ended up being a language that colleges taught.

    There are a few early signs of change currently. There's a push internally by a couple of engineers at Ableton to use Rust, but I still think we're a few years off (at least) before using Rust is the easy option. I think the biggest block is probably that everyone's got used to writing stuff with JUCE, and until Rust has something that can compete with JUCE (which is easier than it sounds, because the Rust ecosystem actually takes care of a lot of what JUCE offers), C++ will continue to dominate among plugins.

    I don't like any build system that is tied to a language. It doesn't work well in industrial scale settings. Many companies I've worked for have their own internal build systems. Rust would be rejected at these companies just because of this. One way to look at it is that the build/package system for Rust is the way one company thought it should be. Many other companies won't agree with their path. But, steps are being taken by some players to make using Rust more compatible with custom development environments.

    From a security standpoint, there are problems with the whole package manager mentality. This is in no way unique to Rust. In fact Swift is going down this path now too. But there are major problems with this development mentality in things like banking, communications, healthcare, and other highly secure systems. I've worked on multiple projects where a package manager wouldn't have been allowed anywhere near the project. Surprisingly, one of this was an audio/music related thing.

    Rust is interesting to me and has promise. I'm really interested in where it goes and I particularly like what it might do for the embedded space. So, I'm not trying to knock on Rust really, it's just that I see some real stumbling blocks for wide adoption.

  • @seonnthaproducer said:

    @NeonSilicon said:
    I've put up a repository on GitHub with the demo AUv3 of how I think this can work to merge doing DSP in other languages with the AU code in Swift. The link is here, https://github.com/NeonSilicon/Demo_Volume_AUv3

    To try and get around the whole issue of having to have a dev team and a signing key for iOS dev, I've set the project up as Mac Catalyst enabled. This should allow building and testing the iOS AUv3 directly on the Mac. If you do want to build it and try it on iOS, you'd need to take the steps to sign it.

    Take the warning in the section of the readme on the state of the code to heart. This really isn't production ready code. It's been put together pretty fast. But, I think it's interesting as an experiment and point of exploration.

    Awesome, thanks @NeonSilicon
    Actually didn't think of the potential of testing iOS apps directly on Mac. This is great.

    Me either until I was trying to figure out how to put this up on GitHub without including my own signing credentials or making people get their own just to look into how to use this. I've been developing a cross-platform library to make it easier for me to write a program that I'm working on for both iOS and macOS. That had me thinking in a dual platform sorta mindset. So, this kinda just popped into my head. I hope that it actually works for people.

Sign In or Register to comment.