Tag Archives: sfplay~

Preload and play sound cues

Image

 

A single sfplay~ object can refer to many different sound files, or even specific portions of sound files, with a unique “cue” number assigned to each sound. Once those sound cues have been preloaded (i.e. taught to the object), you can cause the object to play a cue just by sending the desired cue number in its left inlet.

The open message demonstrated in the Open a sound file and play it example can also be used with an argument naming a particular sound file, as in open myfile.aif. This preloads the sound file directly into cue number 1, without using a dialog box to let the user find the file, and subsequently sending the number 1 to sfplay~ will play that file. The message preload followed by a cue number, followed by the name of a file, as in preload 2 my2ndfile.aif, will preload the file and assign it cue number 2, and subsequently sending the number 2 to sfplay~ will play that file.

Note that when you ask Max to find a file for you automatically, Max has to know where to look for that file. How will it know? Read the discussion of Max’s file search path in the documentation.

In this example we use the loadbang object to set up some initial conditions in the program. This is an extremely common technique for setting up your program to function correctly and display the correct information when it’s first opened. Once the entire program has been loaded into RAM, the loadbang object sends out a bang message, which you can use to trigger the initial conditions and actions that you want. Here we use it to preload all the sound cues we want, and to start up MSP audio processing (i.e., to start generating audio signal) in this program. By so doing, we have taught sfplay~ its 8 sound cues, and we’ve started sending signal to the computer’s sound output. The signal is all 0 until we play a sound cue, but it’s on nevertheless, so we’re ready to go. Choosing a number other than 0 in the number box will now play the cue.

When the user closes the window, the closebang object will make sure that MSP is turned off with a stop message. This is maybe a good opportunity to discuss the difference between start and startwindow for dac~ and ezdac~. The start message turns on audio processing for the entire Max application, meaning that it’s on in all loaded patches. The startwindow message turns on audio processing only for the patch in which the dac~ or ezdac~ object resides, and any subpatches it may contain, but turns audio processing off in all other loaded patches. The stop message turns off all audio processing in all patches. When audio has been turned on in only one window with the startwindow message, audio in all other windows will be turned off, but if you then close the window in which the audio was turned on with startwindow, MSP will be turned back on in the other open windows. So, if you wish to avoid that, and truly have the audio processing be turned off everywhere once that window is closed, a good way to ensure it is to trigger a stop message with closebang, as in this example.

One other tidbit of information relevant to this example is that the comma character in a message box has a special meaning. It serves as a separator of messages. That allows you to include a whole sequence of messages in a single message box. When the message box is triggered (with either a mouse click or an incoming message), the messages are sent out and executed consecutively as fast as possible. So in this example, a single bang actually triggers an open message (to set up cue number 1) and seven preload messages (to set up cues 2 thru 8). If, for some reason, you actually want to send a message that contains a comma, you would have to precede it with a backslash, as in Hey\, how do you like that comma? The backslash is what’s called an “escape character” in programming; it’s a character that precedes another character to remove that character’s specialized meaning and just treat it as a neutral character.

Open a sound file and play it

Image

 

This shows an extremely bare-bones program for audio file playback.
1. Click on the speaker button (ezdac~ object) to turn audio on.
2. Click on the word “open” (message object) to open a dialog box that allows you to select a sound file. (In the dialog, select a WAVE or AIFF file and click Open.)
3. Click on the toggle object to start and stop playing. (The toggle alternately sends a “1” or “0” to the sfplay~ object, which sfplay~ interprets as “start” and “stop”.)

The sfplay~ box is an MSP object. It performs an audio task: it plays sound files from disk and sends the audio signal out its outlets. The number 2 after sfplay~ is an ‘argument’, giving the object some additional information: that it should play in stereo, and thus should have two audio signal outlets. (The third outlet will send a notifying message when the soundfile is done playing, but this program doesn’t use that outlet.) The speaker button (a.k.a. the ezdac~ object) is a ‘user interface object’. It allows the user to interact with the program (in this case, by clicking on it with a mouse) and it performs a task (to turn audio on and off, and to play whatever audio signals it receives in its inlets as long as audio is turned on). Notice that the patch cords between the outlets of sfplay~ and ezdac~ are yellow and striped; that indicates that what is being passed between those objects is audio signal. The open object is a ‘message box’. It’s a user interface object, too. When clicked upon, it sends the message it contains (in this case, the word ‘open’) out the outlet to some other object. This is a message that sfplay~ understands. (If it were not, sfplay~ would print an error message in the Max window when it received an unfamiliar message.) The plain black patch cord indicates that what is passed between these objects is a single message that happens at a specific instant in time rather than an ongoing stream of audio data. The words ‘start/stop’ and ‘audio on/off’ are called comments. They don’t do anything. They’re just labels to give some information.

Here are a few thoughts for you to investigate on your own.

If you wanted audio to be turned on automatically when the patch is opened, and/or the ‘Open File’ dialog box to be opened automatically, how would you make that happen? (Hint: See loadbang.)

If you want to cause something to happen when the file is done playing, how would you do that? (Hint: Read about the right outlet of sfplay~.)

If you wanted to play the file at a different speed than the original, how would you do that? (Hint: Read about the right inlet of sfplay~.)

A single sfplay~ object can only play one sound file at a time, but it can actually access a choice of several preloaded sound files. How can you make it do that? (Hint: Read about the preload message to sfplay~.)

Suppose you’d like to be able just to pause sfplay~ and then have it resume playing from the spot where it left off rather than start from the beginning of the sound file again. Is that possible? (Hint: Read about the pause andresume messages to splay~.)

What if you want to start playback from the computer keyboard instead of with the mouse? (Hint: See key — and/or keyup — and select.)

Suppose you want to have control over the loudness of the file playback. What mathematical operation corresponds to amplification (gain control)? (Hint: See *~. See also gain~.)

Playing a Sound File

Image

Open a sound file and play it.

 

This shows an extremely bare-bones program for audio file playback.
1. Click on the speaker button to turn audio on.
2. Click on the word “open” to open a dialog box that allows you to select a soundfile. (In the dialog, select a WAVE or AIFF file and click Open.)
3. Click on “1” to start playing (“0” to stop playing).

The sfplay~ box is a normal MSP object. It performs an audio task: it plays sound files from disk and sends the audio signal out its outlets. The number 2 after sfplay~ is an ‘argument’, giving the object some additional information: that it should play in stereo, and thus should have two audio signal outlets. (The third outlet will send a notifying message when the soundfile is done playing, but this program doesn’t use that outlet.) The speaker button (a.k.a. the ezdac~ object) is a ‘user interface object’. It allows the user to interact with the program (in this case, by clicking on it with a mouse) and it performs a task (to turn audio on and off, and to play whatever audio signals it receives in its inlets as long as audio is turned on). Notice that the patch cords between the outlets of sfplay~ and ezdac~ are yellow and striped; that indicates that what is being passed between those objects is audio signal. The open, 1, and 0 objects are ‘message boxes’. They are user interface objects, too. When clicked upon, they send the message they contain (in these cases, the word ‘open’ or the number 1 or 0) out the outlet to some other object. These messages are ones that sfplay~ understands. The plain black patch cord indicates that what is passed between these objects is a single message that happens at a specific instant in time rather than an ongoing stream of audio data. The words ‘start/stop’ and ‘audio on/off’ are called comments. They don’t do anything. They’re just labels to give some information.