More object-oriented music: modular synthesizers
I have now encountered three separate pieces of software that are designed in a "classical" object-oriented way and that let their users construct various kinds of musical instruments: the Nord G2 synthesizer, the Tassman software synthesizer, and the MAX/MSP music programming system. In my next few articles, I would like to talk about how this kind of software behaves, and why object-oriented architecture is particularly well suited to implementing it.
Before I begin, let me emphasize that this discussion is not intended to be a review or a critique of these products. Each one is designed with a different purpose, so direct comparisons between them are unlikely to shed much light. Moreover, as far as I know, each product is well respected in its field, and has been extensively reviewed by people who are much more skilled than I. My intent in these articles is to talk about how these products feel from the perspective of someone with a good deal of experience in object-oriented programming (a claim that I feel comfortable making at this point), with less emphasis on how they feel from a musician's viewpoint.
Object-oriented programming is about simulation. The whole idea of object-0riented programming started out with the Simula67 programming language (more than 40 years ago!) and the point of it was to define software objects that would capture some of the characteristics of physical objects so that one could use those software objects to write programs that behaved similarly to the physical objects. In order to understand the workings of the musical instruments that I am about to describe, then, it will be useful to know a little about the physical objects that they are intended to simulate.
The fundamental idea, especially for the G2 and Tassman products, is to simulate a modular synthesizer. You may not be aware of it, but most of you have probably encountered at least the sound of a modular synthesizer, because a Moog modular synthesizer was used to produce the enormously popular recording Switched-On Bach. Indeed, if you follow the last link above, you will see a picture of a Moog modular synthesizer in the background.
The fundamental idea is that a modular synthesizer is a musical instrument that consists of a number of modules that are connected (electrically) by patch cords. Each module has a particular purpose, and by interconnecting an appropriate collection of modules, you can create a musical instrument that suits your fancy.
Moog no longer makes modular synthesizers, but there are several companies that do. One of them, synthesizers.com, manufactures hardware synthesizer modules that are electrically compatible with the older Moog modules. I have not personally used their products, but as before I understand that they have a good reputation, so I am comfortable mentioning their products as examples of the kind of device I mean.
A typical use of synthesizer modules is to start with a module that is capable of generating sound. The most common such module is an oscillator. One then uses a patch cord to connect the output of this oscillator to a filter, which changes the sound's character, and thence to a voltage-controlled amplifier, which changes the sound's loudness over time (and in response to pressing and releasing keys on the instrument's keyboard) in response to a control signal generated by an envelope generator. The resulting signal, when amplified, gives the typical synthesizer sound. Put a bunch of these modules in a cabinet and you have a (hardware) synthesizer system that you can patch together to build a variety of different-sounding musical instruments.
What I intend to explore is why object-oriented programming is particularly suited to building software systems that behave like these synthesizers, as well as to give examples of how such modular synthesizers work in practice.
Stay tuned. So to speak.