Design patterns


in Max?


The term design patterns has its origin in the field of object oriented programming. They describe general reusable solutions to standard problems, first in the field of architecture, then in the early eighties of the last century in software design. They are not connected to a specific programming language, however the desription of many patterns uses features of languages like Java or Objective C, particularly in creating objects dynamical during the runtime of a program. Max is more or less static in this case (scripting with thiswindow is not really useful in this context, maybe with JavaScript).
In our context it is not necessary or possible to transfer each known design pattern to Max, but following some of them makes the life much easier. Particularly the Model-View-Controller pattern is quite all-purpose and usable in Max.
The Model-View-Controller pattern divides a task into three sections:
  • The model is the part of the program which does the work. Its data is read from the
  • View. The view displays the inner state of the model and has e.g. sliders and number boxes for user interaction.
  • The controller finally the part which glues the other two parts together. It takes data from the model and sends it to the view, and vice versa, plus it can do more things. In our case tLb.FXController also takes care of saving and restoring the model parameters to and from disk.

Here is an example: nearly every demo of MaxMSP patchers shows things like this:
Don't do it in this way. Here the model – the sine oscillator – is glued together with the user interface – the number boxes. This makes it difficult to re-use e.g. just the oscillator in a different context without additional work on the interface. Maybe you don't need an interface at all, maybe you need a lot of oscillators but not the number boxes for all of them. The patch on the left is a very simple example. Consider you worked on a more complicated patch, like ReKonstrukt from LSD. Wouldn't it be great to use the same patch for Max for Live without much additional work? All you have to do is design a new user interface, the core patch itself remains untouched. Therefore, a much better way to start a patcher is using the Model-View-Controller design pattern and create this with the help of the pattr-system which is shown in the next picture.
Instead of connecting user interface objects to the signal generating objects, pattr objects are used. This methods frees the model from the user interface and you can drop it into every part of your patch wherever you want to. Note the additional pattrmarker which makes it easy to find the model in the jungle of other patchers.
This leads to the introduction of the probably most underestimated object family in MaxMSP – the system build around pattrstorage. More on this on the next page.