Personal understanding of a composing style: the composing continuum – composing from start to finish : rough prototyping : pre-composition : defining a score : the all-important manual : alternative solutions to on-line documentation : the contextual menu: arguments, values and annotations : the output is the score – String Trio (2012).
One of the attractions of computer-aided composition is that it appears to offer a new and different way to compose, a way that just might be able to give new solutions to prevailing questions that can prevent pieces from being written. I’m sure I’m not the only composer who has imagined a piece of music that has turned out to be (seemingly) impossible to compose.
I remember working for most of a summer vacation on a large-scale composition for solo piano with wind, brass and percussion, and eventually having to abandon it. Pieces for large wind ensemble, because they can include so many different instrumental parts and instrumental colours, require a lot of notes. If things go wrong, rewriting can become a very tiresome business indeed. Composers get around this by initially writing in short score, but the sheer quantity of music that the medium appears to need can be daunting and, eventually, as in my experience, defuse musical ideas altogether. I did, however, some four years latter manage to compose this piece, and I did it through programming.
But before I started composing Heartstone, I did spend several months not applying this experimental approach to my latest work in progress. There were reasons why this was the case, and they weren’t musical but personal. My eldest son was seriously ill and I spent many long days (and nights) in hospital where it was difficult to compose. I was away from my comfort zone – my desk and my computer – but there were long periods of empty time, time when I could do nothing but wait and be the caring parent. However, this proved to be providential because it gave me a chance to think very carefully about a computer-aided composition (CAC) system I had recently started to explore. Being away from my desk (and computer) gave me quality time to absorb into my working practice this new system, particularly its musical vocabulary and lexicon of functions.
The first question that I had to answer, or so it seemed, was how I might understand and describe the parametric elements of my composing style. An early concern was: could I compose with the rhythms and metric structures my music had already formed over some twenty years of composing? Would I be constrained by this CAC system in creating what I was used to composing on paper? Irrational rhythms and tied note-lengths were quick to raise their questionable heads. Later, and significantly, the parameter of a note-length’s duration joined these questions. This soon became a quite engrossing exercise, because to answer such questions demonstrated to me what was lacking, and might have to be written into the system. At first I didn’t know the language on which this particular CAC system was built, but I gradually learnt it, and (with help of the system’s designer) made appropriate modifications so that this computer-aided composing system gradually became an extension of my compositional thinking.
Even with the advances in CAC systems since 1989 it’s unlikely that every composer’s requirements will ever be accommodated immediately, but in the early stages of grasping the potential of a system this is possibly a good thing. My experience is that working slowly and with bite-sized objectives can be very rewarding, even if it takes a while to bring a current composing project on board.
So to the big question – Is it practical to think of CAC has handling the whole process of composing a concert piece from start to finish? Can a composing continuum be achieved that manages the whole composing process: from those pre-composition experiments to the production of a full-score (and parts)? For many composers who have investigated this approach the answer has been an emphatic no. But the gap between that no and a possible yes is closing.
My personal composing continuum goal has not been so much achieving a finished full-score in notation within a single computer application, but being able to experiment and try ‘what ifs’, and at least produce what is called in other design disciplines a rough prototype. And this prototype should be in a transportable format, in my case a MIDI file and MusicXML format.
That said, I’m equally aware that some composers of note have made exciting and productive use of CAC systems to create the all important body of material that underpins a composition. And this material is rarely composed sections of scores, but collections of discrete parametric material from which a composer’s imagination is able to gather together and fashion a comprehensible score.
Although I mentioned previously the need to test out how my rhythmic language could be accommodated, the very first practical experiments started with creating small ensemble pieces for solo instruments of different timbres. Creating melodic lines is rarely a problem in a CAC system, but synchronising a quartet of melody lines is certainly more difficult.
The parametric element can be summarised as requiring a melodic line to have at the very least rhythm and pitch. Rhythm and pitch are usually divided into separate parameters, but to talk of ‘rhythm’ can be a little premature, because what a system needs more precisely is a list of note-lengths to correspond or synchronise with, a list of pitches. Like this:
(setf pitches ‘(c4 cs4 c4 fs4 g4 fs4 cs4 fs4 c5))
(setf lengths ‘(s e s q q e e h q))
;; s = 1/16, e = 1/8, q = 1/4, h = 1/2
=> (s c4 e c5 s c4 q fs4 g4 e fs4 cs4 h fs4 q c5)
This is the material certainly, but it won’t play out the melody! For this we need to create (or define) a score, score that will ‘do the playing’. In most CAC systems a template is provided that is a series of flexible slots into which the composer can fit the scoring details of instruments. Below is an example of such a template: to allow the variable melody to play with the sound of a clarinet at a defined tempo.
(:key-signature ‘(c maj)
:tempo 100 )
:program ‘clarinet )
My first experiments created little quartets that started with the instruments playing together in unisons:
(:key-signature ‘(c maj)
:tempo 100 )
:program ‘flute )
:program ‘horn )
:program ‘violoncello )
This may seem so obvious, but I’ve seen many composers come seriously adrift at this point. This part of the program simply has to be correct, and correctly laid out. But once defined a score can now become a template for any number of experiments. My suggestion is to save the score template under a file-name and paste it into an empty file, then, compose away knowing that it can be reused at any time. Don’t belittle such experiments because you can very easily make them the starting point later on for elaborate test pieces.
In the past composers beginning to use CAC environments had to search ‘in the manual’, and then spend hours of careful reading! I well remember studying David Zicarelli’s MAX system: its manual was a vast loose-leafed file over nearly a 1000 pages. Gradually, designers realised that it was preferable for a system’s functions and their documentation to be available as menu items, and imaginatively arranged to make it possible for the format to be printed into the score window; documentation and exempla embedded in the system itself and when needed brought to the composer in a separate window. We’re now seeing many other solutions to supporting the range and possibility of a CAC system. One powerful solution is the ‘floating’ contextual menu (shown below).
This is at least somewhere to start. Nevertheless, taking in the potential of 700 plus functions is a huge undertaking. It’s good to have some strategies up your sleeve for managing this learning challenge.
One strategy I’ve found useful is to collect together all the functions as you discover and use them, and place then into a dedicated index. After a while, start printing this list out. Have it by your side, or if you have a large enough screen display, keep present as an open editor window on your system. The first thing I did when finishing the composition of a recent tutorial for a CAC system was to make such a text-file index (in alphabetical order), and keep it visually present so the function names became more and more familiar. This 30-stage tutorial used just over a seventy different functions. The system I was working with itself contained over seven hundred functions!
So a major challenge exists: how to discover and absorb the range and content of functions the CAC system contains. Acquiring function knowledge is like learning the vocabulary of a language. Some functions either generate material or process it, and these can be challenging because some contain many arguments and values; some are dedicated to the business of conversion from one data form to another, for example integers to pitches. Others can be described as utilities or even primitives having a subsidiary role, being one-shot functions doing one thing and one thing only. One such primitive is the append function able to join two or more lists of data together.
I’ve found the analogy with learning a foreign language very helpful, even consoling. Developing fluency is often hard won; we can’t always immerse ourselves in learning by situating ourselves daily in the context in which the language is used. When working with a programming language in a sustained way, fluency gradually develops, but when that regular engagement ceases it can feel an uphill task making a re-engagement. For this reason I’ve come to value making annotations of the scripts, code or programs I write. An annotation is an extension of that all-essential commenting of code.. It is not a shorthand for explaining what’s going on but attempts to show a process or an outcome in more depth, and often with musical examples. It provides an analysis of the narrative of the composition. Most of my major compositions in code have such annotations, and they have been published on my web archive. Over the years they have provided valuable sources of reflection on the how and why of composing. The composer Alexander Goehr has written famously that ‘a composer should always be conscious of the history of his (or her) art.’ In my experience having a clear trace of the composing process in code within a programme structure can truly be most valuable.
A good example of this can be found in the score and annotations of my String Trio of 2012. This composition shows a piece created entirely through programming, and with no interventions, massaging or added decoration when taken to the stage of producing a full-score. When the code is run, the composition is the output. I don’t consider that there is any particular merit attached to being able to achieve this, except as a private demonstration of a certain consistency of purpose and thought.
The idea of the piece was carefully planned at the outset, and the program was able to follow and execute these ‘plans’ with some accuracy. If you do view the annotation, you’ll notice the code contains several ‘home-made’ functions created especially for the composition. This is a further reward for those who gain some fluency with a CAC system: you can learn to devise your own tools.
It is very common phenomenon to find that a composer has been led into working with a CAC system because it seems to offer a solution to solving a particular composition problem or realising an ambitious project. This is perhaps not the best premise on which to engage the challenge the CAC presents. It needn’t be all or nothing, one or the other, traditional skills and practice or computer-aided composition. But, as with learning a language properly, there comes a point of commitment where the composer has to be convinced the investment in time and a different mode of thought and action can be justified. When you learn a language seriously you begin to engage in the culture that stems from that language, and it is that culture that supports, colours and informs the hard and repetitive business of learning.