OpenAL lets you play multiple sounds at once

This sound engine was written by Alex Restrepo under a creative commons attribution-share alike licence, so you are free to use it so long as you attribute the code to the author and if you change it and share it you must do so under the same license. I have corrected one small mistake (a semi-colon where it should not have been) and also edited the formatting of the code to my personal preference. You can get an Xcode example project that uses the sound engine here. If you just want the sound engine itself you can get it here. If you look at the example project you will see how easy this sound engine is to use. It provides simple methods for playing and managing background music and for playing sound effects on top. These classes use AVFoundation to play the background music and OpenAL to play other sounds on top. I am not informed enough about either of these to know what advantages or disadvantages this may offer but will look into it and possibly do a pure OpenAL version. To add the sound engine to your own project just add the class files included in SoundEngine.zip to your project. Also be sure to add the OpenAL.framework, AVFoundation.framework and the AudioToolbox.framework otherwise you will get a host of strange errors. You have the option of using the CMOpenALSoundManager as a singleton. If you do use it as a singleton (you can do this by setting USE_AS_SINGLETON to 1 at the top of CMOpenALSoundManager.h) you just need to initialize it somewhere in your code with:

[[CMOpenALSoundManager sharedCMOpenALSoundManager] init];

You also need to enumerate the tags for your sounds (ideally somewhere that every class that needs them will have access to them):

enum mySoundIds {
BUTTONSOUND1
        BUTTONSOUND2
        SUCCESSSOUND
        ERRORSOUND
};

You can then add your sound effects by passing an array of sound file names like so:

[CMOpenALSoundManager sharedCMOpenALSoundManager].soundFileNames = mySoundFileNamesArray;

To access your sound manager from anywhere in your project make sure you have included the CMOpenSoundManager header file and then reference the sound manager with:

[CMOpenALSoundManager sharedCMOpenALSoundManager]

Here is an example of playing some background music and then playing a sound effect:

[[CMOpenALSoundManager sharedCMOpenALSoundManager] playBackgroundMusic:@"backgroundLoop.m4a"];
[[CMOpenALSoundManager sharedCMOpenALSoundManager] playSoundWithID:BUTTONSOUND1];

One thing that I am not satisfied about with this system is the need for the enumeration. The reason being that you need to know which order the sounds are going to be loaded so that the correct sounds match the correct enum value. A better way in my opinion would be to use NSString keys, so that when you load a sound, you also pass a key. This is the approach taken in the code on the gethacktes.net blog, which is another great resource for OpenAL on the iPhone. Doing it this way allows you to lazy load sounds in any order. If I make that change I will be sure to post it here.

A fantastic resource for Cocoa, Objective-C and programming in general

The script called PropertyFromInstanceVariable had already been added to by a couple of other people, Yung-Luen Lan & Mike Schrag and Pierre Bernard and I have now shaped it for my own specific needs, and possibly yours too.

The tedium I was trying to eliminate was the process of creating Objective-C properties from instance variables and doing basic memory management on them. This is a repetitive process that seems more appropriate to hand off to the machine.

Matt’s script allows you to take an instance variable defined in your interface file and automatically create a property for it, synthesize the property in the implementation, add a release statement and set the property to NULL in the dealloc method.

For example, running the script on this:

NSString *myString;

would automatically create this in the interface:

@property (nonatomic, retain) NSString *myString;

this at the top of the implementation:

@synthesize myString;

and adds these two lines to the dealloc method:

[myString release];
myString = NULL;

Because this script was written before the viewDidUnload method had been added to the UIViewController class it didn’t make use of the viewDidUnload method. I wanted to update it to set the retaining references to subviews in the view hierarchy to nil. These reference properties may have been set through IBOutlets when loading a nib or programmatically in the loadView method.

I have now modified the script to reflect my own coding habits. It still creates the property, synthesizes it and adds a release to the dealloc method, but if the class is a subclass of UIViewController then this is placed in viewDidUnload like so:

self.myString = nil;

This script can be run on multiple instance variables at once and greatly cuts down on the time it takes to set up a new class. Instructions on installing the script can be found here.

You can get my fork of the script on github.

NOTE: I have updated to script and edited this post to reflect those changes. All links are to the most recent version.

Apparently some people don't like Objective-C

If you reference an object in your implementation that you declared in your header with @property and then used @synthesize in your implementation to automatically create getter and setter methods for the object, then using self.myObject  = newObject will call the setter and references to self.myObject will call the getter. As far as I know, if you are just referencing your object you don’t need to use the getter unless you are trying to distinguish from an object with the same name. When you assign your object however, the distinction becomes very important because everywhere you write:

self.myObject = newObject;

you are actually sending the message:

[self setMyObject:newObject];

which under the hood looks like:

objc_msgSend(self, @selector(setMyObject:), newObject);

The consequence of using self.myObject in this way is that myObject will use whatever retain property you set in the @property declaration. So if you set up myObject like so:

@property (nonatomic, retain) MyObjectClass *myObject;

then the value of myObject will be retained even after newObject has been deallocated.

If instead you had assigned myObject like this:

myObject = newObject;

then myObject is just the same as newObject. Therefore if newObject is deallocated then myObject will be pointing to a meaningless memory address. Probably not what you want.

So, here is an example:

.h file
...
UIView *myUIView;
...
@property (nonatomic, retain) UIView *myUIView;
...

.m file
...
@synthesize myUIView;
...
// Get frame:
CGRect applicationFrame = [[UIScreen mainScreen] applicationFrame];

// Set up myUIView:
UIView *tempUIView = [[UIView alloc] initWithFrame:applicationFrame];
tempUIView.backgroundColor = [UIColor blackColor];
self.myUIView = tempUIView;
[tempUIView release];
...

At this point in the code myUIView is now set up and ready to use. Because I used the setter to assign myUIView it is unaffected when I release tempUIView. If I had forgotten to use self.myUIView for the assignment then I would be unable to use myUIView later in the program.

Hope that clears things up for some of you. Please comment if I have something wrong or if you can help make things even clearer.