MixerGUIDef 

Defines the appearance of a MixerChannel in a mixing board.

Usage:

MixerGUIDefs may be stored in two places for easy retrieval. Both of these are illustrated in MixerGUIDef's *initClass method.

aMixerChannelDef.guidef = aMixerGUIDef;

If assigned, all channels made from this mixer definition will use this MixerGUIDef.

MixerChannelGUI.defaultDef =  aMixerGUIDef;

If a MixerChannelDef does not have a GUI definition associated with it, the defaultDef will be used.

Creation:

*new(channelSize, viewProtos, viewKeys, viewBounds)

Creates an instance. Unlike MixerChannelDef, this is not stored automatically in the global library.

channelSize: A Point defining the total height and width of the channel's GUI.

viewProtos: An Array, listing the object prototypes that will be used for each view in the channel GUI. The object prototypes may be classes or instances of AdhocClass.

viewBounds: An Array of Rect objects specifying the bounds of each view, relative to the top left corner of the channel. 

Example: 

This is the default MixerGUIDef, suitable for stereo mixer channels.

MixerGUIDef(Point(50, 290),

[MixerMuteWidget, MixerRecordWidget, MixerPresendWidget, MixerPanWidget,

MixerLevelSlider, MixerLevelNumber, MixerPostsendWidget, MixerNameWidget,

MixerOutbusWidget],

[Rect(0, 0, 20, 20), Rect(30, 0, 20, 20), Rect(0, 25, 50, 30), Rect(0, 65, 50, 15),

Rect(10, 85, 30, 100), Rect(0, 190, 50, 15), Rect(0, 210, 50, 30),

Rect(0, 245, 50, 20), Rect(0, 270, 50, 20)]);

Notes: 

The viewProtos and viewBounds are parallel: Rect(0, 0, 20, 20) corresponds to the MixerMuteWidget, etc. 

It is possible to display more than one pre- and post-send. To do this, include the pre- or post-send widget more than once in the viewProtos array, and assign appropriate bounds so they don't overlap. When the widgets are created, they will get unique indices: the first presend gets the key \presend0, the second \presend1, etc. 

Mixer widgets 

The system depends on objects to maintain the individual views for mixer parameters. These have a very simple interface, so it is easy to write new widgets to support different usages. 

Most widgets will have a single view to reflect a single numeric value. These widgets should inherit from the MixerWidgetBase class and should implement the following methods:

makeView(layout, bounds) -- create the view in the view variable, and initialize the spec (spec variable)

doAction(view) -- update the mixer's control with the new value from the GUI

updateView(value) -- update the GUI to match the mixer's state

clearView -- if the mixer GUI is released (is no longer pointing to a mixer), the views may want to reflect that state. For instance, the default views make the backgrounds clear.

restoreView -- update the view to show that the mixer GUI is active again.

updateKeys -- return an object that will be used to update only the proper widgets when a mixer's control changes programmatically or by MIDI. matchItem() performs the matching, so the object can be a symbol, an array of symbols, or a function. 

MixerPanWidget is a good example; use this pattern when writing your own single-view widgets.

Other widgets, such as the default pre- and post-send widgets, need to maintain two or more views. In these cases, it may not be helpful to inherit from MixerWidgetBase. Review MixerPresendWidget to see which methods need be implemented. 

Another type of multiview widget would be a multi-dimensional panner. There is not presently an example of this in the library, but I will post one on the dewdrop world tutorial site.