MSP Sampling Tutorial 2: Playing Back From Multiple Sample Points

From Cycling '74 Wiki
Jump to: navigation, search

Click here to open the tutorial patch and files:

Part of the logic behind the way MSP works with samples is that multiple objects within a Max patcher can access the same sample memory of a single buffer~ object. This makes it quite easy to implement polyphony within a sampler playback patcher, as shown in this tutorial.

Loading a sample

Take a look at the tutorial patcher. As with the previous tutorial, this one uses a buffer~ object (named gerald, in this case), to store a sample that can be accessed by other objects. Rather than recording into the buffer~ we've instructed it to load in a sample (called "drums.aiff") when the patcher loads. The replace message to buffer~ differs from the read message in that it resizes the buffer~ object's memory to accomodate the entire soundfile being read; while in this tutorial this would make no difference, the two messages behave differently once you begin loading and unloading samples into the same buffer~ object.

  • Double-click the buffer~ object to view the contents of the sample called gerald.

Samplingchapter02a.png a sample called gerald

If we take a look at the loaded sample, we see that it seems to contain four sounds, equally spaced in time about a second apart. In this patcher, this sample is accessed by a series of three different play~ objects, all named after our buffer~ object... these three play~ objects are integrated into the patcher logic to play back different parts of the sample.

A simple drum machine

  • Turn on the audio by clicking the ezdac~ object and turn up the gain~ slider. Click on the button objects in the patch and listen to the results. These button objects trigger messages instructing the different play~ objects to access different parts of the buffer~ we've loaded. The four different ramps generated by the line~ objects each play a different one-second part of the buffer~. Because of the way we designed the audio file that the buffer~ has loaded, these sounds correspond to the four sounds we saw in the waveform display of the buffer~: four drum hits from a TR-808 drum machine... a bass drum, a snare drum, a closed hi-hat, and an open hi-hat.

Because all three of our play~ objects are capable of accessing the same buffer~ contents, they can be triggered simultaneously and create a polyphonic sound. The rest of the patcher logic simulates a very simple aleatoric drum machine, which uses random objects driven from a metro to trigger parts of the buffer~ based on the message boxes. The drum machine uses random objects to define a probability of a sound event for the bass drum (one chance in three), the snare (one chance in four), and the hi-hats (two chances in three, equally divided between the two sounds).

  • Click on the toggle box at the top of the patcher to start the metro. Once the drum machine starts going, notice that it's possible to hear a bass drum, a snare drum, and one of the hi-hat samples simultaneously, even though all three sounds live within the same buffer~. Notice that, because of the way we've constructed our patcher, it's impossible to hear an open and closed hi-hat at the same time; both of those sample triggers go to the same play~ object, which can only sound one 'voice' of our drum machine. As a result, they will interrupt one another if they trigger too quickly.


The MSP sampling architecture allows for any number of sample playback objects to access the contents of the same buffer~ object. As a result, you can use multiple play~ objects to simultaneously access sample data to create a polyphonic texture. Creating audio files that contain samples at regular time intervals makes it easy to set up "banks" of samples within a single file, accessible from MSP by reading at different points in a buffer~ sample.