K509 — Computer Music Seminar: Assignment 9

Assignment 9: Amplitude and Pitch Tracking

You can analyze the amplitude and pitch of audio, either live or played from sound files, and use the resulting data to influence the audio generated by the computer or to trigger events. This kind of analysis is frequently known as amplitude or pitch tracking.

When you analyze the amplitude of an audio signal, you look at all the individual sample points that flow by at the sampling rate. The sample point that has the highest absolute value within a particular span of time is the peak amplitude for that span of time. Looking for the peak amplitudes drawn from short (e.g., 50 millisecond) contiguous time spans turns out to be a good way of tracking, or following, the envelope of a sound. In Max, we can do this with the peakamp~ object.

To track pitch, we can use the sigmund~ object. This doesn’t come with Max5, so you have to download it and either install it or keep it in the same folder as your patches that use it. The sigmund~ object emits a continuously varying pitch and amplitude estimate for an input signal. The signal needs to be a clear, monophonic melodic source, like someone singing into a microphone with no additional processing. The pitch estimate can be used to do many different things. Simple examples include doubling or harmonizing a vocal with a synthetic line, or triggering a sound when the vocalist sings a middle C.

Download the example patches for this assignment.
Play around with the “amptrack” patch, until you understand how it works. When the peak amplitude of the input sound exceeds a threshold, then the > object outputs a 1; when the peak falls below the threshold, > outputs a 0. The togedge object sends a bang out its left outlet when it detects a transition from 0 to 1. So every time the peak amplitude rises above the threshold, we get a bang from togedge and use this to play a MIDI drum note. You have to tune the threshold carefully for this to work.
(There is a more complex, but better, way to handle the threshold logic. You can see this at work in the “bliptrig” folder in the MSP Quickstart tutorials.)
Make a patch that works like the “amptrack” patch, but instead of triggering a MIDI note, make it trigger an audio event of your choice (such as playing back a sound file).
Suggestions...
- Most likely, you will need to use the bang sent by togedge to trigger an envelope.
- You could also try scaling the peakamp~ output and using it to control the pitch of an oscillator. (This would require some data smoothing, which you could do by feeding values from peakamp~ (perhaps through speedlim) to line~, to create ramps between successive amplitude estimates. Run the amplitudes through a message box containing “$1 100” on their way to line~. 100 is the glide time.
Study the “pitchtrack” patch, and see how the pitch estimate responds to different kinds of input signals. The left outlet of sigmund~ is a MIDI note number, but with a fractional component. Rounding this number to its nearest integer is optional. In the example patch, the pitch estimate is used to control the pitch of a square wave oscillator that doubles the input sound. The result is pretty glitchy, sometimes in an interesting way. You could control this better by using a split object to exclude MIDI pitch numbers that are obviously out of range, as can happen with unvoiced sounds from a vocalist, silence, or notes that are too low to be tracked.
Make a patch that uses sigmund~ to track the pitch of an input source. When the pitch falls within a certain narrow range, use that as a trigger to play a sound.
Suggestions...
- Be sure to copy the “sigmund~.mxo” file from the “assign9-examples” folder into the same folder as your patch. Otherwise, sigmund~ won’t work.
- You can use split to decide whether the pitch estimate is in range.
- Send the two split outlets into the two inlets of a onebang object (left outlet to left inlet, and right to right).
  When onebang receives a number or bang in its left inlet, it sends a bang out its left outlet only if it last received a bang in its right inlet. Then it doesn’t send any more bangs out its left outlet until it first gets another in its right inlet. In our application, the result is that when several consecutive pitches fall within the range specified in your split object, the onebang object sends a bang out its left inlet for the first in-range note, but not for subsequent ones, preventing unwanted multiple triggers.
  You should give onebang an argument of 1, so that it will send a bang if the first message it receives happens to arrive at its left inlet.