Bundles

An Integra Bundle could be thought of as a 'meta-collection'. A Collection that, apart from the signal/data processing modules also contains information about the composition, the composer, the performers, documentation of the actual performances, instructions to performers, instructions to sound engineers, etc. In short it is a 'meta-score' that extends the written score in many dimensions and ties together different kinds of documentation formats and digital resources (audio, video, images, texts). For a piece with many documented performances the Bundle can become a very large object forming a view on the ontolgy of this particular work. However, a Bundle does not have to be limited to one composition, it can be a collection Integra documented pieces by one composer or a set of pieces played by a particular ensemble. The Integra Bundle class may be thought of as a way to store a database query such as (in quasi SQL):

  SELECT ALL COMPOSITIONS BY LUCA FRANCESCONI WHERE performed-by CONTAINS Ars Nova

and allow for the result of this query to be stored on a local machine.

The Bundle is a subclass of the Collection class, which defines generic container-like attributes. The ModuleCollection class extends Collection by adding module-specific container capabilities such as the ability to create connections between module ports. The Bundle class extends Collection by adding capabilities related to storing data pertaining to an entire work, not just the signal/data processing modules. It is responsible for locating all of the resources relating to a work, or a given view of a work.

As has been stated the Bundle may become very large and a lot of data of no interest to a particular user or, more importantly, in a particular situation, may be included in the Bundle. To handle this, as part of the Bundle, the concept of Bundle views were introduced. A view may be one particular performance or only the signal/data processing modules of all the versions of one piece.

Using the example above where we have stored a Bundle of all the compositions that the ensmble Ars Nova has performed, one view of this data could be “Recording, June 2007” and another could be “DSP for Composition A”. The first one would return a 'view' of the works recorded by Ars Nova on a session in June 2007. This view may contain sub-views that are “Luca” (the data Luca wanted to see) and “Producer” (the data the Producer of the recording wanted to have access to - likely to be the version of the piece to be recorded). The second view contains all the DSP modules for Composition A, in all their different version throughout the history of the piece. This view may have been created by a laptop musician interested in using some of the same processing that Luca Francesconi used in Composition A. As opposed to the producer in the context of a recording, the laptop musician may be helped by getting access to all the different version of the modules.

Following is a preliminary suggestion for an example XML file describing a simple Bundle with a few different views. As can be seen the Bundle XML is mainly referencing the data stored in Collections and Modules.

<Collection>
<object id="ob.0" views="2">
      	<view name="Jamie's view" >
		<collection name="recitalHall2003"
                            xlinktype="simple"
                            show="embed"·
                            actuate="onLoad"
                            href="../collections/recitalHall03.xml" />
    		<description>I made this last year</description>
	</view>
	<view name="Henrik's view" >
		<collection name="Malmo2007"
                            xlinktype="simple"
                            show="embed"·
                            actuate="onLoad"
		            href="../collections/Malmo07.xml" />
    		<description>Fantastic performance</description>
	</view>
</object>
<object id="ob.1" views="2">
	<view name="Jamie's view>
		<person name="Jamie">
		...
		</person>
	</view>
	<view name="Henrik's view">
		<person name="Henrik">
		...
		</person>
	</view>
</object>

The environment variable

  LIBINTEGRA_BUNDLE_PATH

is where the user stores their Integra bundles e.g. ~/work/Integra/mybundles/ The variable may be set to a comma separated list of directories:

  LIBINTEGRA_BUNDLE_PATH=/path/1:path/2/blah:/path/3/foo 

The LIBINTEGRA_BUNDLE_PATH environemnt variable have anything to do with the .integra/ working directory described here.

A bundle is created either locally on the client through the Integra Environment GUI or by executing a query on the on-line database. Once it is created it can be up- and downloaded:

• Via the website
• Using libIntegra XML-RPC

The XML-RPC interface may also be used to keep a locally stored bundle up to date with changes made and uploaded to the server database.

Depending on what kind of bundle has been created it may contain a large number of different kinds of files. The common nominator for a bundle is that it contains a contents.xml file (see here for a proposed example) at the top level referencing all other files. The contents.xml file doesn't contain anything by itself. The archive is zipped together: To the user it looks like (and is) a single file that can be moved around, copied to any other medium or shared over a network. Apart from the top level contents file the archive contains all other files specified, including libIntegra generated XML as well as auxilliary data used by the module host (audio files, sdif etc) and general documentation files such as audio and video recordings and photographs from performances and rehearsals.

Following is a proposed hierarchy of the Integra Bundle:

  bundlename/contents.xml - XML file giving bundle contents (directory/file list)
  bundlename/header.xml - Bundle name, date, owner, license information - that sort of stuff
  bundlename/hosts.xml - Host details of hosts this bundle will work with (e.g. Max/MSP version 4.5). 
  This file should also include host-specific  dependency list (e.g. the zexy library, CNMAT externals etc)
  bundlename/XML - Integra generated XML hierarchy
  bundlename/XML/collections - collection files 
  bundlename/XML/classes - class definitions
  bundlename/XML/documentation - documentation files ?
  (bundlename/XML/aggregates) (Can these go in classes?)
  bundlename/XSL/ - Stylesheets for collections (and documentation)
  bundlename/audio/ - Wav/aiff etc
  bundlename/video/ - quicktime/avi etc
  bundlename/images/ - gif/png etc.
  bundlename/host/Max - module implementations as Max patches/externals
  bundlename/host/SC3 - module implementations as Supercollider patches
  bundlename/host/unix
  bundlename/host/OSC

etc.

At runtime the bundles are decompressed, and stored in a semi-temporary location:

  ~/.integra/bundlename.identifier/

The optional '.identifier' is an integer used in the event of having two bundles with the same name?

We re-compress the bundle after the current session and write back to the original archive. We then delete the temporary files.

We can then use the temporary working copy in .integra/ as a means to detect a crash, and can recover using the data there if a crash occurs.

We can also use the working copy as an auto-save location if required.

• Do we support (multiple) undo at the library level, or do we leave this to the UI using the library? (Supporting this would make life significantly more complicated)