Tag Archives: audio

sigmund~ for pitch tracking

Image

The sigmund~ object is a third-party object for pitch tracking designed by Miller Puckette and Ted Apel, available on their page of downloadable Max objects. You’ll need to have it installed for this example to work. Why is it called sigmund~? ‘Cause it’s your analyst, I assume! You might also want to have downloaded ducker~.maxpat from the previously posted example, so you can try it out in conjunction with sigmund~.

To have sigmund~ attempt to discern discrete notes rather than give a continuous pitch evaluation, use the ‘notes’ argument. Pitches are reported using MIDI-based numbering, but using float values to show fractions of semitones. In most cases, it works better to round those values rather than truncate them, for more accurate representation of the intended pitch.

ducker~ to suppress soft sounds

Image

A “ducker” is a system that turns a signal down to 0 when it’s below a given threshold. It’s useful for suppressing unwanted low-level audio, such as in a cell phone transmission when the user is not talking. Or, more to the point for musical purposes, as in a microphone signal when the musician is not playing.

In this patch the user specifies an amplitude threshold, attack time, and release time, either by sending those values in the appropriate inlets or by typing them in as arguments to the object in the main patch.

When the amplitude of the signal coming in the left inlet goes above the threshold, the >=~object sends out 1, so the rampsmooth~ object starts heading toward 1 in the number of samples specified (i.e., starts fading in the signal). So as not to lose too much of the wanted signal, that fade-in should be quick. A good attack time might be in the range of 5-40 ms, depending on the source. When the amplitude of the signal coming in the left inlet goes below the threshold, the >=~ object sends out 0, so the rampsmooth~ object starts heading toward 0 in the number of samples specified (i.e., starts fading out the signal). For many instruments, the release time might be slower than the attack time, so you might want that fade-out time to be longer than the fade-in time. A good release time might be in the range of 200 ms or more, depending on the source.  In the main patch you can use the mstosamps~ object to calculate the correct number of samples for the fade times.

Abstraction for mixing or crossfading two audio signals

Image

This patch is functionally identical to the mix~ abstraction in Example 1; you can read its explanation there. It’s repeated here in order to begin a series of examples regarding “initialization”: setting up the initial state of your program the way you want it. This patch demonstrates the use of a # argument in an object box to designate a value that can be specified in the parent patch when this patch is used as an abstraction (an object in some other patch). When this patch is used as an object in another patch by typing its filename into an object box, whatever is typed in as the first argument in that object box will be used in place of the #1, wherever it appears in this patch. (Subsequent arguments in the parent patch could be accessed with #2, #3, etc.) If nothing is typed in as an argument in the parent patch, the # arguments will be replaced by the integer value 0.

In this example, the #1 argument means that the initial crossfade value (to specify the balance between the audio signals coming in the first two inlets) can be typed into the object box in the parent patch. Notice that if the user does not type in any argument, the default behavior of this patch will be to send out only the audio signal of the left inlet, because the crossfade value will be 0 by default, resulting in a multiplier of 1 for audio signal 1 and a multiplier of 0 for audio signal 2.

[You can read a thorough explanation of the # argument in an excerpt from the Max 4 manual regarding the changeable arguments $ and #.]

An important thing to notice in this abstraction is that it has been constructed in such a way that the crossfade value coming in the rightmost inlet can be provided either as a float or as a control signal. If a person just wants to set a static crossfade value, a float is sufficient. It can be typed in as an argument and/or provided in the right inlet. For a dynamically changing value, though, a control signal is better. If, in the parent patch, a MSP signal is connected to the rightmost inlet of this patch, then any typed-in argument (and any float in the right inlet) will be ignored by the right inlets of the -~ and *~ objects in this patch.

Granulation of a recorded sound

Image

In classic granular synthesis, grains are very short windowed segments of sound, normally from 5 ms to 100 ms in length. A stream of sound grains be spaced at exactly the same time interval as the grain length, or at some greater interval of time. The spacing can even be randomized (some random time interval greater than or equal to the grain length). A single stream of grains is all you can do with a single groove~ object.

Although it’s not demonstrated here, you could have a multiplicity of such streams going with multiple groove~ objects, or with multiple instances in a poly~ object, which would result in some overlapping of grains, making a “cloud” of grains, and if it’s a dense enough cloud it starts to sound like one continuous sound.

This is an example patch that creates one steady stream of grains randomly chosen from a 10-second recording. You can set the grain length and the grain spacing to whatever timings you want. Here we use a 5 ms attack time and a 5 ms release time, so the minimum grain length in our case is 10 ms. Therefore, we limit the minimum grain spacing to 10 ms, too. (The number box setting the time interval for the metro object has had its minimum value set to 10 in the Inspector.) Each grain starts at a randomly-chosen start time in a 10-second buffer~. Each grain is also assigned a random loudness and a random panning. To make grains that are more like notes than grains, you can make grain lengths/spacings that are greater than 100 ms.