Background
The Max program, as it was released commercially in 1990 and existed for most of the ’90s, consisted of objects and messages, including some objects designed for the transmission, reception, and management of MIDI data, but it wasn’t capable of directly processing audio data. That capability had to wait till personal computers became faster, specifically until Apple introduced the Power PC chip in its Macintosh computers in the mid-’90s.
An audio processing extension of Max called MSP (Max Signal Processing) was introduced in 1997. In addition to the event-based and message-based paradigm of Max, MSP introduced new objects that use a special ‘signal’ message, which defines a network of audio processes that operate on the individual samples of audio signals stored in memory. That is, MSP objects that send or receive the message ‘signal’ are linked together to define an algorithm for constantly processing the thousands of numbers per second that describe an audio signal that can be played by the computer’s DAC or an attached audio interface. MSP objects are distinguished by the fact that their names all end with the tilde character ‘~’. (Like a sine wave, get it?) The patch cords that carry the ‘signal’ message are yellow-and-black striped, to distinguish them from ordinary Max patch cords that convey other, individual messages such as single numbers, lists of numbers, words like ‘start’ and ‘stop’, etc.
Normally, Max is sitting and waiting for an event such as a keystroke, a mouse click, or a MIDI message that will trigger messages to be passed from one object to another. MSP, however, is constantly computing the thousands of numbers per second necessary to produce a digital audio signal that can be played by the DAC. That represents a lot more work for the CPU, so you’re given the option to turn MSP on only when you need it. But given the power of modern CPUs, it’s not really that much of a burden for Max to compute audio, unless your program is making really extremely computationally-intensive demands. So there’s usually no reason you can’t just leave MSP on all the time.
Some more technical background info
What’s really happening when you turn MSP on?
One thing that happens when MSP is turned on is that Max sets up an arrangement with the computer’s operating system (Windows or Mac OS) to pass audio information back and forth. The operating system will take care of getting audio from the computer’s input jack and converting it into numbers with an analog-to-digital converter (and/or the computer will get numbers from an attached audio interface that does the analog-to-digital conversion task), and passing those numbers to any application that has said it needs audio input. The operating system also accepts numerical audio data from applications that are outputting it, and sends those to a digital-to-analog converter (DAC) for audible output by speakers.
For that to work, the Max application has (under the hood, where you don’t have to worry about it) special functionality called “callback” functions that communicate regularly (very often, in fact) with the operating system to arrange the passing of audio data. For Max to process incoming audio data in real time (that is, with no discernible delay), it needs to be receiving small amounts of new data constantly. Max gets data from the operating system in chunks of a few hundred numbers at a time—just a few milliseconds at a time—so that it can be constantly number-crunching with only a few milliseconds of delay. You can think of Max’s input callback function, then, like a virtual conveyor belt that brings a constant supply of new material for MSP to do its work. Max is constantly asking the operating system for more audio data, the operating system says “here ya go” and provides the most-recently-received numbers from the ADC, and that handoff repeats at regular intervals every few milliseconds.
In a comparable way, on the output end, the operating system is constantly needing more audio data for the DAC, and Max’s audio output callback function is constantly providing the latest data computed by MSP.
The other thing that happens when MSP is turned on is that every MSP object sends the message ‘signal’ out any outlet that is intended to produce audio signal. You can think of that as an information-gathering moment that permits Max to construct a “signal network”, a kind of a formula for all the operations it will need to do, and the order in which it will need to do them, to compute the desired audio. Another way to think of it is that Max is determining the signal path by which audio data should virtually flow from one object to another. In short, when MSP is turned on, the signal network is quickly compiled, the audio connections with the operating system are established, and the audio data computation (input and/or output) begins.
Each time you as a programmer change something about the MSP signal network, by adding or deleting a new MSP object or by changing patch cord connections between signal outlets and inlets, Max briefly turns audio off, recompiles the signal network, and turns audio processing back on.*
When to turn MSP on
In most applications that deal with audio, you as an end user don’t have to be very concerned at all with how the application is passing audio data back and forth with the operating system, how its callback functions work, and so on. That’s all taken care of by the programmers who wrote the application, and they hide any such concerns from the end user. The user should just need to indicate what s/he wants to do (play audio, for example) and it’s just supposed to happen. In Max, because it’s a programming environment (an application for programming other applications), you as a programmer need to be concerned with it at least to the extent of starting and stopping the entire audio computation process. Even so, if you’re writing an application to be used by other people, there’s no reason to bother them with such matters, so you should just set up the audio behind the scenes.
Because Max is a programming environment and a program-running environment at the same time, Max provides ways to turn MSP on and off, including even a couple of slick-looking user-interface objects for doing so: ezadc~ and ezdac~. But, IMHO, for the most part that’s not a task that the end user of a Max patch should need to deal with, so in most cases the starting and stopping of MSP should be automated and should take place behind the scenes of the user experience. There’s not really any compelling reason why MSP shouldn’t be on all the time if your Max patch is dealing with audio. By default, the Max application opens with MSP turned off. Therefore, if you’re making a patch that deals with audio, it’s usually best just to turn MSP on automatically when the patch is opened.
There are several ways to turn MSP on and off.
* There’s an option in Max’s application preferences, accessible by choosing Preferences… from the Max menu, called “Enable Mixer Crossfade”. If that option is turned on, Max actually keeps a duplicate copy of the old signal network before it compiles the new version of the signal network, and it continues to run the old network while it computes the new one. That avoids the noisy clicks that could occur due to recompiling the signal network while audio is playing, at the expense of some redundant work for the computer and some (very slight) delay because of the time necessary to crossfade between old and new signal chain.