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)

«134

Comments

  • There’s not too much out there as far as I know (especially on YouTube) but these might help:

    MIDI:
    http://ruismaker.com/au-midi-plugins/

    http://www.rockhoppertech.com/blog/auv3-midi/

    Audio:
    http://devnotes.kymatica.com/

    http://subfurther.com/blog/2017/04/28/brain-dump-v3-audio-units/

    https://medium.com/better-programming/create-audio-unit-extension-from-scratch-77abee79d12

    (Not sure about the last one as I haven’t read it but it came up and looks potentially promising)

    You’ll probably have to write the AU code in Objective C but you can definitely write UI stuff in Swift.

    You also want to make sure to have a good grasp on synchronization, threads, and real-time safety when dealing with the render block. See here: http://atastypixel.com/blog/four-common-mistakes-in-audio-development/

    DSP code will also tend to involve a decent amount of math.

  • For video content about AUv3 dev get the Developer.app program from the App store. It's available for the Mac and iPhone/iPad. It's got all the content from WWDC and other videos that Apple has done. There is stuff there for audio dev. What is there is haphazard and far from complete. You also have to get very familiar with the docs on developer.apple.com. Learn how to search these for the content that is there. Be warned, Apple's new documentation is bad. You can find some links to their old docs sometimes. The old docs are less bad. They are also less useful today. There is good documentation on the version 2 AU's. There is lots of stuff in the docs for the AUv3 spec that talks about how features are "bridged" to the V2 spec. So, it can be helpful to know this stuff too.

    It's important to know what your goals are though. If you want to only develop AUv3's, where to look and what to use is very different from what you would want to do if you want to develop plugins for other specs too. If you want to develop commercial plugins, that's different from what you might want to do if you are looking to develop things for your own usage.

  • edited December 2020

    X

  • wimwim
    edited December 2020

    You can use C++ too. In fact, I think you need to for the realtime safe bits. Most of the head scratching parts for me is figuring out how to successfully bridge the C++ classes to Swift.

    Good article here: https://www.rockhoppertech.com/blog/audio-units-auv3-midi-extension-part-2-c/

    Also some bits about not using Obj-C on the realtime thread: http://atastypixel.com/blog/four-common-mistakes-in-audio-development/

  • wimwim
    edited December 2020

    The JUCE framework is a good way to get some feeling for C++ and Audio Unit code: There are some basic (JUCE oriented) tutorials there. I had some challenges getting it to work right with XCode, but that was some time ago.

    https://juce.com/

  • @mercurialization Unfortunately Swift just isn’t safe enough for this kind of task yet. Objective C is a bit of a pain, but you only really need it for the object-oriented shell of your AU. The rest can (and in some cases must, as @wim alludes to) be written in the pure C subset or careful C++. I generally write as much as I can in C++.

    @wim If you have any questions I’d be happy to look at stuff with you. It took me a bit but now I’ve got Objective C, C, C++, and Swift playing nice together and it’s a decent setup since I can choose whichever is best for a given task.

  • wimwim
    edited December 2020

    @TonalityApp said:
    @wim If you have any questions I’d be happy to look at stuff with you. It took me a bit but now I’ve got Objective C, C, C++, and Swift playing nice together and it’s a decent setup since I can choose whichever is best for a given task.

    Oh wow! Thank you so much for the offer. I’ve put that aside for a bit to allow my wounds from banging my head against the wall to heal. But, when I come back to it, I will make you sorry you offered. B)

  • @wim Very fair :D
    It’s definitely daunting at first and Xcode build errors certainly don’t help. I remember wasting hours on bridging headers that I knew I was doing right before finding the issue resolved when I restarted.

  • @wim Yeah, I kept my project on hold once I realized I needed to improve my scripting and C++ skills. It’s still very much a work in progress, although still a bit of a learning curve.

    @TonalityApp -Is it okay if I bug you a little as well? Right now, I’m learning bits of each language, while prototyping but it’ll be awesome to know how to combine them together.

  • @mercurialization said:

    @TonalityApp said:
    You’ll probably have to write the AU code in Objective C but you can definitely write UI stuff in Swift.

    Thank you for the sources. That's so unfortunate about having to use Objective-C. I'd much rather use Swift for the entirety of the project, or another language altogether.

    As the second most-dreaded language, according to StackOverflow's Developer Survery 2020, I equally dread needing to use it for AUv3. The syntax doesn't appeal to me at all.

    Obj-C is actually a pretty nice language. It's certainly much easier to reason in than C++. Swift is fine too. It isn't really any better to program in than Objective-C though.

    A couple of things to note when looking into programming for macOS or iOS. Pretty much the entire foundation of everything is written in C. No Objective or ++ involved. Anything that is labeled "Core" or "Foundation" is going to be in C. Objective-C is layered on top of that and then Swift is over the top of the Objective-C layer. So, even if you are going to work in Swift only, it's good to be conversant in C and Objective-C. I think that SwiftUI is actually not layered on top of Objective-C, so things are probably going to slowly change as Apple introduces new libraries.

    The API for AUv3 is actually defined in Objective-C. But, since Swift can do anything Objective-C does, there is a Swift API that you can work with to provide the interface between the AUv3 and the host and OS.

    As noted, Swift can't be used for anything realtime. This is because of the runtime system support in Swift. The eventual goal for Swift is supposed to be getting it to the point where you can do systems level stuff in it, but you can't do it today. You can actually write the DSP code in pretty much any language you want that has an interface to C. And that's includes almost any language. Almost everyone uses C++ for this task, but I've seen AU's written in D, Pascal, Faust, etc.

    Swift can't interface directly to C++ (yet). This is really because C++ sucks and isn't Swift's issue. But, it does mean that if you want to write your DSP code in C++, you need a very small Objective-C++ shim between your Swift code and your C++ DSP code. If you wanted to write your DSP in plain C, you can do without the Objective-C layer.

    Personally, I write the whole AUv3 part in Objective-C++ with C++ used for all the DSP. I write the entire UI in Swift. I have experimented with writing an AU in only Swift and C with C for all the DSP. This does work, but as much as I hate C++, I've got tons of DSP audio code that I've written in C++ over the years and it would get pretty ugly to rewrite all of that in pure C.

  • So rust and swift is an option. Interesting.

  • @seonnthaproducer Sure
    @NeonSilicon I agree with or have encountered most of the things you mention. Why the dislike toward C++ though? Also for some tasks I’ve found certain Swift features (like optional chaining) much more convenient than Objective-C.

  • At least Objective-C is still C based. Swift is an utterly unneccessary proprietary language that should not exist imho.

  • @brambos Proprietary? I don’t think it has been for years. I tend to prefer C family languages as well, but for interfacing with non-audio iOS code Swift has grown on me. Why do you dislike it so strongly?

  • @NeonSilicon
    Swift can't interface directly to C++ (yet). This is really because C++ sucks and isn't Swift's issue.

    strongly disagree... C++ is there for ages, and it is used everywhere where real performance optimisarion is needed... this is pure swift design flaw, it's just and only swift fault

    C++ is very deep and complex language and because of it's complexity it needs also very good skilled developer to utilise it's strentghtness and avoid it's weakness - but in hands of skilled dev it's powerfull tool... mother and faher of all object oriented languages

    btw still one of most requested and best payed language skills on job market ;)

  • @dendy said:

    @NeonSilicon
    Swift can't interface directly to C++ (yet). This is really because C++ sucks and isn't Swift's issue.

    strongly disagree... C++ is there for ages, and it is used everywhere where real performance optimisarion is needed... this is pure swift design flaw, it's just and only swift fault

    No it's C++'s fault. C++ doesn't have a stable ABI, and there are various things in C++ where it's impossible to reliably call it from any language (the usual solution is to create an interface which is either pure C, or a subset of C++ and then statically link your libraries).

    I haven't used Swift, but as a high level language it looks pretty decent. The SwiftUI stuff that Apple is working on is extremely nice. For performance stuff it's obviously not suitable, but then that's not really it's purpose. As an Objective-C replacement it makes sense I think.

    C++ is very deep and complex language and because of it's complexity it needs also very good skilled developer to utilise it's strentghtness and avoid it's weakness - but in hands of skilled dev it's powerfull tool... mother and faher of all object oriented languages

    C++ is a walking disaster of a language. C++17 has fixed many of the issues... except you still have bloody C++98 lying under the surface with it's numerous unexploded landmines, inconsistencies and complexities. And even in C++17 you have all these weird issues which cause unexpected behavior. And if you have to interface with someone else's libraries... good luck.

    There are a lot of places (low level code, realtime) where C is still used because trying to predict what C++ will actually do is too damn hard. There's a reason why Linux doesn't use C++ for example and never will.

    When I switched to Rust for personal projects it was ridiculous how much more efficient I was, while the code wasn't any slower (and was far easier to optimize). Whenever I have to write C++ code now it's painful, as I have to spend so much time thinking about all the quirks of C++, rather than my underlying model of the code/computer architecture.

  • edited December 2020

    @dendy said: C++ is ... mother and faher of all object oriented languages

    I beg to differ. Smalltalk pre-dates C++ as the first true fully OOPL in 1980 and was also the primary influence when Brad Cox developed Objective-C. Initially C++ was little more than C with classes, but it's moved on since then of course, often in mysterious ways...

    It's funny seeing these Swift vs. C++ / Objective-C debates. Reminds me of the C vs. C++ debates in the 80's :smile:

    My vote for the most beautifully engineered OOPL of all time goes to Eiffel. Compiled out to ANSI C too, so it was a nice high-level and powerful utility language, but still performed incredibly well.

  • The biggest issue with Swift is that it is completely redundant. Objective-C does everything it needs to do; there was no need to introduce yet another language you can only realistically use on a single platform (lack of portability is bad enough in itself, but at least Objective-C mixes nicely with C when you want to minimize the amount of hard-to-port code).

    Now we are stuck in an unfortunate situation where all tutorials and StackOverflow snippets need to be provided in two languages, or be useless to half of the community. Apple are also slacking in providing samples in both languages. It's a huge mess, made worse by the fact that they still keep changing Swift all the time.

  • edited December 2020

    @cian said:
    So rust and swift is an option. Interesting.

    You could. Swift is a given. One thing to consider though is that Xcode is really an Objective-C, Swift, C, C++ tool. And the instruments and debugging and simulators from Xcode are really useful.

    @TonalityApp said:
    @seonnthaproducer Sure
    @NeonSilicon I agree with or have encountered most of the things you mention. Why the dislike toward C++ though? Also for some tasks I’ve found certain Swift features (like optional chaining) much more convenient than Objective-C.

    Many reasons for my dislike of C++. The first requires a Shrek reference, forgive me. Objects shouldn't be like ogres. They shouldn't have layers. This alone leads to many of the issues that C++ causes. The second one is how C++ handles pass-by-value versus pass-by-reference and stack versus heap allocation. Combine this with ogres and you get all sorts of problems. An O-O language has to handle this better than C++ does to have me like it. Next, there are so many layers and concepts in C++ now that it is hard to read code. It's nearly as bad as Perl. A language needs to communicate to developers more than it does to the compiler. C++ really fails miserably in this regard. Every time they add a new idea to C++, it has to be "orthogonal." Look at the new module concept and how it interacts with namespaces. Why?

    The final point for me with C++ is that I really like multiple inheritance. C++ boned this up so much that every new language runs away from it without even considering that it is a solved problem and it has been done well before. So, we have all of these interface based languages now that cause a great deal of unneeded complexity and they don't even solve the problem of M.I. in the end anyway. I.e. the "diamond" problem is a semantic issue, not a syntactic one. I hate C++ for this.

    @moodscaper said:

    @dendy said: C++ is ... mother and faher of all object oriented languages

    I beg to differ. Smalltalk pre-dates C++ as the first true fully OOPL in 1980 and was also the primary influence when Brad Cox developed Objective-C. Initially C++ was little more than C with classes, but it's moved on since then of course, often in mysterious ways...

    It's funny seeing these Swift vs. C++ / Objective-C debates. Reminds me of the C vs. C++ debates in the 80's :smile:

    My vote for the most beautifully engineered OOPL of all time goes to Eiffel. Compiled out to ANSI C too, so it was a nice high-level and powerful utility language, but still performed incredibly well.

    Absolutely! Eiffel and Sather are really well thought out O-O languages. I've been lucky enough to actually get payed to work in both of them. Wonderful!

  • @cian said:
    So rust and swift is an option. Interesting.

    You could. Swift is a given. One thing to consider though is that Xcode is really an Objective-C, Swift, C, C++ tool. And the instruments and debugging and simulators from Xcode are really useful.

    Yeah that's a good point. If I was to go down this route I would write the DSP code in Rust and expose it as a c library. And then probably work out the least painful way to write my wrapper code. If you can write the GUI code for an AUV3 in Swift that would work for my purposes.

  • @brambos said:
    The biggest issue with Swift is that it is completely redundant. Objective-C does everything it needs to do; there was no need to introduce yet another language you can only realistically use on a single platform (lack of portability is bad enough in itself, but at least Objective-C mixes nicely with C when you want to minimize the amount of hard-to-port code).

    Now we are stuck in an unfortunate situation where all tutorials and StackOverflow snippets need to be provided in two languages, or be useless to half of the community. Apple are also slacking in providing samples in both languages. It's a huge mess, made worse by the fact that they still keep changing Swift all the time.

    I basically agree with you. But, Objective-C doesn't have all the cool new features that gain mindshare. Swift does. There are things that I think Swift has done better than Objective-C. I see a not too different future where if you want to program in Objective-C, then you are going to need to know how to translate Swift examples into it. I don't think the two languages issue is going to last all that long.

    The good thing is that Apple does still do almost all their base level stuff in C. We can still use it from most any language we want in the end.

  • @NeonSilicon said:
    The second one is how C++ handles pass-by-value versus pass-by-reference and stack versus heap allocation.

    This, oh god this. Also working how to initialize an object properly in C++ can be a surprisingly difficult problem.

    Next, there are so many layers and concepts in C++ now that it is hard to read code.

    C++ is the only language I've used where you have to be a language lawyer to write what should be reasonably straighforward code.

    Look at the new module concept and how it interacts with namespaces.

    I don't want to, you can't make me...

    I think Rust puts to the lie the idea that a low level language has to be this complex. Rust manages to be principled and comprehensible in a way that C++ never managed. While I like Rust, I do think it's a shame that nobody ever built a modernized C. Not something that attempts to rebuild modern paradigms, or whatever. Just a language that cleans up some of the gotchas in C, improves the template system and maybe improves structs a little.

    The final point for me with C++ is that I really like multiple inheritance. C++ boned this up so much that every new language runs away from it without even considering that it is a solved problem and it has been done well before. So, we have all of these interface based languages now that cause a great deal of unneeded complexity and they don't even solve the problem of M.I. in the end anyway. I.e. the "diamond" problem is a semantic issue, not a semantic one. I hate C++ for this.

    I've never used Eiffel (though I've heard good things about it), so maybe I'm missing something here, but I've never encountered a problem where multiple inheritance (or indeed inheritance) was particularly useful. Delegation, interfaces and mixins have always been sufficient for me, and I find them a lot easier to reason about.

  • @brambos said:
    The biggest issue with Swift is that it is completely redundant. Objective-C does everything it needs to do; there was no need to introduce yet another language you can only realistically use on a single platform (lack of portability is bad enough in itself, but at least Objective-C mixes nicely with C when you want to minimize the amount of hard-to-port code).

    I mean you could say this about almost any programming language really.

    But I don't agree with this. It's a nice language, offers a lot of power (protocols, closures, option types baked in, different value types, write on copy handled for you, a good story for memory management) and should greatly improve programmer productivity. If you look at the SwiftUI stuff that Apple is working on it becomes clear why they're pushing this.

    Now we are stuck in an unfortunate situation where all tutorials and StackOverflow snippets need to be provided in two languages, or be useless to half of the community.

    I think this is a short term problem. Objective-C is clearly being sidelined at this point.

  • @moodscaper said:
    I beg to differ. Smalltalk pre-dates C++ as the first true fully OOPL in 1980 and was also the primary influence when Brad Cox developed Objective-C. Initially C++ was little more than C with classes, but it's moved on since then of course, often in mysterious ways...

    Technically it was Simula67 (1967!), but Smalltalk was the first mainstream OO language for sure. And is very nice. It's a shame that message based OO passing did not become the norm. I blame C++ and Java for that.

    C++ has the worst implementation of OOP that I can think of really.

  • edited December 2020

    @dendy said:

    @NeonSilicon
    Swift can't interface directly to C++ (yet). This is really because C++ sucks and isn't Swift's issue.

    strongly disagree... C++ is there for ages, and it is used everywhere where real performance optimisarion is needed... this is pure swift design flaw, it's just and only swift fault

    C++ is very deep and complex language and because of it's complexity it needs also very good skilled developer to utilise it's strentghtness and avoid it's weakness - but in hands of skilled dev it's powerfull tool... mother and faher of all object oriented languages

    btw still one of most requested and best payed language skills on job market ;)

    C++ is powerful and deep and a hack. It’s having accumulated a lot of power doesn’t make it a good approach. It is a sign of C++’s NOT being great that it requires experienced programmers to take advantage of its strengths. Sometimes poor solutions stick around because of precedence rather than because they are great solutions.

    C++ isn’t even close to being the mother and father of object-oriented languages.

    It came into being in the mid 1980’s in response to the development of object-oriented languages decades which whose descendants were starting to get traction so that programmers could do object-oriented programming without learning a new language. Object-oriented languages have existed since the late 50s or early 60s. Objective C came into being slightly before C++ but didn’t gain traction. So, C++ isn’t even the mother/father of Objective-C.

    C++ is an effective but cumbersome hack. Let’s not treat it as an elegant solution even if it is effective.

  • edited December 2020

    @brambos I agree that portability (and clunkiness of doing anything lower level... like withMemoryRebound or anything involving UnsafeMutablePointers) make Swift fall short of ideal. But as @cian and @NeonSilicon mentioned it's hardly redundant any more than any other modern language. Hopefully it will continue to evolve and address the various shortcomings. In terms of a language sanctioned by Apple for iOS development, Objective C is hardly a final and perfect choice. Swift's changes are mostly beneficial, and I believe they achieved a stable ABI recently. For the most part (especially for non-audio apps) Swift can speed up development and (in my opinion) has a nicer syntax. For anything it doesn't cover I can always fall back on C or C++.

    @NeonSilicon All fair points about C++. I'm always curious to hear people's experiences and preferred language constructs – I'll have to look into Eiffel and Sather. What's your favorite/ideal implementation of multiple inheritance?

  • edited December 2020

    @cian said: Technically it was Simula67 (1967!)

    Ah... I wondered if anyone would mention Simula :smile:

    From Smalltalk-80 The Language:

    Simula used the object/message metaphor only for the higher level interactions in the simulations it implemented

    So technically, it was not a fully object-oriented language, although of course, many internet sources now tell us otherwise. My memory of Smalltalk pre-dates the internet :smile:

    Object-based languages have been around for a long time, but it wasn't until Smalltalk-80 when everything was an object, even classes and methods are objects in Smalltalk-80.

    I think to a large degree, that pureness was also part of its downfall / lack of acceptance. Your average C programmer would look at Smalltalk and then say... um... OK, so how do I do a switch statement or a for / next loop over an array? :smile: As an old colleague used to say, their heads were still stuck in curly brace mode :smile:

    But yeah, Simula definitely got the ball rolling with the whole object / message thang.

  • edited December 2020

    @mercurialization said:
    As the second most-dreaded language, according to StackOverflow's Developer Survery 2020...

    This one always puzzles me. I'm an old school C programmer who learned OO with Delphi / Object Pascal and then moved on to C++ with all its gotcha's (copy constructors, anybody?). Objective-C was clean and easy to learn in comparison, and message passing (borrowed from Smalltalk) rather than method calling has some real advantages. Plus, as brambos said, you can freely mix straight C code in there for writing the critical time sensitive code.

    The tutorial at medium.com that TonalityApp posted is a pretty good one: it shows you how to code the majority of the AU in Swift.

  • So far, I understood that you need either Swift or Objective-C for the GUI of iOS / iPadOS Apps.
    And that Apple wants us to use Swift instead of Objective-C.

    But to include faster libraries (written in C or C++) in Swift Apps, you also need Objective-C to glue them together, which looks like this:

    Swift -> Objective-C -> C++
    or
    Swift -> Objective-C -> C++ -> C

    From what i read, Objective-C itself would be good enough to be used, while skipping Swift.
    Objective-C could sometimes even be used where Swift could not, without even the need to use C++ or C.

    But Swift seems to be the future, newer stuff may not be possible or well documented with Objective-C.

    But you could use pure C libraries directly from Swift, without the need for Objective-C:\

    Swift -> C

    Also, it seems possible to use Rust together with Swift, but this is not supported or possible within xcode, if i correctly understood:

    Swift -> Rust

    I would like to start programming for iOS / iPadOS (though not audio apps) and i have some (old) experience with C and C++ and also got interested in Rust.

    So I need to learn and use either Swift or Objective-C first.
    From what i read in this thread, Swift may be the better and more future-proof way, even if Objective-C may still be valid.

    And when need for faster libraries arises, implement them in C or Rust.
    As long as no existing C++ libraries are needed.

    But @brambos seems to recommend using Objective-C instead of Swift.
    True?

  • I don’t recommend Objective-C over Swift in general if you’re starting out now and don’t have a massive amount of existing Objrctive-C code on the shelf already.

    In the past Swift was not ready for AUv3 yet but I haven’t looked into it recently. I seem to recall Audiokit saying it’s still a challenge.

    For realtime safe/DSP I would definitely recommend plain C. If you intend to stay on Apple systems you can use the Accelerate library for SIMD/vectorized code without tying yourself to a single CPU architecture.

    But don’t listen to me. I’m not a developer and I have no background in programming. I’m just a designer who happens to know what a compiler is for.

Sign In or Register to comment.