The pattr system


The pattr system was introduced in Max 4, but unfortunately not very well documented, so most people were just a little bit confused and used further on colls to save patch data and send/receive for message passing between patchers.
In Max 5 it become much more powerful. Its main purposes are:
  • saving and recalling patcher states
  • storing and reading patcher states to and from disk
  • propagating patcher states from one part of the patcher to others.
The latter is probably mostly unknown, but with its help it is possible to implement specific design patterns in Max. Here is how to make the Model-View-Controller pattern:
First look at the sine oscillator from the previous page.
We added the pattr and a pattrmarker and removed all number boxes etc. from the patch.
The first new thing in Max 5 is that you can tell pattr which type of data it should store and what the initial value should be. This is done in the pattr inspector window.
You see, since it holds a frequency, its type is set to float32 and the attribute is frozen. If you forget this and you reopen your patch the next time, this setting would be gone.
Then the initial value is also set, here to a value of 440. The rest of the attributes are left on their default values.
Now lets continue with the view. Above was said that pattr can be also used for communication purposes. This is where the mysterious pattrmarker comes into the play. It helps to create a base address under which the pattrs of a given patcher can be found.
Look at the screenshot to the right. You see the former number boxes, but they are now connected to pattrs, too. Inside the pattrs are strange @bindto attributes. These attributes constitute the communication between the two patcher windows. The syntax is ::pattrmarkerName::pattrNameInsideTheWindow.
The upper pattr is now connected with the pattr freq in sineosc, which controls the frequency of the cycle~ there.
If you are confused by the direct connection between the number box to the pattr and from there back to the number box: what normally would cause a stack overflow is totally ok here. The Max scheduler knows about pattrs and hinders these overflows. Instead it allows a two way communication between patchers:
If you are adventurous you can make a little experiment: put a deferlow into the feedback chain between pattr and the number box, change the value in it and see what happens.
The controller in this mini-example is the place where pattrstorage finds its place. pattrstorage is the central object to manage all states of the model, making presets with them, and write and read this data to disk. The simplest way to make the model data available to pattrstorage is to use it as a subpatch inside the controller, like its shown on the left.

If you now double-click on pattrstorage it opens its so called client window, showing all parameters currently seen by it:
A short word on the green framed pattr mspOnOff. Inside the tLb framework the color green on pattrs denotes that the Hide From Pattrstorage attribute is set, making it invisible to pattrstorage. This means, this pattr is only used for communication, not for storage. Also note that the Data Type is set to long, since it only holds "0" or "1" values and Default Interpolation is set to thresh 0.01. This has no meaning here, but in case you use the switch in a context where you interpolate between presets – another feature of pattrstorage – the attribute has already its right value, namely no interpolation, you can have only "on" or "off". thresh 0.01 causes that immediately after the start of an interpolation between two preset numbers, at the "in-between" value of 0.01, the next preset will be recalled for this parameter.
hide
If you worked with the pattr system before you might ask, why not use autopattr? Distinct pattrs makes it easier to set certain attributes for each parameter, especially if the recall order is important (set "Priority") or the mentioned interpolation attribute.