Presenting The Amazing Audio Engine 2
Presenting The Amazing Audio Engine 2: a new audio engine for Core Audio. In this video I introduce the main concepts, and walk through creating a simple demo app that plays a loop with effects, mixed together with audio input, with recording capabilities.
Find TAAE 2 on GitHub at https://github.com/TheAmazingAudioEngine/TAAE2
Comments
...And here's a demo of the sample app - source code available in the TAAE2 repository.
https://youtu.be/q9dcApliV-Y
Great work. Is there a specific section for TAAE2 discussions/comments in this forum?
Nice work! And no worries, you pronounced my name almost perfectly
Doubly amazing!! ... any chance you could upload your brain to github? I'd like to clone it...barring that, I'm going to try TAAE2 out right now.
Congrats!!
You never stop do you? XD
Does this mean float buffer processing will become something more just like a block based module?
(Also, totally thought you were the world fastest typist for a while there)
Look forward to take advantage of this in my apps! Any plans for making a sample code on how to integrate with AB (FX)?
Thank you very much! Lovely to see you here - RMSAudio's looking good, too!
Not so much - it's not really very high-volume, so I've not bothered with categories just yet.
Woo! Go me!
Your wish, my command. I give you: my brain
(I'm highly specialized)
=D
Not quite sure what you meant there - each module does indeed process float buffers (but it's a C function that does the actual work
)
Oh, but I am! Totally all realtime. Nope, I didn't spend 2 hours editing.
Probably, yeah - I need to write the programming guide at some point; that'll happen once it's a little more mature.
I split off the metering module discussion to: http://forum.theamazingaudioengine.com/discussion/1203/metering-module-for-taae2
This looks really cool -- thanks for continuing to use your powers for good
Any thoughts on the costs/benefits of using this versus TAAE1? Eg, if someone was about to begin a new app, should they go with 2 right away? Or if they were halfway through an app using 1, would it make sense to port to 2? Or 90% through, or 10%?
On a completely different note, would you say the new version is better suited to making AUX? I've been studiously ignoring that issue so far, partly because in the minimal poking around I've done I couldn't see a good way of reconciling my TAAE1 code with the AUv3 environment. (Admittedly that might just be me being stupid.) If TAAE2 made that easy it would by a massive boon to us all... (No pressure
)
Cheers
Hmm. I would say start with TAAE2 now - I'm going to be porting my apps to it in the very near term. A few things may change before we hit a 'stable' release, but nothing enormous, I'd say. TAAE1's days are numbered now, so were it me, I'd probably not start a project using it.
The benefits of a port kinda depend on how much would be involved in the process. While TAAE1 is going to be retired sooner or later, I'm not going to bail on all those folks with apps built on it, so it'll continue to get important bug fixes and such, should they arise. It's not going to drop off the face of the earth any time soon.
Indeed, I'd say TAAE2 does make AUX development easier
lol - that hamster is rather robust - flying out on its back like that!
I've updated the AEMeteringModule files but as I was testing them out it appears the example app has developed a few new bugs: the mic input doesn't seem to work anymore and when I plug in my headphones (with in-line mic) the app stops sending audio to the device speaker but it doesn't end up getting routed to the attached headphones. I tried this on the master branch rather than my hacked version of the example, and it behaves the same way.
I hope the heart of the engine will remain fairly backwards compatible for a while, as compared to the example project.
I am loving working with this engine - I don't know precisely why, but it seems more clear/easy to work with somehow... in fact its so easy to process audio it's going to be a temptation to go a little overboard with processing/cpu-load. It seems super flexible too.
Oh, that's weird @leothiessen! I just tried it here and it seems fine on my 6S Plus: I started it up, tapped the mic input icon to turn it red, recorded a second of audio and played it back to make sure it was working (it was), then plugged in headphones and monitoring started straight away. Unplugged, monitoring stopped, recorded and played back, still working. Can you gimme a repro sequence?
Very glad you're liking it! The stack architecture is a bit of a gamble, because it's fairly different to what's come before, but I've really enjoyed working with it too. Feels neater and more robust to me.
@Michael - Turns out it was my phone and a forced reset/reboot cleared it right up! I was just going to listen to an audiobook and headphones didn't work... Then it dawned on me... Sorry to bother you.
I'm curious why the architecture is a bit of a gamble - is that primarily due to it being "uncharted waters" so potential challenges remain to be discovered?
To me it feels more robust too - I was thinking that might be just because I find it easier to work with - leading hopefully to less programming errors.
Ah, good to know
It's a gamble because it's "new" (not a new concept, but probably new to most people). That means a bit of a learning curve, which could be problematic for some. That's partly the motivation behind my desire for a graph adapter, so you can - if you so desire - just provide a list of channels/filters and it'll do the rest. Personally, I prefer the stack, but it may not be for everyone, and the idea behind TAAE2 is flexibility.
Maybe you can do an Xcode plugin that lets you draw such graphs visually, a bit like Interface Builder? And drag the modules to outlets in the code for keeping references to them. But perhaps that would just make it all too easy, and people like us would get too much competition on the app store!
Yeah, no
I haven't found that:
TAAE2 works with iOS versions >= ?
For which versions will it be tested ?
thank you!
I haven't quite nailed this down yet, but it's almost certainly going to be iOS 8.3 and up. Maybe 8.0, but I'll need help testing
Hi there,
this is my first post, just wanted to say thatI recently got started with TAAE1 which I think is great! can't wait to get started with TAAE2 as well!
thanks!
Hi, Michael!
I was trying to follow your first example video and ran into a weird problem.
I'm getting a compiler error when trying to import the header file.
Also attached is my project structure. I suspect I didn't create the new project in the same place you did in the example.
While it is really cool the demo moves quickly, it's nearly impossible to see exactly all that's going on.
(No complaints, really. I'm very happy to see what's in TAAE2!)
Any ideas?
Thanks!!!!
I get this same error
I've tried this in four separate projects (to no avail).
I'm certain it has something to do with the search paths, but I'm clueless on where/how/what to set.
I noticed Michael was (for some reason) adding "build/Debug-iphoneos" to his header search paths.
Unfortunately, none of those directories are in my project, or the project on GitHub.
Here's the screen shot...
The TAESample project compiles and works.
I thought about structuring my test the same way, but it appeared to use libTheAmazingAudioEngine.a framework. I couldn't even find the file to copy!
Darn it.
(replied @ http://forum.theamazingaudioengine.com/discussion/1218/has-anyone-else-successfully-followed-along-the-taae2-video-with-success#latest)
Hi Michael & All,
First off, I've been a big admirer of your work with AudioBus and Loopy for some time. I have inherited a project that is still in Alpha - a small sequencer type of app. The original dev built it using AVAudioEngine + TPCircularBuffer (inside an AU), but I find it to be kind of limiting. My client is willing to move to TAAE, but we are trying to decide between TAAE1 and TAA2. I would prefer to use TAAE2, but since it is a commercial product, I am a little hesitant.
I know you answered these questions about a month ago, I was just wondering if the answers may have changed in the past month.
Thanks Michael, I appreciate any insight you can give us. We need to make a decision in the next couple of days. I am leaning towards TAAE2, but I figured I'd write in before taking the plunge.
Thanks Nigam!
Most likely over the next 2-3 weeks, I'd say. We're still in the process of refining some details, so I don't want to throw away any documentation work if there are any nontrivial changes - I think that's growing increasingly unlikely, though, so it should happen soon. Note that there's already extensive header documentation in place, but obviously that's only of limited utility without an overarching document.
Absolutely!
Very little, I suspect. Any changes I think will be fairly cosmetic, rather than structural.
Nope, on the contrary, TAAE2 is already much more capable than TAAE1. One minor exception is that TAAE2 interacts only minimally with AVAudioSession, whereas TAAE1 did all necessary interaction, but the actual requirements this places on developers using TAAE2 are quite minimal, and all visible within the sample app.
No problem!
At this stage, missing documentation notwithstanding, I'd probably recommend a new project be build around TAAE2; it's more robust than TAAE1's ageing codebase, and is being very actively developed, whereas TAAE1 is in a holding pattern. It does carry the risk of API changes (although I don't think these will be anything more than minimal) and beta bugs, but these should be ironed out quite fast. I'm building my new app around TAAE2 right now, too, so it's getting lots of exercise.