Click here to open the tutorial patch: 06sRecordPlayAIFFFiles.maxpat
You have already seen how to store sound in memory - in a buffer~ - by recording into it directly or by reading in a pre-recorded audio file. Once the sound is in memory, it can be accessed in a variety of ways with cycle~, lookup~, index~, play~, groove~, wave~, etc.
The main limitation of buffer~ for storing samples, of course, is the amount of unused RAM available on your computer. You can only store as much sound in memory as you have memory to hold it. For playing and recording very large amounts of audio data, it is more reasonable to use the hard disk for storage. But it takes more time to access the hard disk than to access RAM; therefore, even when playing from the hard disk, MSP still needs to create a small buffer to preload some of the sound into memory. That way, MSP can play the preloaded sound while it is getting more sound from the hard disk, without undue delay or discontinuities due to the time needed to access the disk.
MSP has objects for recording directly into, and playing directly from, an audio file: sfrecord~ and sfplay~. Recording an audio file is particularly easy, you just open a file, begin recording, and stop recording. (You don't even need to close the file; the sfrecord~ object takes care of that for you.) In the upper right corner of the Patcher window there is a patch for recording files.
be shown a Save As dialog box for naming your file. Navigate to the folder where you want to store the sound, name the file, and click Save. Turn audio on. Click on the toggle to begin recording; click on it again when you have finished.
In the left part of the tutorial patcher there is a patch for playing audio files. The basic usage of sfplay~ requires only a few objects, as shown in the following example. To play a file, you just have to open it and start sfplay~. The audio output of sfplay~ can be sent directly to dac~ or ezdac~, and/or anywhere else in MSP.
openmessage box marked ‘Set the current file’,
and open the audio file you have just recorded. Then (with audio on) click on the toggle marked ‘Play/Stop’ to hear your file.
Because sfplay~ does not need to load an entire audio file into
memory, you can actually have many files open in the same sfplay~ object,
and play any of them (or any portion of them) on cue. The most recently
opened file is considered by sfplay~ to be the ‘current’
file, and that is the file it will play when it receives the
openmessage boxes to open some other
audio files, and then click on the message box marked ‘Define cues, 2 to 9’.
preload message to sfplay~ specifies an entire file or a
portion of a file, and assigns it a cue number. From then on, every
time sfplay~ receives that number, it will play that cue. In the
example patch, cues
4 play entire files,
5 plays the first 270 milliseconds of sacre.aiff, and
so on. Cue
1 is always reserved for playing the current (most
recently opened) file, and cue
0 is reserved for stopping sfplay~.
Whenever sfplay~ receives a cue, it stops whatever it is playing
and immediately plays the new cue. (You can also send sfplay~
a queue of cues, by sending it a
list of numbers, and it
will play each cue in succession.) Each
preload message actually
creates a small buffer containing the audio data for the beginning of
the cue, so playback can start immediately upon receipt of the cue number.
Now that cues 0 through 9 are defined, you can play different audio excerpts by sending sfplay~ those numbers. The upper-left portion of the patch permits you to type those numbers directly from the computer keyboard.
to play the different pre- defined cues. Turn ‘Keyplay’ off when you are done.
Before you define a cue, you will probably need to listen to
segments of the file to determine the precise start and end times
you want. You can use the
seek message to hear any segment
of the current file.
the current file. In the right portion of this patch, enter an end time for
seek message. The excerpt you have specified will begin playing.
Try different start and end times.
Once you find start and end times you like, you could use them in
preload message to establish a cue. Because sfplay~
can't know in advance what excerpt it will be required to play in
response to a
seek message, it can't preload the excerpt.
There will be a slight delay while it accesses the hard disk before
it begins playing. For that reason,
seek is best used as an
auditioning tool; preloaded cues are better for performance
situations where immediate playback is more critical.
The patch in the lower right portion of the Patcher window demonstrates
the use of the right outlet of sfplay~. When a cue is done
playing (or when it is stopped with a
0 message), sfplay~
bang out the right outlet. In this example patch,
bang is used to trigger the next (randomly chosen) cue,
so sfplay~ effectively restarts itself when each cue is done.
Note the importance of the gate object in this patch. If it were
not present, there would be no way to stop sfplay~ because
0 cue would trigger another non-zero cue. The gate
must be closed before the
0 cue is sent to sfplay~.
For large and/or numerous audio samples, it is often better
to read the samples from the hard disk than to try to load
them all into RAM. The objects sfrecord~ and sfplay~
provide a simple way to record and play audio files to and from
the hard disk. The sfplay~ object can have many audio
files open at once. Using the
preload message, you
can pre-define ready cues for playing specific files or
sections of files. The
seek message to sfplay~ lets
you try different start and end points for a cue. When a cue is
done playing (or is stopped) sfplay~ sends a
out its right outlet. This
bang can be used to trigger
other processes, including sending sfplay~ its next cue.
sfplay~ - Play audio file from disk
sfrecord~ - Record to audio file on disk