Timothy Place

The vocoder—the musical instrument that gave Kraftwerk its robotic sound—began as an early telecommunications device and a top-secret military encoding machine.

The Secret History of the Vocoder

In this tutorial series, we have created the heart of a vocoder using the MC system introduced in Max 8. The vocoder imbues a sound source (the carrier) with the drive of a second sound source (the exciter). We used MC to work with multiple channels of audio (e.g. 2 channels for stereo sound). Then within each channel, we used MC again to process each frequency band of audio for the two sources.

At the end of tutorial 3, we produced the patcher below, which is parameterized using Max for Live objects to make it easy to turn into a device.

In this patcher, and in this whole tutorial thus far, we've used a static "super saw" style synthesizer playing the note "A" for our carrier. While it isn't very dynamic or exciting it demonstrates the potential of the vocoder.

To take our vocoder to the next level, it is time to think about our options for better carrier signals.

This subject could easily fill a volume and is impossible to cover completely in this brief introduction. We will focus on two places to launch your journey...

Max comes bundled with hundreds of example patchers that provide both inspiration and a place to find models for your own work. Many people don't realize what an incredible treasure trove exists in these examples and it is definitely under explored. One of these fabulous examples is the "Classic Vocoder" patch. You can find it in the menu bar under the Help item.

All of the magic happens in the bpatcher above the ezdac~ object. Opening that patcher, taking it out of presentation mode, and unlocking it to edit, yields this:

The patcher uses send~ and receive~ rather than patch cords for the main audio, but it isn't too crazy to track down if we are patient:

The center section at the bottom is just for outputting lists to display a visualization. It doesn't actually impact the audio.

The area labeled "Excitation Source" is the synth for our carrier. That's what we are here for; we will come back to this in a moment.

The bank of 15 abstractions on the left that are labeled "classic-channel" are the heart of the vocoder. Each channel implements a bandpass filter both the carrier and for the exciter (it actually doubles the filters up to get narrower bands with better separation) and uses the avg~ object for the envelope follower.

Now that we have the lay of the land, we can steal the synth out of this vocoder and add it to our own with a quick copy and paste.

In this synth, zerox~ is used as a quick-and-dirty analysis of the input signal. More zero-crossings per period of time means higher frequencies, and really high frequencies are more likely with noisy sounds. An FFT or other analysis method could be more accurate, but this gets the job done and is computationally very light.

If the input signal is deemed to be noisy, then the synthesizer switches to become a noise source. Otherwise, it uses a rectangular wave from the train~ object. If a voice input is used, then the carrier tracks approximately with the human voice to produce noisy sounds for consonants and tones for vowels.

A second option with which we may wish to experiment is providing an external synthesizer that is not of our own making. There are lots of ways to patch this up in Max: bring in another adc~, instantiate an instrument plug-in with the vst~ object, or use a Max for Live synth in the amxd~ object. If we want to use our vocoder inside of Live, then we can get the carrier to come in as a sidechain input.

Here are the modifications to our patcher:

We added a plugin~ object to get 4 channels of audio from the Live application — the first two channels are the inputs from the track (which we're using for the excitation source), while inputs 3 and 4 are used for the sidechain inputs (for the carrier source).

We've replaced the ezdac~ object for an mc.plugout~ object. The mc.plugout~ object defaults to stereo on channels 1 and 2.

We've moved all of the interface objects into the upper-left region of the patcher window, which will be displayed in our Max for Live device in Live, and we have also selected all of the other objects and patch cords and selected Hide on Lock... from the Object menu to hide those objects when we lock our patch. (Note:  we could also have added the UI objects to the Presentation Layer of our patch, as well).

Then, to make it a Max for Live device, save it as a Project:

In the resulting Project window, you can export it as a Max for Live device:

Now you are ready to load your device into Live and provide any carrier you like; from clips, to the Wavetable Instrument, to anything else your heart desires.

In creating a basic vocoder, we've covered a lot of ground. We also have left a lot of ground uncovered. If you want some additional context and some ideas where you might take your vocoder explorations next, this video offers a great history and a number of examples:



I hope you've had as much fun following along as I've had in creating this series. As always, happy patching!

Learn More: See all the articles in this series  

vocoder_4.jpg

In the last tutorial of this series, I’ll take my vocoder to the next level by creating new options for carrier signals, and get my vocoder ready for Max for Live.

a-basic-vocoder-tutorial-part-4

A Basic Vocoder Tutorial, Part 4

The vocoder effect is everywhere — from the Sylvan Esso's recent release "Ferris Wheel" to more iconic appearances such as Phil Collins' 1981 "In The Air Tonight," Scritti Politti's "Boom! There She Was" or <insert your favorite Kraftwerk tune here>.

In this tutorial series, we're building a vocoder of our own, with the help of Max 8's MC (multichannel) capabilities. So far, we've looked at real-time analyzers (RTAs) as the heart of our vocoder, and used a pair of RTAs to create a mono vocoder. This time out, we'll create a stereo version of our vocoder and add a few new features. 

We have two sources for our vocoder: an excitation source and a carrier. In this example, we're using a drum loop as the excitation signal and a synthesizer for the carrier. 

Both signals are split into multiple frequency bands, and we use the amplitude envelope of each band of the exciter and apply that envelope to each corresponding band of the carrier.

Here is the basic vocoder patcher we created in Part 2 of this tutorial:

From Mono to Stereo - Making it Multi-Channel

So far, we have used Max's MC features as a way of passing multiple bands of audio between objects in our vocoder patch. In order to to create stereo (or multi-channel) version of our patch, we will want to make multiple copies of this vocoder — one for each channel of audio input to the vocoder.

In essence, we will wrap our MC patcher inside of another MC patcher. We can use the Max mc.poly~ object to do this. The magic of this object is that it allows us to process channels in parallel using multiple instances of a loaded patcher. This is exactly what we need!

The first step is to convert our vocoder patch into a re-usable Max abstraction. 

Since the mc.poly~ object is an MC version of the standard Max poly~ object, we can define the inlets and outlets of our abstractions just as we would with any abstraction loaded in a normal poly~ object — all of the same rules apply, and inlets and outlets are defined using the same in/in~ and out/out~ Max objects. The abstraction we're creating represents one channel (or voice) of the mc.poly~, so we can simply think of traditional mono inputs and outputs when we create our abstraction even though the wrapper is called mc.poly~.

Don't worry if you need to re-read that last paragraph a few times — it'll make sense when you think about it for a while, even if it seems challenging at first ("Wait, I thought I was in MC, shouldn't I use MC?"). It gets easier with time.

With that in mind, let's create the abstraction we're going to loaded by mc.poly~ Here it is, ready to go. We will call the abstraction "my.vocoder.voice~." It's worth taking a minute to study the patch and compare it to the original source:

The observant reader will note that we've made an addition to our previous patching — the section connected to the out 1 object and the bottom of the patch (When the abstraction is loaded, it becomes the second outlet of the mc.poly~ since the out~ 1 with the tilde character is the first outlet). 

This snippet of patching provides the ability to get the metering of the bands out of the mc.poly~ at control rate so that we can make a fancy visualization in the outside patcher.

The resulting  vocoder we get by loading our my.vocoder.voice~ abstraction into an mc.poly~ object  with an argument of 2 (stereo) now looks like this:

The mc.poly~ object is hosting multiple instances of the my.vocoder.voice~ abstraction - that's one instance for each channel of audio coming into the mc.poly~. In our example, we've used an argument to tell the mc.poly~ that we want 2 channels for stereo audio output. In fact, we could specify any number of channels we might want.

We can also change the number of channels dynamically... sort of. By setting the @voices attribute of mc.poly~ with a message box, we can change the number of channels it processes. But there is a gotcha: the change of voices for mc.poly~ will not take effect until we restart the DSP.

Changing the number of voices also means we would need to initialize the parameters of the new voices to match those of the existing voices (which can get a little messy with a larger number of channels). For the purposes of this tutorial, we will keep things simple and assume that the voice count is fixed at stereo.

We connected all of our parameters to inlets in our my.vocoder.voice~ abstraction. Those parameters are connected to user interface objects in the hosting patcher. In our example, you'll notice that we're using Max for Live UI objects (live.numbox and live.dial) instead of number boxes and dial objects. We're doing that for two reasons:

The parameters will be all ready do use if we want to convert our MSP patch to a Max for Live device

The Live UI objects work well with Max's Snapshot system.

The bands parameter changes the number of bands in the vocoder. The bands are represented as channels by MC inside of our abstraction. 

Just as it is with the number of channels feeding our mc.poly~, a change to the number of bands inside of the mc.poly~ will only take effect when the DSP is restarted — this means changing from 20 bands to 32 bands is possible, but you must also restart the DSP.

The bandwidth (BW) parameter changes how narrow or wide the filters are inside of the vocoder. At a value of 100% the filters have a Q-factor that produces a near-ideal crossover. 
Values greater than 100% will result in more signal getting through each of the filters, resulting in a higher overall gain of the output. 

Using values less than 100% will result in narrower filters and  a reduction in the overall gain of the output. We can compensate for this by using the live.gain~ slider to change the output gain.

We also need to ensure that all voices of the mc.poly~ are updated when parameters change — otherwise, one channel may change and the other be left with old settings. We'll use a b 1 (bangbang) object and a message box that sends a target 0 message to update all the parameters at once. This will muddy up the look of the patcher, but operate as we would expect the vocoder to behave.

Our patcher now looks like this after we've added these updates:

We have now successfully created a Multi-channel, Multi-band vocoder using MC inside of MC! 

If you want more practice, this same technique could be used to create a Multi-channel, Multi-band limiter with the content in the MC tab of the limi~ help patcher.

What remains to make our vocoder even more compelling? Interestingly, our next steps have very little to do with the heart of our vocoder patch itself. Instead it has everything to do with creating more compelling synthesizer/carrier input, and that's what we'll be looking in the final installment in this Vocoder tutorial series. 

image4.jpg

So far, we've patched a real-time analyzers (RTA) as the heart of our vocoder, and used a pair of them to create a mono vocoder. This time out, we'll move into multichannel territory and create a stereo version of our vocoder, and add a few new features. 

a-basic-vocoder-tutorial-part-3

A Basic Vocoder Tutorial, Part 3

Vocoders can be an insane amount of fun. 

In part 1 of this series, we created a real-time analyzer (RTA). We did this using MC — the multi-channel/multi-band/multi-voice patching paradigm introduced in Max 8. In this installment, we will use the real-time analyzer patch we created as the starting point for creating a vocoder effect.

Here is the real-time analyzer patcher we created in Part 1 of this tutorial:

Remember that our RTA is taking a channel of audio and splitting it into a number of bands based on frequency. This functionality is similar to an equalizer, except that we are just splitting the bands up to do metering as a visualization – we aren't actually altering the content of each band.

The patching on the right-hand side of the patch calculates the frequencies for the bandpass filters (shown in yellow) and the ideal Q-factor (shown in green). We then take these values and include the bandpass filter frequencies and the Q factor in the patcher on the left as messages sent to the mc.reson~ object. 

You can think of the mc.reson~ object as 20 traditional reson~ objects. In fact, it actually is 20 traditional reson~ objects — mc.reson~ is just a super-convenient wrapper for 20 reson~ objects.

What makes it  a real-time analyzer is the live.meter~ object connected to the output of mc.reson~.

As it turns out, beginning with Max 8.1, Max ships with an abstraction that does all of the calculations we covered in the first part of our Vocoder tutorial — it is called mc.bands~. If you would like to see the mc.bands~ abstraction in action, check out the MC tab of the limi~ help files. It contains a patch that demonstrates how to use MC to create a multi-band limiter.

If we use mc.bands~ in our real-time analyzer, the resulting patcher looks like this.

A vocoder works by taking the envelope (which is the volume level, roughly speaking) of each band of audio in one input signal called the exciter, and applying those volume levels to the corresponding bands of audio in another input signal called the carrier.

The classic example of this is using a voice as the exciter and a synthesizer as the carrier. The volume levels of the voice "excite" the same bands of audio in the carrier sound, which is a synthesizer. The result is that it sounds like the synthesizer is being played by the voice.

This is the reason we will need two copies of the mc.bands~ abstraction — we need one mc.bands~ abstraction to track the envelopes of the bands of audio in the exciter, and a second mc.bands~ abstraction for the carrier sound to which those envelopes will be applied.

The patcher below establishes the excitation source (the drum loop) and the carrier source (a synthesizer with fixed frequencies).

The synthesizer, in this case, is a quick and dirty "supersaw" sawtooth wave playing the note A. It does this using MC with the use of the mc.saw~ object. That object is a wrapper around 12 copies of the traditional saw~ object. Each instance has a different frequency: either A (55 hz or a multiple of 55 hz) or a slightly detuned version of A that is "off" by 1 or 2 hertz.

Both the synth (the carrier) and the drumloop (the exciter) are passed through their own copies of the mc.bands~ abstraction to split the audio up into frequency regions. 

To get the vocoder effect, we now need to combine them back together.

We have a number of options available to us to get the envelope of the bands of the drumloop (the exciter). One simple approach is to square the signal and then smooth the result. One side effect of squaring the signal (multiplying it by itself) is that all of the resultant samples will be positive —there will be no negative numbers. 

We then need to smooth the signal out, for which a filter like the MSP slide~ object is appropriate. As we've done throughout this tutorial, we will use mc.slide~ to wrap 20 slide~ objects. One for each band.

Each band of the carrier (the synth) then has its gain controlled by the envelope (the output of the mc.slide~ object) of the matching band in the exciter. We mix the bands back into a single channel, et voilà!

Because there can be some loss in this process, I like to put a limiter with a gain boost at the end to ensure the result is audible. The MSP limi~ object is the perfect fit for this task.

We do, in fact, now have an actual vocoder!

Things to try include experimenting with different excitation sources and different carrier sources. A lot of great vocoders in the world also tie the carrier to the exciter. For example, the carrier can morph between pure tones and noise depending upon what the exciter is doing.

In the next part of this series we will turn our modest mono vocoder into a stereo vocoder. We will also investigate how we might begin to parameterize the vocoder.

If you come up with something fun, please share your variation in the comments!

vocoder_patch.png

In the second part of this Vocoder tutorial, we will use the real-time analyzer patch we created in part 1 as the starting point for creating a vocoder effect using Max's MC multichannel voice patching paradigm.

a-basic-vocoder-tutorial-part-2

A Basic Vocoder Tutorial, Part 2

Vocoders can be an insane amount of fun. At the root of the vocoder effect we know and love, we take an audio signal such as a human voice and use it to excite the production of another sound, such as a synthesizer. In this classic case, you may get a robotic voice effect as a result. But don't stop there. The patient explorer will discover plenty of other creative applications.

In this series, we create a vocoder with Max using the MC objects introduced in Max 8.

Before we jump into the vocoder itself, let's talk about MC for a moment. Just what is MC?

While it's true that the name MC was inspired by the idea of patch cords being "multi-channel", there
are countless things you can do with MC that we might not traditionally consider as "channels". So
yes, in MC you can have one patchcord carrying both the left and right channels of a stereo signal.
And yes, in MC you can have one patchcord carrying 8 channels of audio from a 7.1 surround mix.
But you can also have one patchcord that carries each band of audio frequencies in a multi-band
compressor.

For the vocoder, we will use MC both as multi-channel in the classic sense (we will ultimately create a
stereo vocoder) but we will also use MC in the multi-band sense where each "channel" of the
patchcord represents a band of audio within the "channel". If that seems challenging to wrap your
head around, don't give up! The patching will bring it to life, I promise.

A real-time analyzer - or RTA -  is a device that displays the spectrum of an audio signal. You could think
of it as being like a graphic equalizer, but without the equalizer. Instead, it just displays what
frequencies are actually there in each band of audio.

Like an equalizer, an RTA typically divides the spectrum up logarithmically. That sounds all fancy and
mathy, but what it means is that the bands are spread across the domain in a way that sounds even
to the human ear. For example, each band might represent 1/3 of an octave over some number of
octaves. This is in contrast to the way the FFT works, which splits audio into bands but does so
linearly rather than logarithmically. The result is that the RTA, at least the way we will build it, will use
audio bands that are more "musical" than what is produced by the FFT.

(If you are interested in the FFT, be sure to check out the series I created on that subject)

The reason we are talking about the real-time analyzer is that our vocoder will be built from the
same building blocks as an RTA. In this first installment of the series, we will create an RTA. In part 2, we will take two RTAs and combine them to make a vocoder.

The first step to creating the RTA is to take our single audio signal and split it up into a series of
bands of audio. The basic bandpass filter in Max is called reson~, and it is the easiest tool to use for the job. Let's imagine that we want to split the signal into 20 bands. One way to do that is with 20 reson~ objects, each with a different frequency.

The first argument to reson~ is the gain, which is 1.0 for all of the filters, meaning there is no change or attenuation of the signal in the pass band of the filter. The second argument is the frequency, which is different for each filter. We will look at where those numbers came from later. The Q factor is always 7.628, which we will also look at later.

All of the filters are then summed at a pass~ object. This is my favorite way to sum signals together. Not only is the pass~ object the most computationally efficient object to use, but it also ensures that
if I later move this patcher into an abstraction, and then mute it using the mute~ object, that it will work as expected.

Patching together 20 reson~ filters like this isn't particularly complicated. On the other hand, it is a
pain to have to patch all of those filters together. It's even more of a pain if you want to change the
number of bands to say, 16. Or 32. Or any other number. You would, in fact, need to create entirely
separate patchers for each and every configuration!

Most audio objects in Max can be made to handle multiple channels by using the  mc. prefix on the object name. This is true of the reson~ object, which becomes mc.reson~ in the patcher below. We want 20 instances of the reson~ object, which means 20 channels of audio processing, so we add the @chans attribute to say so.

In this case, we use loadbang to set all of the gains 1.0 using the "setvalue" message. All of the Q
factors are set to 7.628 also using the "setvalue" message. We set the frequencies for all 20 filters
using the "applyvalues" message.

In MC, "setvalue" takes a list. The first number is the channel number / voice number / band number,
beginning at 1. If you specify channel/voice/band 0 then the value is applied to each and every
instance inside. In this case, there are 20 instances of a reson~ object inside.

The "applyvalues" works a little differently. Each value in the list is applied to the channel/voice/band
at each successive index in sequence. The result, in this case, is the first reson~ getting a frequency of 80 hertz, the second reson~ getting as frequency of roughly 104 hertz, and so on.

The patchcord coming out of mc.reson~ is both a different color than the signal patchcord coming in and also
wider. This is an MC patchcord and it is carrying 20 channels of audio!

The mc.mixdown~ takes those 20 channels of audio and produces another MC patchcord. This new
patchcord only has 1 channel of audio inside of it because the argument to 
mc.mixdown~ is 1.

The pass~ object is not an MC object. But all of the classic Max audio objects accept MC patchcords.
When they process audio they take the first audio channel only and then discard the rest. In this case
there is only one channel so nothing is lost.

All we need to visualize our 20 bands of audio is a live.meter~ object. Contrary to what I just said about classic Max audio objects discarding all but the first channel, some objects simply adapt to the MC patchcord that connects to them. This is mostly true of UI objects that have an audio input but no audio output.

So look at that! We have a working 20-band RTA!

The only problem now is that we are stuck with a bunch of frequencies and a Q-factor that we've
accepted on faith. What if we want to change the range of frequencies or the number of bands?
Magic isn't going to cut it. We need to be able to calculate those values for ourselves.

Let's say we want to figure out the frequencies for splitting up the audio between 80 hz and 12000 hz
into 20 bands. How could we do that? The uzi object can count from 1 to 20 to represent each
band. If we want to count from 0 to 19 (still 20 bands) then we could do so like this:

We can then map those numbers onto the range of frequencies from 80 hz to 12000 hz using the
scale object.

"Great," you say! But look closely... these numbers are not the same as the numbers we used earlier.
They aren't even close. That's because we used a linear mapping. To use the more musical "equal-
octave" logarithmic mapping, we have another trick to employ.

Here we use the ftom object to convert the frequencies into MIDI note numbers. Then we scale
across the MIDI note numbers linearly before converting back to frequencies using the mtof object.
That provides us with the perfect logarithmic curve without needing to think too hard about what
math is going on in there. Note that we need to add the floating-point argument to ensure that the
midi to frequency conversion is accurate and not rounded off.

The problem of the "magic" frequencies is solved! Now we just have that magic Q-factor of 7.628.
Where does that come from? How can we hope to calculate it ourselves?

The truth is that we could fudge the Q in many applications. Especially in a vocoder. Whatever the
ideal Q is, you may want to modify it for artistic or aesthetic reasons. The vocoder device in Ableton
Live has a bandwidth (or "BW") parameter that does exactly this.

In other applications, it is more crucial to know the ideal Q-factor and we'd like to understand it here
too. The ideal Q-factor is the Q-factor that results in any two adjacent filters crossing over at -3db.

(If you want to know more about filters and crossovers, I have a series on that too.)

The Q-factor is how steep the filter is. It is based on ratios so that it can apply equally regardless of
the actual frequency you are using in the spectrum. For simplicity, we can use the first 2 frequencies.
When we calculate the ideal Q-factor for those two filters then the same ideal Q-factor will hold for
the rest of the frequencies in the series.

The first two frequencies are 80 hz and 104 hz. The !- object does simple subtraction, it just reverses
the numbers before doing it. So the number box below it shows the result of 104-80 which is 24 hz.
That's the distance between these two filters.

The frequency where we want these two filters to cross over is half way between them. Half way
across this 24 hz chasm, is 12 hz. That means the crossover point is at 92 hz (80+12 or 104-12). So the
bandwidth of this filter is 12 hz and cutoff frequency where it hits -3db is 92hz.

Q-factor, however, is not raw bandwidth. It is a ratio of the bandwidth to the cutoff frequency. So we
divide the cutoff frequency (92hz) by the bandwidth (12hz) and we get our Q-factor of 7.628.

A Real-Time Analyzer is a great tool for visualizing the spectrum of your audio signals in a musically significant way. And it makes an excellent building-block for creating vocoder effects.

The basic concept of the RTA is simple: it's abunch of bandpass filters with audio meters at the end.
The challenging part is figuring out what frequencies to use and how to set the Q-factor. To do that
there is no avoiding some math, but there are ways to intuit the process and think about it in practical
terms. That's what we did here.

The other thing we did was leverage Max 8's MC features. With the tools we employed here, this
patcher can be easily modified to make an RTA of 16, 32, 128 or even 256 bands.

v3.png

Vocoders can be an insane amount of fun. At the root of the vocoder effect we know and love, we take an audio signal such as a human voice and use it to excite the production of another sound, such as a synthesizer. In this series, we create a vocoder with Max using the MC objects introduced in Max 8. We’ll start by creating a real-time analyzer.

Search Results