On Oct 29, 2012, at 8:58 AM, Jack Nutting < email@hidden> wrote: I agree with pretty much all of this, with maybe one exception: creating an audio graph. Setting up an audio graph requires a lot of really repetitive code. Depending on what you're doing, you may be able to abstract that into something reusable, and depending on your preferences using Objective-C to do that instead of C might be a good choice
That's an interesting and valid point. I've been doing a punitive amount of copy-and-paste coding in AUGraphs lately, largely owing to the fact that the effect units work with and will apparently only work with floating-point formats, while most other iOS audio units want ints, so I have to read the format from the effect unit and set that as a property on the input and output scopes of every other unit in the graph, or set up AUConverters to go into and out of float just for the sake of the effect. Pretty ugly, and there are likely ways to clean up that repetition, although I'm sure you could do it cleanly in C as well (e.g., a SetFormatThroughoutAUGraph() function).
Or just create a GUI builder for AUGraphs. Maybe that's the point of AULab and I've just missed it?
Speaking of cleaning up drudgery… in the book, we have that CheckError() function that logs a returned OSStatus if it's not noErr and then exit()s. This is just for teachability, and it's clearly totally unsuitable for production (you should never call exit() on iOS!). I mentioned in my Core Audio class at Cocoaconf this weekend that one of the classic problems in Core Audio is cleaning up state when you get an error. Say you've created an AUGraph, but creating one of your nodes fails and you have to bail out… it's a hassle figuring out what does and doesn't need to get cleaned up, and returning gracefully. The frequent use of "goto bail" in Apple's sample code is one of the places I point people to as a legitimate use of goto.
I've never had a great way to deal with this, but someone in the class made the comment that our CheckError() function could take, in addition to an error string, a block that would be executed in the failure case. In the block, a caller could include whatever code was necessary to clean up state at the specific point of failure. It's a neat idea, although I can also see it getting messy and copy-and-pastey if you have a bunch of CA calls in a row, each adding more things to clean up in a failure case. But it might merit some thought as a way to write a generic Core Audio "bail" function.
--Chris
P.S. Gratuitous plug: we're doing the all-day Core Audio class again at CocoaConf Raleigh next month. Haven't decided if I'll keep doing it in 2013, or if we've exhausted the market for people who'll pay for an all-day CA immersion. |