I was working on a project and needed to allow the user to pick a sound to play when an event occurs. Even though OS X has great sound support it lacks a common GUI element for allowing users to pick a sound to play. Each program implements this in a different way, and most of the sample code I looked at didn’t meet my expectations. So I wrote this sound picker and example app to demonstrate how the picker can be used.
Playing Sounds
Playing a sound when a button is pressed is easy. In interface builder you drag the sound file from the media palette to the button. Whenever the button is pressed the sound will be played.
Why you would want a sound to be played every time a button is pressed is a bit of a mystery. I suppose it would make sense if you wanted to build a quick sound board, but other than that this feature is pretty limited.
To play the sound programatically the code is pretty straight forward.
NSSound *aSound = [NSSound soundNamed:@"Sosumi"]; [aSound play];
There are only two caveats. The first is that the sound name is case sensitive even though the file system may not be. The second is that they sound must either have been created and named earlier in the application, or the sound must be in one of the following folders:
~/Library/Sounds /Library/Sounds /Network/Library/Sounds /System/Library/Sounds
Three of those four folders don’t exist on a fresh install of OS X, and the one that does exist should never be edited lest it be overwritten on an upgrade or reinstall of the operating system.
Most users don’t know that they can add sounds by creating one of the 3 missing folders and filling it with aiff, wav, or mp3 files that can then be played as system sounds or accessed in dozens of applications.
An application that requires the user to navigate out to finder to make the folders and then move files into the folders and then come back to the application to select the newly added item, that isn’t a very good user experience.
Most applications also don’t automatically refresh when the user adds items to one of the sound folders. Tracking changes to folders is easier under Leopard then it ever was under previous versions of OS X, but is still a complex task. A quick look shows that System Preferences and iChat both require a quit and relaunch to recognize new sound files
Desired Features
For a good user experience with picking sounds I decided that four things were needed for my sound picker:
The User Interface
I mocked up an example user interface using Snapz Pro to take some screenshots of various user interface elements and then cleaned them up in Photoshop.
Drag and drop with copying
I envision a scenario where the user has downloaded a clip from a web page and wants to use it in my application. They should be able to drag the file from the downloads folders directly into the sound picker to use that sound, and the sound should continue to work even if they delete the original sound.
The well and file icon are there to visually cue the user that this is a place that might accept dragging and dropping of files.
Popup of system sounds
A list of system sounds, prebuilt sounds in my application, and sounds previously added to the sound picker should be nearby the drag and drop area. Within the popup they should be divided into sections, similar to what iChat does:
Per sound volume control
The user is more likely to have downloaded a sound then to have created it themselves. That means if they have more than one sound in the application they are likely to end up from different sources and have a variety of loudness. The sound picker should be able to set the volume on a per sound level.
Sound example
When a sound is set by either the popup or drag and drop, the user should get a sample of the sound, and be able to reproduce that sample if they want to hear it again. That is what the play button does over the sound image to make it clear that it is going to play the sound in the well. The button should not be there while accepting the drag, and should animate in after the drag.
The Developer Interface
The developer interface is as important as the user interface, because if it isn’t easy to develop with I’ll end up continuing to hard code sounds into my applications.
The drag and drop view, and the controller object should be an Interface Builder palette so that I can use it in many applications. It should have binding to make it possible to use something other than a NSPopupButton or Slider for setting the volume.
