IASIG Working Group Goals Document

Submitted: April 3, 2003
Author: Chris Grigg, Beatnik
Group Name:Interactive Loop & Branch for SMF

1. Describe the topic and purpose (goal) of this WG:

To develop a specification for a standard, interoperable method of representing looping, branching, and other flow-of-control operations or compositional structures in Standard MIDI Files. The final specification should be published by either the IA-SIG, the MMA, or as a joint IASIG/MMA release.

Sub-Goals:

1. Full compatibility with older SMF content
2. Transparent to older SMF players, if possible
3. Make it easy for sequencer companies to add support
4. Create an open standard without legal "strings" of any kind (no royalties, in public domain).
5. Publish and evangelize a common language (set of terms) for compositional looping & branching and the benefits it provides.
6. Harmonize with other MMA & IASIG interactive audio specifications where appropriate (SMF, XMF, Interactive XMF)
7. Consider extensibility where appropriate

2. Describe the motivation behind (for example, benefit to the market) addressing this topic:

Compositional looping and branching are staples of adaptive soundtrack construction, and

have always been a feature of most game music engines and data formats. However , the Standard MIDI File does not include any standard method of achieving loop & branch, indeed nothing other than simple linear start-to-finish  playback. If there were a standard for loop & branch in SMF,  it would make it much easier to create adaptive MIDI music, and adaptive MIDI music could be interoperable, i.e. could be authored on any MIDI sequencer and played on any conformant SMF player.  Reliance on proprietary players and tools could be reduced. 

Looping and branching is useful in many, many creative and technical applications.  For example:

1. Allowing an SMF to last for any given duration by looping a section a variable number of times
2. Allowing different passages of an SMF to be played, or allowing the passages to be played in a different order, based on conditions at the time the SMF is played
3. Starting an SMF from different positions (start offsets) based on a condition, for example a scalable SMF that starts with an instrumental introduction on high-polyphony players, but starts at the beginning of the melody when played on a one-voice player (e.g. a simple phone)
4. Data compression, by re-using a single copy of repeated figures multiple times

Presently there are multiple approaches to the problem, however all of them are proprietary and this causes a number of large problems (see item 3.). Standardizing  SMF loop & branch  functionality via IA-SIG & the MMA is expected to reduce those problems and lead to several significant benefits:

1. Portability of SMFs with loop & branch to all SMF players
2. Direct support of loop & branch in MIDI authoring tools (sequencers)
3. Create a common vocabulary and understanding of loop & branch for all SMF composers
4. Promote the use and craft of adaptive MIDI soundtracks

Lastly, an important motivation for this WG is that the MMA’s XMF Working Group has produced a draft specification for SMF Loop & Branch. The IA-SIG WG work would begin by reviewing the draft MMA spec.

That design uses SMF’s existing Marker meta-event to define anchors  (jump targets) , and defines two new meta-events:  a variable operation and a conditional link. Links can be jumps or calls, or can spawn new track players. The SMF player is required to supply an array of 32 numeric variables and a simple expression engine.  Link targets can be in any track in the same SMF or any other SMF or XMF file, with external files specified by URI.

The draft spec is incomplete, and needs to be finished and perhaps revised somewhat. The MMA Technical Standards Board feels that since the XMF Working Group has moved on to other projects and this is an interactive audio-oriented work item, the IA-SIG is a more appropriate forum for completing this specification.

3. Describe the current situation (technology, market influence, etc.):

Presently there are a number of methods for putting loops and branches into SMFs, however this situation presents several disadvantages:

1. The formats depend on proprietary SMF player implementations
2. The formats were not created by, and are not maintained by,  any standards development organization
3. For the most part the formats are not publicly published
4. Because there are multiple formats, tool support is fragmented and rare
5. Adding loop & branch information to an SMF in many cases cannot be done in the composer’s favorite MIDI sequencer; a separate tool is required.

4. Determine specific issues which will must be addressed by the WG (in phases, ranked by order of importance):

NB: Despite instructions, these phases are listed in order of execution, not order of importance. Phases 1-3 are likely to overlap.

  PHASE 1 – Determine creative & technical requirements

   Discussion to include:

• Review Background & Requirements Analysis in the MMA draft spec

• How much complexity in the player is acceptable?

• Should SMFs inside containers (such as XMF files or .MP4 files) be supported?

• For SMF Format 1, should the Conductor Track be supported?  How?

• How should the player store and evaluate branch conditions at runtime?

• Branch targets: Labels or offsets?

• Is a variables mechanism needed at runtime?

• Is an expression evaluator needed at runtime?

• Is compatibility with the IXMF interactive audio model a goal?

• How important is playback behavior on older SMF players?

• Should SMFs with loop & branch be a new SMF format to avoid legacy player problems?

• Confirm WG sub-goals listed above at 1.

  PHASE 2 - Evaluate existing (proprietary)  published SMF loop & branch mechanisms

    For example: Beatnik, Miles, others

  PHASE 3 – Evaluate MMA draft specification

  PHASE 4 – Design final loop & branch mechanism

  PHASE 5 – Develop final spec document:  “Interactive Looping & Branching for Standard MIDI Files”

5. Describe the proposed completion schedule for the group:

6 weeks  - PHASE 1 - Determine creative & technical requirements

2 weeks - PHASE 2 - Evaluate existing (proprietary)  published  mechanisms

2 weeks - PHASE 3 - Evaluate MMA draft specification

6 weeks - PHASE 4 - Design final loop & branch mechanism

4 weeks - PHASE 5 - Develop spec document

20 weeks  total project length