The central idea of this work document is to find ways of comparing different composition systems/languages. We would like to try to define some criteria with which composition systems can be evaluated: what would we ask if we were to write a consumer report on a collection of composition systems?
Maybe the scope of this thing should be limited to composition languages of some sort (this as opposed to systems), including the visual ones, but excluding systems without abstraction mechanisms. There are some dangers to this endeavour:
1) The outcome might be an useless bulk of feature-lists This document is not intended to describe all detailed, marginal features (like the kind of output formats supported, etc.). In our opinion it is most useful to concentrate on the central core mechanisms of a composition system and from there predict/understand its capabilities and limitations. We hope all contributors will show some discipline in this.
2) Because most systems are fully programmable - the answers to lots of questions can be: "yes, it can all be done, but the user only has to do some programming". We should not be satisfied with such answers, each system/language makes lots of presuppositions and assumes that programming users adhere to them. Fully arbitrary extensions often do work for the first extension but not for the second one because orthogonality was broken. Therefore please be careful in this.
In discussions it is easy to be able to have a standard set of prototypical problems. The vibrato and the drumroll problem proved fruitful concepts. There must be more simple but hard problems, let's try to include an inventory here.
The systems to discuss are sometimes families of programs (like Roger's Fugue, Canon and Artic family), sometimes a growing design of a system yet to be (like our LOCO, Lisp as a second Language, generalized time functions, COCO set), and sometimes a completed system (MAX, KYMA). This will be a bit confusing, so we propose that the author(s) of each composition system (preferably) clarifies these issues beforehand - either the author chooses to deal with each language separately, to only deal with one, talk in general on the whole family, or clarify the differences.
This is a first rough inventory, PLEASE EDIT, EXTEND and CHANGE as much as you like. The QUESTIONS should finally come out as clear as possible. Maybe we can answer them for each of the systems we know about below the question (because the answers may clarify the need for the question to be asked). But first we need some precise questions.
Peter Desain
Henkjan Honing
January 1992
**********************************************************************
Computer music composition systems Questionaire
[DRAFT Wednesday, September 29, 1999; for a recent copy contact honing@mars.let.uva.nl]
MUSICAL PRIMITIVES
(objects that conceptually represent sound, and can be translated into some form of sound, or in a known sound specification format)
What are the primitive, predefined musical objects? (e.g. none (MAX?) notes, rests !!, sounds)
What are their attributes? (pitch, duration, start-time)
What is the type of each attribute? (a value, a stream of changing values, a time function)
When are these attributes specified/calculated? (creation time, default values now- scaling later, laziness)
Is there access to attributes of primitive musical objects after creation time? If so, what kind of access? (read and/or write access)
Do the attributes reflect performance or score data, or both? (note category and local tempo, or performance duration)
Can new primitives be defined that integrate nicely? (e.g. drum-hit, grace-note, lights-on)
What assumptions on attributes/behaviour should they adhere to? Are the time attributes treated specially? (start-time, duration)
MUSICAL COMPOUNDS
What are the compound musical objects? (S,P, Seq, Sim, event-lists, mixes, clouds, chords)
How are they created? Do they specify part-of relations or also imply time-relations or other constraints?
Is there access to the elements of a compound after creation? (Sim and Seq functions could calculate a note-list, a hierarchical note-list or even a data-structure that reflects Sim and Seq objects directly. They could even be implemented such that they 'play' directly as side effect - and do not deliver any data representation).
What are the extra attributes attached to this structure? (label, name, track number)
Are all compounds predefined or can the set be extended by the user? Are there special compounds for overlap and non-standard attachment (Pre- and post- objects)
INTERACTIONS BETWEEN ATTRIBUTES OF PRIMITIVES AND COMPOUNDS
How is the relation between parameters of primitives and compound objects (especially in control of timing)? (absolute start-time vs. start-time relative to some compound vs. implicit start-time dictated by compound)
Is this a one-way interaction, if so, which way? (may duration of compound depend on specified duration of primitive or the other way round, or even constraint type of relation)
If parameters of primitives are complex, how do they interact with attributes of compounds? (e.g. time functions, rubato functions spanned over compound objects)
At what time do all these interactions take place? (run time, creation time)
PRIMITIVE TRANSFORMATIONS
How do transformations work, on which representation level do they act?
Can they be user-defined?
COMPOUND TRANSFORMATIONS
How can transformations be stacked and combined?
Are there difficult interactions in this process?
Is this done in extension/intention, can transformations be decomposed?
[Could you elaborate what you mean here? RBD]
Can the kind of transformation combination be user-defined?
INTERACTIONS BETWEEN DATA AND PROGRAM
How is flow of control handled, how does it interact with data-flow? (e.g. MAX's bang)
How and where is the system lazy and/or eager? (planning)
How and where is 'real-time' response possible? (we mean not 'very-fast', but reacting to not yet known events)
PROBLEMS
How does it solve the following prototypical problems?
Transformations on discrete vs continuous data; the vibrato problem.
Transformation vs complex musical object, dependency
[what does this mean? -RBD]
; the drumroll problem.
Portamento problem
We also need to represent non-causal aspects of music (right to left, or future to now communication). For example, a note which pitch has to glide to the pitch of next note, not yet known or not locally available. Mechanisms are needed to refer to this "future" object in the language.
Transition problem
Control functions are in principle defined for the interval of the object they are linked to. But some times we need to extrapolate and interpolate between control functions to be able to describe, for example, what should happen between notes. How is this supported in the language?
Compressor problem
Sometimes a global transformation needs to refer to the results of a local transformation of an attribute (bottom-up communication). This is needed, for instance, when a transformation depends on the final (completely transformed) value of some attribute. For example, a compressor transformation that needs access to the final amplitude description of a specific object (like a number of notes in parallel).
Articulation problem
Comparable to the portamento problem is the articulation problem. Articulation needs to know onset of next note to, for example, express a legato: a certain absolute overlap between two succeeding notes (and keep it legato under time transformation). First, the current note needs to know what the next note is (not trivial when, for example, the current note is followed by a P structure containing several notes), and secondly, what the onset of that note is (assuming this cannot be derived from its own local end time, for instance, the next note is time-shifted a bit or preceded by a rest). This has to be the next note in that sequence, particular voice or stream. In general, the problem indicates the restrictions of simply representing articulation as an attribute (as if, for example, a single note could have an articulation), because it ignores its structural characteristics.
How long is a note?
for example, a note with a release - how far does it extend?
Crescendo problem
In case of crescendo from a certain value to a maximum value, when should it be at its maximum? At the end of the last note of a sequence, or at the beginning of the last note in that sequence? How is the latter solution represented?
EXAMPLES
What are prototypical examples of the system?
Beautiful simple solutions - things that are easy.
Awkward work-around solutions - things that are hard but can be done
True limitations - thing that cannot and should not be done
PROGRAMMING LANGUAGE
Which level of general programming is available?
When is it needed?
What programming style? (declarative, procedural, constraint, data-flow)
**********************************************************************
DOCUMENT HISTORY
27 January 1992: Peter Desain and Henkjan Honing, initial proposal
20 February 1992: Roger Dannenberg, added Fugue description.
14 June 1993: Peter Desain and Henkjan Honing added introduction + addresses
7 July 1993: Peter Desain and Henkjan Honing added some more problems
Addresses
Email group: +dist+/afs/andrew/usr/rbd/dists/models.dl@andrew.cmu.edu
[people that were sent questionaire:]
Peter Desain: desain@nici.kun.nl
Henkjan Honing: honing@mars.let.uva.nl or henkjan@alf.let.uva.nl,
Roger B. Dannenberg: dannenberg@cs.cmu.edu
geraint@edinburgh.ac.uk
e.miranda@edinburgh.ac.uk
Gerhard.Eckel@ircam.fr
Gerard.Assayag@ircam.fr