I thought I’d see if I could make the process just a little neater, and successfully devised a way to compile the images straight into the library, so the distribution remains nice and clean — just the library itself and a few header files.

Now, I can pop image resources into a folder, and after compiling, access them within the static library with:

UIImage *image = TPGetCompiledImage(@"Button.png");

It automatically handles “@2x” Retina images (although it doesn’t currently do “~ipad” versions).

Here’s how it’s done.

The magic is in a shell script which uses the xxd hex dump tool to create C code that represents the image data as a byte array, then creates around it a set of utilities to turn those arrays into UIImages on demand.

Along with it is a couple of template files — a header and implementation file — that describe the format of the derived code.

Finally, a little tweaking of the project in Xcode (with a brief foray into a text editor to work around some Xcode shortcomings) puts it all together.

Update: Fellow dev Cocoanetics pointed out that they’d solved a similar problem, and have a great write-up on how they create compiled resources using custom build rules on their blog.

The Image Resources

…Just a bunch of png files within a folder inside your project directory. The script assumes there are normal and retina (@2x) versions of each.

The Template

These are the template source files from which the end result will be derived. It contains a few tags that the accompanying shell script will process. I created it in Xcode, placing it within the same folder as the source png images, but removed it from the target’s compile phase, as we’ll be adding the derived source instead.

First the header, TPCompiledResources.h:

//
//  TPCompiledResources.h
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import <UIKit/UIKit.h>
 
UIImage *TPGetCompiledImage(NSString* name);

And the implementation file, TPCompiledResources.m:

//
//  TPCompiledResources.m
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import "TPCompiledResources.h"
 
/*{%IMAGEDATA START%}*/
/*{%IMAGEDATA END%}*/
 
UIImage *TPGetCompiledImage(NSString* name) {
    /*{%LOAD_TEMPLATE%}
    if ( [name isEqualToString:@"ORIGINAL_FILENAME"] ) {
        static UIImage *_SANITISED_FILENAME_image = nil;
        if ( _SANITISED_FILENAME_image ) return _SANITISED_FILENAME_image;
 
        if ( [[UIScreen mainScreen] scale] == 2.0 ) {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithCGImage:
                                                     [[UIImage imageWithData:[NSData dataWithBytesNoCopy:SANITISED_2X_FILENAME 
                                                                      length:SANITISED_2X_FILENAME_len freeWhenDone:NO]] CGImage] 
                                                                   scale:2.0 
                                                             orientation:UIImageOrientationUp];
        } else {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithData:[NSData dataWithBytesNoCopy:SANITISED_FILENAME 
                                                                                           length:SANITISED_FILENAME_len freeWhenDone:NO]];
        }
 
        return _SANITISED_FILENAME_image;
    }
    {%LOAD_TEMPLATE END%}*/
 
    /*{%IMAGELOADERS START%}*/
    /*{%IMAGELOADERS END%}*/
    return nil;
}

The Shell Script

Here’s the script that does all the work. The script looks for all “png” images in the given folder, then creates C code representing each image along with wrapper code to give access to the image byte arrays, with help from the template.

This script goes into a “Run Script” phase, placed at the beginning of the library’s build process.

#!/bin/sh
 
# Where the images are (get this from the first "Input Files" entry)
RESOURCES_FOLDER=`dirname "$SCRIPT_INPUT_FILE_0"`
 
# The name of the source template, minus extension
SOURCE_NAME="TPCompiledResources"
 
# Create C arrays, representing each image
tmp="$TEMP_FILES_DIR/compile-images-$$.tmp"
cd "$RESOURCES_FOLDER"
for image in *.png; do
    xxd -i "$image" >> $tmp.1
done
 
# Read the code template
TEMPLATE=`sed -n '/{%LOAD_TEMPLATE%}/,/{%LOAD_TEMPLATE END%}/ p' "$RESOURCES_FOLDER/$SOURCE_NAME.m" | sed '1 d;$ d'`
 
# Create loader code for each image
for image in *.png; do
    if echo "$image" | grep -q "@2x"; then continue; fi
    ORIGINAL_FILENAME="$image"
    SANITISED_FILENAME=`echo "$ORIGINAL_FILENAME" | sed 's/[^a-zA-Z0-9]/_/g'`
    SANITISED_2X_FILENAME=`echo "$SANITISED_FILENAME" | sed 's/_png/_2x_png/'`
    echo "$TEMPLATE" | sed "s/ORIGINAL_FILENAME/$ORIGINAL_FILENAME/g;s/SANITISED_FILENAME/$SANITISED_FILENAME/g;s/SANITISED_2X_FILENAME/$SANITISED_2X_FILENAME/g" >> $tmp.2
done
 
# Create the source file from the template and our generated code
sed "/{%IMAGEDATA START%}/ r $tmp.1
1,/{%IMAGEDATA START%}/!{/{%IMAGEDATA END%}/,/{%IMAGEDATA START%}/! d;}
/{%IMAGELOADERS START%}/ r $tmp.2
1,/{%IMAGELOADERS START%}/!{/{%IMAGELOADERS END%}/,/{%IMAGELOADERS START%]/! d;}" "$RESOURCES_FOLDER/$SOURCE_NAME.m" > "$DERIVED_FILE_DIR/$SOURCE_NAME.m"
 
# Copy the template header file in
cp "$RESOURCES_FOLDER/$SOURCE_NAME.h" "$DERIVED_FILE_DIR/$SOURCE_NAME.h"
 
rm "$tmp.1" "$tmp.2"

The “Run Script” phase that hosts this script also needs a couple of additions, to tell Xcode what the inputs and outputs to the script are: In the “Input Files” section, the path to the image resource folder, with a “*.png” wildcard at the end, and also the path to those template files, TPCompiledResources.{h,m}. Finally, the two output files go in the “Output Files” section:

Project Setup

Now it was just a matter of setting up the project to include the derived source files in the build. This was a bit messy and took a little doing, but with guidance from this article by Ben Zado on file references relative to DERIVED_FILE_DIR, it wasn’t too painful:

1. Build, in order to generate the derived source files.
2. Navigate to the derived sources folder within the build products, and drag the TPCompiledResources.{m,h} into the project, placed within a new group (I called the group “Derived Sources”).
3. The path type for those files (accessible from the properties viewer — Cmd-I) should be “Relative to Enclosing Group”, and consequently the “Path” field should just show the filename, with no path component. This was a bit touch-and-go for me, and I had a hard time making this happen, so I left it as-is for now, fixing it manually later in step 8.
4. Under Xcode Preferences » Locations » Source Trees, add an entry with setting name “DERIVED_FILE_DIR“, display name “Derived Files” and path “$(DERIVED_FILE_DIR)“.
5. Set the path type for the group containing the two derived sources to “Relative to Derived Files”.
6. Quit Xcode, and open the project.pbxproj file from within your project’s bundle.
7. Find the “Derived Sources” group (or whatever it was named in step 2), and delete the “path” property from the list of attributes.
8. I had to also find the TPCompiledResources.{m,h} file sections and delete the “path” attribute for those, too.
9. Reopen Xcode, and build — it should be good to go (don’t worry that the derived sources are shown in red in the project group — Xcode’ll find them).

Now that’s done, images can be accessed by TPGetCompiledImage(@"ImageName.png"). Yay!

Here’re two extensions I use to run PHP code (one which just executes it and shows the result in Growl, and one which copies the result to the clipboard), and an extension that runs a snippet of C code. Of course, it wouldn’t take much to make extensions for many other languages, too.

Execute PHP Code.alfredextension

Execute PHP Code, Copy Result.alfredextension

Run C code.alfredextension

In case the solution was useful to others, here’s how I worked around it: Use the preprocessor to rename the symbols automatically during the build phase.

This is done by adding a series of -DOldSymbol=NewSymbol flags to the ‘Other C Flags’ build setting – like -DTPCircularBuffer=ABCircularBuffer, for instance.

No more symbol conflicts.

iOS-Universal-Library-Template

The existing static library template provided with Xcode only builds one architecture, which is not particularly suitable for distribution. A number of people have created scripts to create universal libraries, which require some mucking around with Xcode target settings to use.

This template draws on this work to provide all that is required to produce universal libraries – just select the ‘Universal Static Library’ type in the New Project/New Target dialog, and you’re all set.

You’ll wanna edit the extension to put in your API key and Team ID, then just select a file in Alfred, type ‘testflight’ (or an abbreviation thereof) and enter, then enter a build summary, and off it goes. Result will appear in Growl.

Upload to TestFlight.alfredextension.zip

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.

If you’re interested to see what I’m up to, do join me over there.

Here’re some mockups of the main interface…

Subscribe here for more news about Audiobus as it happens.

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

We’ve dropped Loopy’s price for the holiday period!

Loopy HD, for iPad and iPhone, is 50% off at $3.99 (normally $7.99), and Loopy, for iPhone, is 30% off at $1.99 (normally $2.99).

Happy holidays!

Gift Loopy

Gift Loopy HD

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.

I’m excited to announce the release of Loopy 2.2, and Loopy HD 1.1, which introduce features that the professional and semi-professional musicians are going to love: Trainable MIDI control, and MIDI clock sync!

Loopy can now be entirely controlled via external MIDI devices, via the Camera Connection Kit for iPad, or any one of a number of third party adapters for the iPhone and iPod Touch.

With Loopy, musicians can now accomplish the kind of setup that would otherwise cost hundreds of dollars in expensive, bulky specialised equipment to achieve.

Controllable actions include record toggle, mute toggle, record then automatically select next track, record then overdub, toggle record with no count-in/out, clear, re-record, solo, volume, pan, tempo adjust or tempo tap, pause, double or halve clock length…

The update also introduces MIDI clock sync: The clock can be synchronised, in either direction, with external devices, other software (such as Ableton Live) over WiFi, software running on other iOS devices via WiFi or Bluetooth, and even other compatible apps running on the same iOS device, via virtual MIDI!

Oh, yeah – one more thing: Loopy on the iPhone or iPod Touch can now run up to 12 channels. Yep. Layer it up, baby.

Loopy user and forum member fonyo recently wrote an article on the Loopy forum about busking with low-budget equipment and Loopy. There was some great information in the article, so I’ve reproduced it here with some editorial modifications.

I’ve been planning for a long time to do some busking. I’ve always been amazed by street musicians, and can watch them for hours. That’s why I’ve put together some thoughts on buying portable equipment.

In summary: For just a fraction more money than that saved by choosing Loopy instead of a single Boss RC-300 Loop Station, you can pick up a complete, high-quality busking setup, perfect for going out into the street and performing for the public.

Boss RC-300 vs Loopy

First, let me compare the new Boss RC-300 Loop Station with Loopy, not counting the iPhone’s/iPad’s price (because we love it and would buy it anyway!). I chose the RC-300 as it gives you the closest number of individual loop tracks you can record/overdub

My point is this: let’s forget the RC-300 and save that 400 quid for other stuff to buy so we can go out and play!

Equipment list

Here’s my equipment list. I tried to find a balance between price and quality, while also keeping in mind portability.

Let’s see the details of each. Loopy is obvious, it’s the “core” in our iDevice and the iKlip is holding it (e.g. on a mic stand).

iRig guitar & instrument interface is transferring the sound to the iDevice.

iRig MIDI to control Loopy through MIDI (I know it’s not capable of doing this yet but soon it will be!) and we connect a nice MIDI foot switch (cheap and smart) the Behringer FCB1010. This is the only thing which needs a power supply but I’m listing it as I would go for it anyway. I’m sure now that iRig MIDI and LINE6 Mobilizer II are released we will soon find many battery-operated or maybe even passive foot-switches for iDevices through MIDI.

I’m sorry to disappoint you, but an electric condenser mic like the iRig iMic just won’t give you a nice sound, and as the tests and reviews are showing it’s just not suited for professional use such as live quality street busking.

That’s why I came up with an idea of a small but powerful battery-operated mixer with enough inputs to handle your better quality microphones. You can also plug in your instruments or any device with line out, such as an iPod as a music source.

The mixer device is the Behringer XENYX 1002B which runs on two (!) 9VDC batteries. The main output of the mixer (your gig) goes into the iRig’s TRS input. As a nice optional hardware for electric guitars with pickups, I recommend the MOTU ZBOX. It’s a miracle for guitar sound, and it’s passive so it doesn’t require any current. The Behringer 1002B has 5mic-line input OR 2mic-line/6stereo input with 3bandEQ, 2aux etc.

Finally, the Public Address (PA). I’ve found real luggage-like battery powered speakers made by PylePro and those are just wicked! Low-budget but nice stuff. They have wheels and handle for easy relocating, EQ, and many other cool things built-in. They give you enough power to blow away your own head with guitar riffs, beatbox, singing, so you can just use Loopy to amaze your audience! The iRig’s output goes in the PylePro’s input, and there we are.

You do need to buy a mic, but this way nearly anything will sound better than that electric condenser.

Summary

For the money you avoided spending on a Boss RC-300 LS for £400 (vs. Loopy 2 HD for £5), you can pick up nearly all this equipment — the sum is between 400-550 depending on where and what you buy or not. Then, you’re good to go and show some real busking to the public and start a career like our Uncle Dub Fx!

You can discuss fonyo’s research at the Loopy forum.