20Concepts Lesson 10 - Presets and The Pattr Object

From Cycling '74 Wiki
Revision as of 17:53, 4 December 2012 by Darwin Grosse (Talk | contribs)

Jump to: navigation, search

(Needed: Example Video)

One of the things that everyone wants to do is to store the "state" of their patch so it can be restored when a patch is opened. If there is the chance of having more than one useful state, having multiple presets is even more valuable. Max provides a simple means of storing states - using the preset object - it has some limitations for external storage and content management. Therefore, it is important to consider a Max subsystem that offers significantly more flexibility: the pattr object.

(Needed: Fixture Patches with download)

The Pattr Object

Working with preset content in Max is all about learning to work with the pattr object. This object manages connections to your on-screen UI objects, maintains a set of preset "slots" to select, and interacts with other objects for the storage and communication of the preset data. Perhaps the best way to learn about the pattr object is to review a set of videos created by Gregory Taylor that maps it all out:

Once you've reviewed these tutorials, we can start building toward our example patch.

More about autopattr


Now that we've learned about the overall use of pattr, let's look into some details. First, the important autopattr object. One important part of the autopattr autonaming function is that it just uses the object's default name, and adds an array index (such as [1]) after similar objects after the first. If you want to manage the names better, you need to name the object before you instantiate (create) the autopattr object.

Secondly, if you want to exclude a control from the autopattr default management, you need to connect this object to the second outlet of the autopattr (as with the above patch). This is useful for controls that select a preset from a pattrstorage object, or when you have controls (like a master volume control) that shouldn't change from preset to preset.

Finally, if you add an object to the patch after you've created the autopattr object, you will need to either reload the patcher (by saving, closing and reopening the patch) or reinstantiate the autopattr object (normally by editing the content of the object box). This will cause autopattr to rerun its collection of objects, do any necessary naming (if @autoname is set to 1) and add new objects to the internal pattr system.

More about pattrstorage

You'll notice that even in the simplest pattr example (above), I'm using the pattrstorage object. That's because pattrstorage maintains the majority of preset-like functions as well as providing us with ways to interact with the stored information. In the patch above, we are using it to give us a display window for the results of the autopattr object - we get the display window by double-clicking on the pattrstorage object box. In this window, we can see all of the attached objects, the order of preset loading, the way that interpolation will be performed and the current value of the object. This information is critical for proper use of the pattr system, and it is only through the pattrstorage object that we get easy access to it.

This is a work in progress...

Rerouting Data using pattr

(Needed: text)

Creating Complex Controls using Preset Morphing

(Needed: text)

Web Links

(Needed: text and links)


(Needed: text and exercises)

by Darwin Grosse and Cory Metcalf