Gregory Taylor

I've been thinking about The Material World recently.

Actually, I've been thinking about it by working my way through the recent series of Physics Patch o' the Day postings and doing things like turning gravity off and flinging things around the room that weigh nothing and watching what happens. And I think that the general happiness that comes with playing with some new thing in the Max universe is sweetened this time out by simultaneously being able to create patches that act like "the real world," and also doing things that are impossible. I can't think of the last time I had so much fun watching things bounce since I was a kid.

It got me thinking about one of those topics we don't talk much about in the Max universe, but which holds a similar fascination for me - physical modeling. So I thought I'd put together a primer that might assist others in discovering something new to enjoy.

Simply put, physical modeling generates audio by using mathematical models that attempt to describe the physical characteristics of the materials and the behavior of musical instruments in the real world. Those models are created by considering the form of the materials that make up the instrument (e.g. their shape, size, and material) along with functions that describe how a person or object interacts with the instrument over time (e.g. how the instrument is played by rubbing or striking or opening and closing tone holes).

While there’s a lot more that could be said about the technique and the interesting history involved in the development of physical modeling, that explanation will do fine for the purposes of introduction. I’ve provided a selection of reference readings at the end of this article that will exhaust and delight you, I hope (if you’d like a little more background right now, here’s a a basic introduction to physical modeling synthesis from Martin Russ, writing in Sound on Sound).

What's interesting about Physical Modeling

That's kind of a subjective question, but I'll try to answer it anyway. I think there are three things about physical modeling that I find interesting:

The process of describing the behavior of an instrument as a set of algorithms and constants lets us create versions of instruments that don't physically exist by extending the physical behavior we can model in new ways - the difference between a ukelele and a strummed bridge cable or a standard size koto and one 100 meters long is merely a matter of some thought and numerical substitution. While I can't afford a 13 foot Steinway with an insanely resonant soundboard tuned to the Just Intonational variant of the Javanese scales I like to work with, physical modeling makes it possible to have the instrument and play it.


The process of breaking a physical instrument down into a set of discrete behaviors lets us create new hybrid instruments that don't exist in the real world by decoupling those component parts that describe behavior and substituting different components - I can make guitars which are played by blowing on them or bowed saxophones.


I'll admit that the final answer is highly subjective, but I love what physical models sound like when they don't perform according to expectation. A part of that has to do with the fact that we're creating mathematical models that will accept numbers that bear no resemblance to how materials behave in the real world, where their behaviors would be constrained by physical things. In addition, the act of "playing" a physical instrument involves an impossibly complex set of behaviors that are easily controllable, while feeding an equation sets of numbers (particularly when those numbers describe systems that interact with each other in subtle ways) can produce results that would be impossible to actually do. For some people, that might make physical models "unreliable" or "difficult to play" (in fact, companies who make products based on physical modeling spend great amounts of time and effort on designing interfaces that are "playable" and predictable). To me, it's an opportunity.

Why This Primer? (the one-second-per-second theory of Max usage)

With that in mind, I wanted to talk about some of the options available to you as a Max user for exploring physical modeling synthesis. Since Max is a product that lets you connect things together to do an almost limitless list of things, there are all kinds of reasons for choosing Max to do something you like. In some cases, it’ll involve patching together various kinds of interfaces and applications and using Max’s message passing and processing abilities to create something unique. In some cases, Max provides the opportunity to reverse engineer your own version of something you’ve seen or are familiar with. In other cases, Max allows you the option of to explore ideas on a very low level in order to understand them better (and with the arrival of gen~, that’s never been more true than it is today. I'll say a little more about this later). Everyone’s got their own interests and agendas, and everyone faces the same constraints – the fact that all of us are aging at a rate of one second per second. Time is finite, and there are things to do and satisfaction to be gained. I see no shame in the intelligent shortcut, and encourage people who wish to find their joy by working things out for themselves at a low level to follow their bliss.

So instead of simply talking about building something in Max from scratch (as I’ve often done in the past), I’m going to talk about a variety of ways that you can integrate physical modeling synthesis into how you use Max – commercial plug-ins, third-party Max objects, and a stop along the way to praise the new gen~ features in Max. I hope I can provide you with some new things to investigate, and perhaps suggest solutions that you may already have to hand or tools that might make intuitive sense to you.

One of the simplest ways to investigate physical modeling synthesis with a minimum of initial effort involves making use of the current crop of third-party softsynths that are out there on the market. You can simply pop a plug-in into a vst~ object and send it standard MIDI messages or the Max messages (you can automatically construct a list of plug-in parameters on the fly and then address those parameters either by name or by number). It’s a great way to get started, and a relatively low-impact way to integrate the complexities of physical modeling synthesis into your rig (You’ll be constrained by the choices that the software’s original designers made in terms of control, but that’s the trade-off).

Modeled Instruments: There are several commercial products that present themselves as attempts to combine faithful physical models of acoustic instruments with well-designed user interfaces that allow you to both explore the parameters involved with physical modeling and to adjust/modify the physical parameters of the instrument to suit your purposes. In all these cases, the challenge for software engineers is to allow for parametric controls that map to real-life behavior (such as the stiffness of an electric piano tine or piano string length) in ways that are intuitive, even though the mathematical model encodes that “intuitive" behavior as a complex set of interactions. You might want to take a look at the front panel user interfaces and see how different programmers have approached the problem.

Applied Acoustics Systems’ Lounge Lizard Electric Piano and String Studio plug-ins,  Modart’s Pianoteq physically modeled piano, and Arturia’s Brass instrument modeling plug-ins are good examples of working to create what is primarily a faithful imitative model, and to add user interfaces that allow you to adjust/modify the physical parameters of the instrument. Although these products don’t strongly decouple the component parts of the physical model, they’re surprisingly flexible and usable.

Construction Sets: When it comes to a more modular approach to physical modeling, Applied Acoustics Systems has approached the construction of hybrid physical modeling synthesis with two different products: their Tassman modular construction kit, and the more recent Chromophone percussion synthesizer plug-in. If you’ve never tried them, you can download trial versions of the Tassman plug-in, and a demo of the Chromophone. Both of these products “decouple" instrument creation in precisely the way makes physical modeling so interesting, allowing for the creation of hybrid physically modeled instruments.

If you’re a Max for Live user and you own the Live Suite, you already have a trio of physical modeling instruments that are cousins of the Applied Acoustics Systems family of plug-ins: Tension (string synthesis), Electric (electric piano simulation), and Collision and Corpus (percussive/mallet synthesis). They can be modified or controlled as you would any other plug-in or rack device using Max for Live.

Reaktor: Native Instruments' Reaktor has a strong and vibrant user community who are actively engaged in the creation of new instruments. The addition of Reaktor Core technology has made it possible for users to work at a much lower level than the traditional Reaktor module, and that has resulted in the creation of some interesting physical modeling instruments. A fair number of these Reaktor instruments work with the relatively simple and straightforward Karplus-Strong algorithm in some form (ReZone, Accoustring, Twanger, Silverwood, Geetar and Whack it) – although there are some interesting excited tube instruments (Steam Pipe and Cathedral Flutes) and even the intriguing hybrid (Prepared Guitar) here and there.

All of these modules are available to you as a Max user if you host Reaktor using the vst~ object as you'd expect, but there is an additional feature that might make them of particular interest to you: the use of Reaktor Core technology means that you can pop the instrument open and have a look at the “code” for it – code which bears a resemblance to the Max patching environment. I know people who’ve used Core-level specifications as starting points when creating their own Max patches, and the level of detail might be helpful for those of you considering gen~ implementations. While not everyone would necessarily find this to be an obvious approach (and there really is no one-to-one mapping between the low-level Core modules and gen~), you might want to consider it.

As Max users, we spend most of our time as object and message wranglers - so much so that I suppose that most people who look at articles and tutorials and recipes on the Cycling '74 website just naturally assume we're going to spend all our time talking about what Max objects to use and how to teach them to play well with others. While I've tried to suggest that there's no harm in making use of Max's ability to host other people's software (and that there are interesting options available), that's not to say that you need to rely on them if you want to do anything with physical modeling in Max. There are a variety of ways to explore and use physical modeling synthesis in the realm of Max objects - collections of Max objects that implement physical models, and Max objects that host other programming languages that let us with with physical models in combination with the unique features of those languages.

PeRColate: Dan Trueman and Luke Dubois' PeRColate is probably the best known of the collections of physical modeling resources available to Max users. The set of objects is centered around a partial port of the the Synthesis Toolkit by Perry R. Cook (whose initials account for the capital letters in the name of the collection) and Gary Scavone, and includes physical modeling, modal, and PhISM class instruments. One of the great things that the helpfile patches provide in the PeRColate collection is a good working notion of what the finicky input value ranges for the physical models are, which is a great help as you explore the sounds you expect to hear, and the mutations that may delight you along the way.

Download the patch, a variation on the helpfile for the bowedbar~ object.


You'll need to install the PeRColate objects first, of course. Playing with the presets and moving the left fader should start to give you an idea of why physical models are finicky beasts, and what kinds of positively wonderful squeals they are capable of.

Finally, one great side effect of the PerRColate collection being open source is that you'll get a set of source code for those physical modeling implementations in C as part of the package. For example, that source code might prove invaluable if were a budding gen~ enthusiast in search of code examples to study [hint hint].

Download the PeRColate collection for the Macintosh and Olaf Matthes' Windows port of the objects

mlys/Modalys: It shouldn’t surprise you that our friends at IRCAM have spent considerable time and effort on physical modeling research. The results of that work appears in two forms that you can use in Max, both of which are involved with IRCAM’s Modalys synthesis engine. You’ve already heard about one of them, in fact – the Arturia Brass product has its origins in the Modalys engine (Here’s an interesting piece about the IRCAM/Arturia collaboration).

Max users can access to the Modalys engine using the mlys library of objects that can be patched together to build virtual instruments. The design of the objects won’t seem like a huge surprise now that you’re in the middle of this article – you patch mlys objects to combine various types of physical objects (plates or membranes of strings or tubes) with models of physical materials and other models for ways of exciting the models (striking, bowing, etc.). Here’s a short video that shows the mlys objects in action – using physical modeling to sonify some Max phys-objects in action:

Note: To access and use these objects, you’ll need to be a member of the IRCAM Forum, though (and yes, they do have student pricing).

rtcmix~: Another place where Perry Cook and Gary Scavone’s Synthesis Toolkit found a home of interest to Max users is Brad Garton’s port of the RTCmix music language to the Max rtcmix~ object. The physical modeling instruments in rtcmix~ are used like any other RTCmix instruments – by double-clicking on an rtcmix~ object to open it and pasting in a script that calls the necessary instrument (you’ll find that doing physical modeling via Csound in Max follows a similar procedure). Once loaded, you can activate and control your RTCmix instrument using standard Max messages. Using the rtcmix~ object gives you access to the full set of physical models available to RTCmix users. These include a wide variety of models that correspond to physical instruments from the Synthesis Tool Kit  (clarinet, bowed strings, brass, clarinets, flutes, modal bars, saxophones, shakers, and sitars), along with a couple of waveguides (a banded waveguide and a 2d mesh) and a Helmholtz resonator.

Csound: As with RTCmix, Max also allows you to host the Csound language by means of the third party csound~ object  In order to work, you'll also need to download and install Csound itself. (See links below.) The standard Csound distribution includes a number of physical model opcodes you can make use of. As with the PeRColate objects and the physical modeling in rtcmix~, Perry Cooks’s programming DNA is the source for a variety of the opcodes whose functions you’ll probably recognize by their opcode names (wgbow, wgbowedbar, wgbrass, wgclar, and wgflute). In addition, you’ll find some Karplus-Strong variations and waveguides (pluck, repluck, wgpluck, and wgpluck2), a simple waveguide (wguide1) and a beaten plate model (wguide2).

Download CsoundNote: In order to run the csound~ object, you'll need to install Csound on your system. 

gen~: The introduction of gen~ makes it computationally possible to create Max patches that work at the single-sample level withoug having to code them in C. For some users, that means that there are any number of new playgrounds, physical modeling being one of them. But it’s not been until the release of version 6.0.7 of Max that we started to see features being added that really made it possible to consider gen~ as a way to do physical modeling. When you think about it, a physical model is composed of pieces: the parameters and constants that represent the physical attributes of the instrument (physical dimensions and materials) together with a number of time-dependent functions that describe interactions with those materials.

Now that GenExpr (the internal language used by the gen family of objects) supports looping and branching constructs such as for/while/if...then, it’s easier to write code that does similar things lots of times and lets us save CPU by only evaluating expressions under specific conditions. And as you may have noticed if you’ve taken a look at any of the Synthesis Tool Kit’s source code, that’s a good thing to have.

In summary, each of these object varieties has their own advantages, from the relatively straightforward Max-like simplicity of the PeRColate or mlys objects to the possibilities that gen~ has begun to offer to those solutions that offer you the ability to leverage the advantages and features of the RTCmix or Csound programming environments. As before, feel free to try them out and work with the approach that makes the most sense to you.

While we may be living in a post-literate era when information has migrated from texts to persons who videoblog, and to aggregations of summary-oriented materials such as my good friend (and drinking buddy) Wikipedia, physical modeling remains one of those subjects that is sufficiently large and complex that books remain a great source of further information. Their benefit is greatly compounded by the tendency of the modern technical book to include CD-Roms or pointers to repositories of code and examples. Here are a few books beyond the Wikipedia pages I have found to be chock-full of useful information and source code-y goodness:

My first resort is always the black telephone-book thick  Computer Music Tutorial (MIT Press) by Curtis Roads, and this article is no exception to that rule. It remains the mother lode – the single book to which I have returned for enlightenment and introduction to a given topic in computer music more than anything else. In the case of particularly technical subjects, it’s generally the first thing I read to get the conceptual “lay or the land" before looking at the more specialized texts. In the case of physical modeling, I’m not sure I’d have had the courage to venture into any of the other texts here without having read Chapter 7 (Physical modeling and Formant Synthesis) of this book, full stop. I’m sorry it’s not available in its entirety online. I’m sorry it’s not an eBook, too. I know that nearly everyone in the world says this, but do yourself a favor – just buy it.


Perry R. Cook’s Real Sound Synthesis for Interactive Applications (A.K. Peters) provides a great introduction to physical modeling that’s long on good visual models of interaction and – somewhat uniquely for the books I’m listing here - includes a substantial body of and source code examples (which you could use as source material for a gen~ port [hint hint] and sound examples that demonstrate nearly everything in the book. The observable fact that Perry Cook and Gary Scavone's Synthesis Toolkit source code keeps showing up throughout this article should imply that having a look at this book is a good plan. Perry has some good advice for new readers: Read the last chapter (Examples, Systems and Applications) first – and listen to the accompanying audio, and then start at chapter one and start hacking around with the Synthesis Took Kit code that accompanies the text.


A little further along the continuum of mathematical rigor, you’ll find Julius O. Smith III’s seminal work Physical Audio Signal Processing for Virtual Musical Instruments and Audio Effects (available in hardcopy form through Createspace) insightful and useful. The mathematically inclined have been known to vanish into this book/website for weeks or months at a time, emerging glassy-eyed with a large sheaf of equations and mumbling, "My God. It’s full of stars…" over and over. If this book seems a bit daunting, here's a compact description of digital waveguide synthesis for the mathematically inclined.


One final booknote: Just in case you’re one of those people who reads about physical modeling and realizes that they perhaps don’t know as much about the physical part of the phrase physical modeling as you’d like, there’s hope for you, too, Nevile Fletcher and Thomas Rossing’s “The Physics of Musical Instruments" is the equivalent of Curtis Roads’ “Computer Music tutorial when it comes to gathering and combining huge quantities of information on many aspects of the physicality of musical instruments and putting that information together in one place. Since it’s currently out of print at Springer (the publisher), you’ve got two options if you want to lay your hands on a copy: pick up a used copy of the book, or browse the Google eBook version.


This concludes my overview of physical modeling and the resources available to you as a Max/Max4Live user. As is usually the case, I’m sure I’ve left several stones unturned, and may even have missed some fascinating contributions from Max users and Forum readers. Happily, these articles include space for response, where you can help me to fill in portions of the picture I might have missed. Thanks in advance, and happy patching.


This short video that shows the mlys objects in action -- using physical modeling to sonify some Max phys-objects in action. Find the tutorial here:

Physical Modelling Synthesis: Video accompanies tutorial

Explore many ways to try physical modeling synthesis in Max.

Search Results