Namespaces

Variants
Actions

MSP Sampling Tutorial 2: Playing Back From Multiple Sample Points

From Cycling '74 Wiki
(Difference between revisions)
Jump to: navigation, search
(Created page with "Click here to open the tutorial patch: 02sPlayingFromMultiplePoints.maxpat Part of the logic behind the way MSP works with samples is that multiple objects within a Max p...")
 
 
(3 intermediate revisions by one user not shown)
Line 1: Line 1:
Click here to open the tutorial patch: [[02sPlayingFromMultiplePoints.maxpat]]
+
Click here to open the tutorial patch and files: [[Media:02sPlayFromMultiplePoints.zip]]
  
 
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 {{maxword|name=buffer~}} object. This makes it quite easy to implement ''polyphony'' within a sampler playback patcher, as shown in this tutorial.
 
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 {{maxword|name=buffer~}} object. This makes it quite easy to implement ''polyphony'' within a sampler playback patcher, as shown in this tutorial.
Line 5: Line 5:
 
===Loading a sample===
 
===Loading a sample===
  
Take a look at the tutorial patcher. As with the previous tutorial,
+
Take a look at the tutorial patcher. As with the previous tutorial, this one uses a {{maxword|name=buffer~}} object (named <code>gerald</code>, in this case), to store a sample that can be accessed by other objects. Rather than recording into the {{maxword|name=buffer~}} we've instructed it to load in a sample (called "drums.aiff") when the patcher loads. The <code>replace</code> message to {{maxword|name=buffer~}} differs from the <code>read</code> message in that it ''resizes'' the {{maxword|name=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 {{maxword|name=buffer~}} object.
this one uses a {{maxword|name=buffer~}} object (named <code>gerald</code>, in this case),
+
to store a sample that can be accessed by other objects. Rather than
+
recording into the {{maxword|name=buffer~}} we've instructed it to load in
+
a sample (called "drums.aiff") when the patcher loads. The <code>replace</code>
+
message to {{maxword|name=buffer~}} differs from the <code>read</code> message in that
+
it ''resizes'' the {{maxword|name=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 {{maxword|name=buffer~}} object.
+
  
* Double-click the {{maxword|name=buffer~}} object to view the contents of the
+
* Double-click the {{maxword|name=buffer~}} object to view the contents of the sample called <code>gerald</code>.
sample called <code>gerald</code>.
+
  
[[Image:Samplingchapter02a.png|border]]
+
[[Image:Samplingchapter02a.png|border]] ''a sample called gerald''
''a sample called gerald''
+
  
If we take a look at the loaded sample, we see that it seems
+
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 {{maxword|name=play~}} objects, all named after our {{maxword|name=buffer~}} object... these three {{maxword|name=play~}} objects are integrated into the patcher logic to play back different parts of the sample.
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
+
{{maxword|name=play~}} objects, all named after our {{maxword|name=buffer~}} object...
+
these three {{maxword|name=play~}} objects are integrated into the patcher logic
+
to play back different parts of the sample.
+
  
 
===A simple drum machine===
 
===A simple drum machine===
  
* Turn on the audio by clicking the {{maxword|name=ezdac~}} object and turn up the {{maxword|name=gain~}}
+
* Turn on the audio by clicking the {{maxword|name=ezdac~}} object and turn up the {{maxword|name=gain~}} slider. Click on the {{maxword|name=button}} objects in the patch and listen to the results. These {{maxword|name=button}} objects trigger messages instructing the different {{maxword|name=play~}} objects to access different parts of the {{maxword|name=buffer~}} we've loaded. The four different ramps generated by the {{maxword|name=line~}} objects each play a different one-second part of the {{maxword|name=buffer~}}. Because of the way we designed the audio file that the {{maxword|name=buffer~}} has loaded, these sounds correspond to the four sounds we saw in the waveform display of the {{maxword|name=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.
slider. Click on the {{maxword|name=button}} objects in the patch and listen to
+
the results. These {{maxword|name=button}} objects trigger messages instructing
+
the different {{maxword|name=play~}} objects to access different parts of the
+
{{maxword|name=buffer~}} we've loaded. The four different ramps generated
+
by the {{maxword|name=line~}} objects each play a different one-second part of
+
the {{maxword|name=buffer~}}. Because of the way we designed the audio file that
+
the {{maxword|name=buffer~}} has loaded, these sounds correspond to the four sounds
+
we saw in the waveform display of the {{maxword|name=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 {{maxword|name=play~}} objects are capable of accessing
+
Because all three of our {{maxword|name=play~}} objects are capable of accessing the same {{maxword|name=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 {{maxword|name=random}} objects driven from a {{maxword|name=metro}} to trigger parts of the {{maxword|name=buffer~}} based on the <code>message</code> boxes. The drum machine uses {{maxword|name=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).
the same {{maxword|name=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 {{maxword|name=random}}
+
objects driven from a {{maxword|name=metro}} to trigger parts of the {{maxword|name=buffer~}}
+
based on the <code>message</code> boxes. The drum machine uses {{maxword|name=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 {{maxword|name=toggle}} box at the top of the patcher to start
+
* Click on the {{maxword|name=toggle}} box at the top of the patcher to start the {{maxword|name=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 {{maxword|name=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 {{maxword|name=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 {{maxword|name=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 {{maxword|name=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 {{maxword|name=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.
+
  
 
===Summary===
 
===Summary===
  
The MSP sampling architecture allows for any number of sample playback objects to  
+
The MSP sampling architecture allows for any number of sample playback objects to access the contents of the same {{maxword|name=buffer~}} object. As a result, you can use multiple {{maxword|name=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 {{maxword|name=buffer~}} sample.
access the contents of the same {{maxword|name=buffer~}} object. As a result, you  
+
can use multiple {{maxword|name=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 {{maxword|name=buffer~}} sample.
+
  
 
[[Category:Teaching Material]]
 
[[Category:Teaching Material]]

Latest revision as of 16:15, 6 July 2012

Click here to open the tutorial patch and files: Media:02sPlayFromMultiplePoints.zip

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.

[edit] 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.

[edit] 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.

[edit] Summary

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.