Tag Archives: RAM
Playing a sample from RAM
Image
You can use the play~ object to play the contents of a buffer~, simply by sending it a ‘start’ message. By default it starts from the beginning of the buffer~. You can specify a different starting time, in milliseconds, as an argument to the ‘start’ message, or you can specify both a starting time and a stopping time (in ms) as two arguments to the ‘start’ message. In the patch, you can see two examples of the use of starttime and stoptime arguments. The message ‘start 0 420’ reads from time 0 to time 420 ms, then stops. You can cause reverse playback just by specifying a stop time that’s less than the start time; the message ‘start 2000 420’ starts at time 2000 ms and plays backward to time 420 ms and stops. In all of these cases — start with no arguments, start with one argument, or start with two arguments — play~ plays at normal speed. If you include a third argument in the ‘start’ message, that’s the amount of time you want play~ to take to get to its destination; in that way, you can cause play~ to play at a different rate, just by specifying an amount of time that’s not the same as the absolute difference between the starttime and stoptime arguments. For example, the message ‘start 1000 2000 1200’ means “play from time 1000 ms to time 2000 ms in 1200 ms.” Since that will cause the playback to take 6/5 as long as normal playback, the rate of playback will be 5/6 of normal, and thus will sound a minor third lower than normal. (The ratio between the 5th and 6th partials of the harmonic series is a pitch interval of a minor third.) The message ‘start 2000 1000 4000’ will read backward from 2000 ms to 1000 ms in 4000 ms, thus playing backward at 1/4 the original rate, causing extreme slowing and a pitch transposition of two octaves down.
The info~ object, when it receives a bang in its inlet, provides information about the contents of a buffer~ object. Since the buffer~ object sends a bang out its right outlet when it has finished a ‘read’ or ‘replace’ operation, we can use that bang to get information about the sound that has just been loaded in. In this example, we see the length of the buffer, in milliseconds. You can use that information in other parts of your patch.
Getting a sound sample from RAM
Image
The buffer~ object holds audio data in RAM as an array of 32-bit floating point numbers (floats). The fact that the sound is loaded into RAM, rather than read continuously off the hard drive as the sfplay~ object does, means that it can be accessed quickly and in various ways, for diverse audio effects (including normal playback).
Every buffer~ must have a unique name as its first argument; other objects can access the contents of the buffer~ just by referring to that name. The next (optional) arguments are the size of the buffer (stated in terms of the number of milliseconds of sound to be held there) and the number of channels (1 for mono, 2 for stereo). If those optional arguments are present, they will be used to limit the amount of sound that can be stored in that buffer~ when you load sound into the buffer~ from a file with the ‘read’ message. If those arguments are absent, when you load in a sound from a file with the ‘read’ message the buffer~ will be resized to to hold the entire file. The ‘replace’ message is like ‘read’ except that it will always resize the buffer~ regardless of the arguments.
The most basic way to use a buffer is simply to access each individual sample by incrementing through the array indices at the sample rate. To do that, the best objects to use are count~, which puts out a signal that increments by one for each sample, and index~, which refers to the buffer~’s contents by the sample index received from count~ and sends that out its outlet. This is good for basic playback with no speed change, or for when you want to access a particular sample within the buffer~.
When count~ receives a ‘bang’, it begins outputting an incrementing signal, starting from 0 by default. You can cause it to start counting from some other starting sample number by sending a number in its left inlet. (You can also cause it to count in a loop by giving it both a starting and ending number. It will count from the starting number up to one less than the ending number, then will loop back to the starting number.)