MAX/MSP 3: Polyphony

[Ernest Meyer]

One of the great joys in modern digital music is the amazing possibilities with polyphony. My first hardware synthesizer was a WASP: an amazing little machine with a touch keyboard that cost less than $200, in 1979, from Oxford Synthesizer Company. It was of course monophonic. But I loved it so much I bought their big machine, an OSCAR, in 1987. It was $600 and sounded like a much more expensive machine, but could only manage a limited duophony. In 2001 I traded it in for a Waldorf Q. I was astonished by its 10 voices and loved weaking its knobs. But in a few short years computer technology made some amazing leaps and bounds, and now I can easily play 100 voices on my computer.

Why so many voices? One may think that a standard composition only has a couple dozen notes playing at once at any one time, so what's the point of more voices than notes? Well, as computer music has made leaps and bounds, the sounds which used to marvel have become old hat. The most difficult synthesis techniques are now within reach of teenage laptop garage bands. A couple of simple oscillators, even when playing wavetables, have difficulty reaching inspiring acoustic wonder any more.

Some of the best sounds in the modern world are built up by layering multiple sounds over each other, so that they interact with each other and add subtleties into the soundmix. For this, one note has to play many voices. My predecessor to Max/MSP, Reaktor, has excellent support for polyphony. From a hardware perspecitve, it makes use of wide instructions (MIMD), implemented by Intel as MMX, to increase processing speed on parallel instructions. This enables low CPU loads for increased polyphony. Reaktor was originally designed from the ground up to support polyphony. Any module can be changed between monophonic and polyphonic operation from its context menu. The modules indicate whether their selected operating mode with a color light in the module icon: black when non functional, red when monophonic, and yellow when polyphonic. Monophonic modules can always connect to polyphonic modules, in which case single values passed into them convert into multiple voices with the same value in the poplyphonic module. Reaktor also permits customization of each voice with a range of simple modules for converting between the monophonic and polyphonic domains the most frequent of which are "to voice", "from voice", and "voice combiner". Hovering over a wire in a polyphonic structure indicates all the values of all voices, which is very useful when debugging a complex instrument. Here's an example.

In the Reaktor world, I rapidly became very accustomed to moving signals between the monophonic and polyphonic domains for building up complex layers and vector-style processing. So when I started in Max/MSP, I assumed movement to polyphony could not be that difficult, and started building a monophonic sytnesizer for conversion to polyphony later. When I got to thinking about the polyphonic part, I looked around for examples of polyphonic synths in the maxobjects database, but did not find much; the only extensive polyphonic example on the Web was a tutorial on the Cycling 74 Web page. However, there had not been many synthesizers at all in the public database, so I assumed it was because people had just not shared their designs. One of the few synthesizers uploaded, from a profesor in Wales, implemented the MSP modules for polyphony, but only operated with one voice. I again assumed it was because it was designed for an old version and no longer worked in MAX/MSP 5, and carried on with my initial design.

Then I got to the conversin to polyphony, I was in for a shock. Rapidly, I learned what could be the main reason I had not found many polyphonic design examples. Probably there have been many others with the same experience as me. I assumed it would be easy converting my design to polyphony, and started arranging it carefully as I thought would be best. But when I got to adding polyphony, I was in for a surprise, and the information appears after many other long tutorials, so I did not work out the problem for some time.

In Max/MSP, polyphonic objects cannot be mixed with monophonic ones. They must be in a separate patcher. Ah, I thought, I can get past that. I can make the polyphonic patcher one of the objects in my main file.

But it didn't work. It caused my quite a bit of confusion in fact. When editing the patcher referred to by the "poly~" object, changes did not reflect immediately in the main design; I had to save the file first. After a while I realized that the patcher I was editing was being saved inside the parent patcher, and the polyphonic part was not in the same file at all; the polyphonic piece really has to be in a separate file. Then, when playing in polyphony, Max opens the separate file multiple times, one instance for each voice.

From a software perspective, this is a trivial implementation, but it imposes some real problems for my own designs. First, the multiple separate instances are very expensive computationally, as niceties like MMD processing are totally impossible. But moreover, it is very difficult to debug, as one needs to open the same file multiple times for each voice. When considering a design with 100 voices, this means 101 patcher instances! 101 files in a GUI environment? I cringe at the thought.

So it's back to the drawing board. Really, I had got used to using polyphony in Reaktor because Reaktor does it so well. But for many permutations in my designs, I was using polyphony as it was convenient, not necessary. Gradually, I'm working out how to convert the Reaktor structures with >256 voices into array-based data within one voice. Most of the processing is events (MSP patches in Max terminology), not audio, so theoretically it could be handled with vector processing within one voice. So the next real challenge will be looking at how Max supports large data structures and a much larger range of data types, which thankfully is much better in Max than Reaktor, and as I plan to examine, finally, in the next Blog. But meanwhile, I think with sadness how many others may have found, like me, that when they got to conversion to polyphony, they would have to throw out their design work and start all over again.