MSP Sampling Tutorial 2: Playing Back From Multiple Sample Points - Revision history

Gtaylor@rtqe.net at 16:15, 6 July 2012

2012-07-06T16:15:26Z

Gtaylor@rtqe.net at 16:04, 6 July 2012

2012-07-06T16:04:42Z

Gtaylor@rtqe.net at 16:04, 6 July 2012

2012-07-06T16:04:11Z

Gtaylor@rtqe.net at 15:36, 28 June 2012

2012-06-28T15:36:42Z

Admin: 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..."

2012-06-25T15:23:06Z

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..."

New page

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 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.

===Loading a sample===

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.

* Double-click the {{maxword|name=buffer~}} object to view the contents of the
sample called <code>gerald</code>.

[[Image:Samplingchapter02a.png|border]]
''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
{{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===

* 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.

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).

* 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.

===Summary===

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.

[[Category:Teaching Material]]

← Older revision		Revision as of 16:15, 6 July 2012
Line 1:		Line 1:
−	Click here to open the tutorial ~~patches~~: [[Media:02sPlayFromMultiplePoints.zip]]	+	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.

← Older revision		Revision as of 16:04, 6 July 2012
Line 1:		Line 1:
−	Click here to open the tutorial ~~patch~~: [[Media:02sPlayFromMultiplePoints.zip]]	+	Click here to open the tutorial patches: [[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.

← Older revision		Revision as of 16:04, 6 July 2012
Line 1:		Line 1:
−	Click here to open the tutorial patch: [[Media:~~02sPlayingFromMultiplePoints~~.~~maxpat~~]]	+	Click here to open the tutorial patch: [[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 1: / Line 1: @@
-Click here to open the tutorial patch: [[02sPlayingFromMultiplePoints.maxpat]]
+Click here to open the tutorial patch: [[Media:02sPlayingFromMultiplePoints.maxpat]]
 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===
-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===
-* 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===
-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]]