Bencina, R. "The Decomposing Interface - reflections on the development of musical software", Chroma, Newsletter of the Australasian Computer Music Association, pp. 5-6, No. 28, June 2000.
Copyright © 2000 Ross Bencina. All rights reserved. Reproduction without written permission prohibited.
The last time I wrote for Chroma (over five years ago now) I was beginning to gain some insight into the degree to which my musical thinking was constrained by the representational abstraction interposed between my creative processes and the realised musical work. At the time the abstraction was the Csound software synthesis language, which I felt was hopelessly inadequate to represent my musical ideas.
My proposed solution to this representational dilemma was to keep the "implementation details" of the music separate from the musical abstractions I intended to articulate. I considered this necessary at least in part because Csound does not provide programming primitives capable of modeling anything but the most minute details of sound synthesis. The idea of decoupling the musical abstraction from its implementation is hardly a new idea. However, at the time I was used to thinking of music in terms of established concrete representational systems (common music notation scores, Csound orchestra and score files, C programs etc.), not in terms of more ephemeral abstractions.
Due to my inability to represent my musical ideas directly using Csound I began what I can only describe as a long and unfinished journey towards mastering the C++ programming language. Among other important things (such as generic programming ), C++ provides language constructs to support Object Oriented Programming - which is still a rather fashionable concept. At the time Grady Booch was quite fashionable indeed and his book "Object Oriented Analysis and Design," struck a chord. A major thrust of Booch’s thesis is that when designing software it is important to consider the design in terms of the problem space independent of the implementation space.
What is meant by the distinction between problem space and implementation space (in the Object Oriented Programming context at least) is that objects within the problem space such as employees of a particular company (to choose a droll canonical example) and their attributes and behavior are considered independently of their implementation as data structures and methods implemented in a particular software system. An advantage of this approach is that it is much easier to produce a coherent software design when you are manipulating abstractions in the problem space rather than dealing with the idiosyncrasies of particular programming languages and operating systems. There is no question that the software must be embodied with the tools to hand - however according to the tenets of Object Oriented Analysis and Design, implementation details should not impact the design of an object model.
As an individual programmer working alone, maintaining a clear view of the interplay between problem space and implementation space is difficult. Similar issues arise in musical composition, and much music is produced in which the problem space is heavily influenced by the implementation space. From many years I have improvised at the piano keyboard - sitting at the keyboard these days I am painfully aware of how the implementation details of the piano have colored my notions of the musical problem space. I feel that the same can be said of the experience of using musical software. The user interface or language primitives present the lowest limit on what is possible, all other [musical] abstractions must be built from them.
A general purpose programming language such as C++ presents an attractive vehicle for implementing musical ideas. However many layers of abstraction lie between the graphical user interface, or textual language parser, and the digital to analog converters. Some of these abstractions may be taken as given such as digital representations of audio signals, however as we travel up the abstraction food chain there are an increasing number of possibilities for representing musical signals. So it is that the question arises: "What constitutes the problem space of a system designed to realise musical compositions?" It is relatively easy to answer this question for the simple case of rendering pre-existing compositions, this has been the starting point of many existing software systems. However it is much more difficult to arrive at a speculative definition of a minimally constrained musical problem space given no historical constraints.
The AudioMulch Interactive Music Studio software which I have been developing for the past few years is my first attempt at modeling a musical problem space. AudioMulch implements a set of musical and audio signal processing algorithms "contraptions" which may be combined using the well known patch-cord paradigm to achieve various sonic results. Although I didn’t begin with a clear problem definition, AudioMulch embodies the abstractions of a typical electronic music studio: Live audio inputs and outputs, signal processing "black boxes", sound sources, mixers, patch cords etc.
Sometimes I feel uneasy about the musical constraints imposed by AudioMulch.. These constraints exists partly because AudioMulch is not a mature program, and partly because it straddles the boundary between the glossy world of shrink wrapped software and the dirty world of code-it-yourself Computer Music. As AudioMulch grows to embody more of the fundamental abstractions of the field the constraints will lessen, however it may be necessary to concede that a key benefit of AudioMulch is its ability to constrain possibility to manageable proportions. For the time being at least, modeling the musical problem space remains a work in progress.