The last tutorial was a great (and fairly easy) introduction to working with the Push, but it does suffer from one problem - long load times. In order for the abstractions to provide easy access to all of the Push parameters, Mark's code created a connection to all of the possible parameters. This process can take a long time to load - which can be an irritation in a live performance situation.
Here's the code for the PushStepper device: Media:PushStepper.zip
The Surface object is the high-level object that finds and interfaces with the Push controller. We use a probe into the control_surfaces LiveAPI path in order to identify the control surface labeled "Push" (which is what any Push device will call itself); once this is done, we register access to the button matrix and create some mediation methods to manage interface with the user interface.
Whenever we grab or release the button matrix, we do it through the grabButtonMatrix and releaseButtonMatrix functions. In addition to performing the grab/release, we also set properties that let us know the current status, and also determine that property that we will be "observing" (in this case, the value). This was actually a difficult piece of logic to get correct, and only with help from Jeremy Burnstein was I able to negotiate the connection correctly.
Finally, when we grab the button matrix, we have to have a way to receive the information. This is done with the Surcvace.prototype.bmxCallback function, which is called any time that the button matrix values change. I put in an extensive note about the use of 'this' in the callback, and that it refers to the button matrix (not the Surface itself), because of the way that we've instantiated the button matrix interface. Confusing? Sure, but it works, and gives us a chance to do some interesting stuff in the Matrix object.