MSP Sampling Tutorial 2: Playing Back From Multiple Sample Points
From Cycling '74 Wiki
(Difference between revisions)
(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: [[ | + | 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.
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.
