Module collections

The term 'module collection' describes a collection of module instances held in memory. The term 'module collection file' describes an XML file that can be used to store the data that is needed to recreate a module collection. Module collections can be used to store networks (graphs) of audio and data processing modules. They can also be used as an encapsulation mechanism: a collection can contain other collections. When a collection becomes encapsulated, it can be used inside another collection as if it were a single module, i.e. it can be instantiated an arbitrary number of times, with each instance being uniquely addressable. The diagram below shows an example module collection.

This diagram shows a representation of the module graph required in order to instantiate a soundfile player that plays through a harmonizer, and out to the audio DAC. In order to create this collection, the encapsulated collection: '3-voice-harmonizer-with-gui' must have been created first, and then instantiated in the new collection: 'my-cool-patch'. '3-voice-harmonizer-with-gui contains two sliders connected to a 3-voice granular harmonizer whose outputs are connected to a summing bus. When '3-voice-harmonizer-with-gui' is instantiated, it is given an instance name like any other module, and this becomes the prefix for the module's OSC address.

Each box in the diagram can be represented by a separate XML file. Broadly speaking these divide into 'module definition files' that contain only non-volatile immutable data, and 'module collection files' that contain any data about a collection that is subject to change. The definition files could be viewed as being like an offline dictionary that an Instance Host can use to lookup data about a given module (e.g. supported ranges of parameters, fixed OSC address strings). The collection file is more like set of instructions to the instance host on how to re-create a given configuration. The red fields in the above diagram represent the data that will be stored with the collection: 'my-cool-patch', the blue fields represent data that would have been stored when the collection '3-voice-harmonizer-with-gui' was saved, and the black fields represent data taken from the the module definition file. In practice the XML collection file format leverages the XLINK technology to create connections between resources in other files.

The module definitions for graphical modules contain no data about their visual appearance. Module collection files also contain no clue as to the visual appearance modules might take when instantiated in a graphical environment. However, since we use XML as a storage format for this data, we can take advantage of standard technologies for adding 'style' information to XML documents, namely XSL. It is proposed that every module collection file contains an optional link to an associated stylesheet, which contains such data as width, height and co-ordinates and colours of modules, text typefaces etc. It then remains up to any graphical module host how they wish to interpret this data.