A Tasty Pixel

The Amazing Audio Engine 2 Sample App demo

Here’s a demo of the TAAE2 sample app – full source code with The Amazing Audio Engine 2.

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 at theamazingaudioengine.com, or on GitHub.

Beautifying code with Alfred

Here’s an Alfred workflow which will perform some prettifying code alignments in the currently-selected text when a hotkey is pressed. It works on instance and struct members, assignments and hey, maybe other things.

Yay, prettier code!

Perform Code Alignment.alfredworkflow

Here’s a video of it in action:

The Amazing Audio Engine is here, and it’s open source and Audiobus-ready

I’m very pleased to announce that The Amazing Audio Engine has pulled into the station. It’s been a long time in the making, and there have been one or two minor distractions along the way, but I’m proud of the result:

A sophisticated and feature-packed but very developer-friendly audio engine, bringing you the very best iOS audio has to offer. We’re talking audio units, block or object-based creation and processing, filter chains, recording and monitoring anything, multichannel input support, brilliant lock-free synchronization and rich Audiobus support.

You’ll find The Engine, a bunch of documentation and the brand-new community forum at theamazingaudioengine.com

It’s also open source. And it’s ready for Audiobus.

The Amazing Audio Engine: Funky Remote IO-based Core Audio Engine Coming Soon

Huzzah! I’m announcing a new project which will be launching over the next couple of months.

It’s called The Amazing Audio Engine, and it represents the product of years of experience with iOS audio. It’s a sophisticated iOS audio engine that lets developers skip the Core Audio learning curve, and get on with writing great software.

The tech behind this is what drives Loopy and Loopy HD, as well as the in-development Audiobus app.

Subscribe at theamazingaudioengine.com to be kept in the loop as it approaches launch time.

Some of the features:

Automatic mixing of multiple audio signals with per-channel volume and pan controls.
Built-in support for audio filtering and effects, including the ability to form complex filter chains, constructing channel groups, or even whole trees of groups, and filtering them as one composite signal.
Built-in support for audio input, including optional use of the Voice Processing IO unit, for automatic echo removal – great for VoIP.
Record or monitor the output of the whole audio system, for in-app session recording, or get the output of one channel, or any group of channels in the processing tree.
Support for any audio format (AudioStreamBasicDescription) that the hardware supports: Interleaved, non-interleaved, mono, stereo, 44.1kHz or any other supported sample rate, 16-bit, 8.24 fixed floating-point – whatever you need for your project.
Very light, efficient engine, designed from the ground up for speed. All Core Audio code is pure C; no Objective- C or BSD calls, no locks, no memory allocation.
Efficient mixing of input signals, using Apple’s MultiChannelMixer.
Fast, lock-free synchronisation mechanism, enabling developers to send messages to the main thread from the Core Audio context, and vice versa, without
locking or memory allocation from the Core Audio thread. Message sending from the main thread is two-way, and can be asynchronous, with a response
block, or synchronous.

Some updates to TPCircularBuffer

I’ve recently made some updates to TPCircularBuffer (on GitHub), my C circular/ring buffer implementation, which add a memory barrier on read and write, inline the main functions for a potential performance boost, and add support for use within C++ projects.

If you’re using TPCircularBuffer at all, I recommend updating!

Circular (ring) buffer plus neat virtual memory mapping trick

I’ve just updated my C circular buffer implementation, adopting the trick originally proposed by Philip Howard and adapted to Darwin by Kurt Revis: A virtual copy of the buffer is inserted directly after the end of the buffer, so that you can write past the end of the buffer, but have your writes automatically wrapped around to the start — no need to manually implement buffer wrapping logic.

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on GitHub: TPCircularBuffer.

There’s a basic example of its use over on the original post.

Seamlessly manage portrait and landscape view controller layouts

A headache-inducing scenario: I’m working on a view controller, and I realise that in order to support landscape and portrait modes, I’m going to need to provide two different layouts.

So, I create two different views within the nib, one portrait, one landscape, each with the same view hierarchy, but with a different layout.

When the orientation changes, I set self.view to the appropriate view. I initialise both views on load, and keep both of them synced to properly reflect the app’s state — basically, I’m double-handling everything, which bloats my code and increases the chance I’ll make a mistake.

So, here’s an easier way: Rather than maintaining two separate view hierarchies and switching between them when the orientation changes, why not just change the layout of one single view hierarchy? The only changes between the portrait and landscape views are layout changes, so if we can extract just the layout information from each view, then we don’t have to worry about maintaining both view hierarchies.

Basically, we’re talking about using each view version as a layout template only.

That’s what TPMultiLayoutViewController class does. It’s a drop-in UIViewController subclass that automatically manages switching between different view layouts for portrait and landscape orientations, without the need to maintain view state across two different view hierarchies.

It works by defining portraitView and landscapeView outlets which it traverses upon loading the nib. It matches each subview element to its counterpart in the other layout (based on tag, target/action, title, etc.), and stores just the layout attributes of each element.

Then, when the orientation changes, the view hierarchy is traversed and these layouts are applied to each subview.

To use it,

Set the superclass for your view controller to TPMultiLayoutViewController.
In Interface Builder, create two different views: one for portrait orientation, and one for landscape orientation.
Attach your portrait orientation root view to the “portraitView” outlet, and the landscape orientation root view to the “landscapeView” outlet.
Attach one of the views (whichever you prefer) to the “view” outlet, and connect any actions and outlets from that view.

Grab it from the TPMultiLayoutViewController GitHub repository, and let me know what you think.