Requirements Investigation for an Interface for Csound
Requirements Investigation for an Interface for Csound
Yuhua Guo
City University, London
Northampton Square London EC1V 0HB
[email protected]
Abstract:
Csound has been around for more than 20 years and is today's standard digital sound processing program which provides powerful functions for digital sound synthesis. Csound enables people to make music with just a personal computer.
Developed originally as a command line driven program by Barry Vercoe, Csound, however, lacks the use interface capability that is needed for most of today's personal computers and this makes it difficult to use for many ordinary composers.
The difficulty of using Csound lies in the manual creation of its score and orchestra files which involves the use of many parameters.
This project aims to investigate the compositional process of music and gather a set of user requirements for developing a user interface for Csound. The interface will help composers to use Csound more easily.
TABLE OF CONTENTS
INTRODUCTION 3
2. RESEARCH CONTEXT 5
2.1 THE PRINCIPLES OF SOUND 5
2.1.1 THE HUMAN EAR 5
2.1.2 Fundamental concepts in sound and music 5
2.2 THE HISTORY OF COMPUTER MUSIC 6
2.3 MUSICAL SIGNAL SYNTHESIS 8
2.3.1 Direct synthesis algorithms 10
2.3.2 Physical Modeling Synthesis 13
2.3.3 Synthesis control signals 14
2.3.4 Musical notation and interface 16
2.4 Musical Processing Programs 19
2.5 Requirements Specification 23
3 METHODOLOGY 28
3.1 THE PRESENTATION 28
3.2 INTERVIEWS 29
3.3 THE QUESTIONNAIRE 31
3.3.1 Purpose of the questionnaire 31
3.3.2 Construction of the questionnaire 32
4 RESULTS 34
4.1 QUESTIONNAIRE RESULTS 34
4.2 ANALYSIS AND DISCUSSION 39
4.2.1 The compositional process and tools 39
4.2.2 Notation and Interface 45
4.2.3 How composers think of sound 47
4.3 RESULTS SUMMARISATION 47
6 CONCLUSIONS AND RECOMMENDATIONS 49
6.1 TEST OF OBJECTIVE 49
6.2 CONCLUSIONS AND RECOMMENDATIONS 49
6.3 LEARNING FROM THE PROJECT 51
REFERENCES 52
Introduction
Computer science has made massive progress over the years and we can now do more things with computers. One of the fields that computer has made a huge impact on is music. The compositional process used to mean sitting in front of a piano for days before getting a piece and only find out it didn't sound right after gathering an entire orchestra to perform it. With a powerful computer and the right synthesis software, composers now can compose even without musical instruments. Considering computers are now more affordable, electronic composition is therefore a convenient and economical way to make music.
Most of today's sound synthesis products evolve from tools developed by researchers in the seventies. These tools were not developed specifically for compositional purposes and researchers at the laboratory used them for scientific experiments. Csound is a programming language for sound synthesis which was developed during that time. Csound has the capability of creating any possible sounds and its capability makes it an ideal tool for composition.
Csound is however a text-based synthesis language and Csound users have to manually create the score and orchestra files that are necessarily for Csound to work. As most of today's software programs are equipped with graphical user interfaces e.g. Microsoft Visual Basic provides a graphical environment for its users to write code, the lack of an intuitive user interface makes Csound extremely difficult to use. Moreover, most composers are not natural computer programmers and the fact that most composers have to spend a huge amount of time and effort on learning Csound before they can use it to compose makes them even more reluctant to use Csound as a compositional tool.
Although there are many other musical processing programs available on the market, they in general suffer from obvious weaknesses,
* Musical processing programs with their own synthesis algorithms are by far less powerful in comparison with Csound
* Many musical processing programs that are built on top of Csound are not designed specifically for composers.
Great emphasis is always placed on utilising Csound's functions, and many developers neglect the fact that programs that are built to interact with Csound should be designed as tools to allow composers to be more focused on compositional experiments, not just help them to use Csound. Therefore quite often these programs make Csound usable but still are not ideal as compositional tools.
The primary objective of this project was to investigate the compositional process of music and gather a set of user requirements that will be used to develop a user interface for Csound. The interface will interact with Csound and allow the composers to compose with a high level of abstraction. The interface will allow the composers to focus on their imagination and realise their imagination with Csound's functionality.
A number of activities were carried out to investigate the compositional process, most importantly the interviews with professional composers. The information gathered from the composers included data of functional requirements, non-functional requirements, and requirements for the interface of the system. The data was analysed and written as a requirement specification document.
A number of tasks were taken in order to achieve the project objective. The tasks are as follows,
* A literature survey which consisted of study on requirement specification for software development, sound, musical signal processing, and a market research on some musical processing programs.
* Preparation of materials used for the investigation, this included making appointments of interviews, designing presentation slides and questionnaire, and arranging equipment for the interviews such as tape recorder.
* The investigation which included conducting a number of interview with professional composers.
* Analysis of data gathered in the interview
* Creating the requirement specification document
The project objective would be tested by conducting a requirements review with the composer who would be interviewed in the project.
A successful implementation of the proposed interface will provide composers with a friendly environment to compose utilising Csound's functions. The system will provide powerful functions for the composers to focus on exploring their imaginations and realise them very easily. Such an interface will benefit most professional composers as well as home music hobbyists.
2. Research Context
2.1 The principles of sound
To fully appreciate sound synthesis, it is important to understand the physics of the sound phenomenon. The following study was carried out during this project.
2.1.1 The human ear
The human ear is a complex system which enables us to hear and identify sounds. The ear serves as a transducer, converting sound energy to mechanical energy to a nerve impulse which is transmitted to the brain. This ability of our ears enables us to do the following actions:
* Perceive the pitch of sounds by detection of the wave's frequencies
* Perceive the loudness of sound by detection of the wave's amplitude
* Perceive the timbre of the sound by detection of the different frequencies which make up a complex sound wave
2.1.2 Fundamental concepts in sound and music
Frequency
Frequency means how often an object completes a vibration within one second.
Natural Frequency
When objects are hit, struck, plucked, strummed they tend to vibrate at a single frequency or a set of frequencies. The frequency or frequencies at which an object tends vibrate with is called nature frequency.
An object that tends to vibrate at a single frequency produces a pure tone. Other objects might vibrate at more complex frequencies, if the frequencies an object vibrates at are integer multiples of the first frequency then the object produces a musically rich tone.
The natural frequency of an object can be manipulated by changing the speed or wavelength. Therefore the natural frequency of a musical instrument can also be manipulated by change the properties of the instrument. For example, a guitarist adjusts the frequencies of a guitar by changing the linear density of each string of the guitar, by doing so he can control the frequencies at which each string vibrates. The guitarist can also control the frequencies by pressing the string against one of the frets on different positions on the neck of the guitar.
Fundamental Frequency (first harmonic / fundamental frequency)
The lowest frequency produced by any instrument is called the fundamental frequency. The fundamental has the longest period and followed by a set of harmonics which have integer multiples of the fundamental frequency.
Pitch
The sensations of frequencies are commonly referred to as the pitch of a sound. Pitch is closely related to frequency. A high pitch sound corresponds to a high frequency and a low pitch sound corresponds to a low frequency.
Harmonic
Each natural frequency that an object or instrument produces exhibits its own characteristic vibrational mode or waveform. These waveforms are only created by the object or instrument at specific frequencies of vibrations, and these frequencies are called harmonics.
Loudness
The loudness of a sound is of a subject response which depends on a few factors. Different individuals might perceive different loudness of the same sound e.g. older people might perceive a different loudness of the same sound to younger people.
Timbre
The quality of a sound that distinguishes it from other sounds of the same pitch and loudness.
Amplitude
The amplitude of a wave refers to the maximum amount of displacement of an object from its rest position.
2.2 The history of computer music
Schottstaedt (1997) defines computer music as "the production of expressive music by means of computational tools, systems or devices". Computer music is a relatively new field in the music history which emerged after the advert of computer. With the help of modern technology especially the use of powerful computers composers can now do something in music which was unimaginable before.
"I dream of instruments obedient to my thought and which with their contribution of a whole new world of unsuspected sounds, will lend themselves to the exigencies of my inner rhythm." Edgard Varese spoke these words in 1937 which reflected part of how he felt about the traditional way of composition. Throughout the music history, like many other composers, Varese was tired of the tonal, textural, and timbral capabilities of acoustic instruments. In order to hear a multi-instrument piece, at that time, the composer had to gather an entire orchestra to perform in front of him. This was a very costly and inefficient solution that could only be afforded to the very wealthy and the very famous.
Between the end of the 19th century and the beginning of the 20th century, there were major developments and extensions in musical languages such as Romanticism, Impressionism, and Expressionism etc. In sharp contrast to the extensions in the musical languages, the developments of new instruments progressed very slowly. New instruments invented often lacked the capabilities to complement the new compositional developments. In the first half of the 20th century, developments of new musical instruments were focused on the electronic synthesis of sound and electronic manipulation of sound. For example, Lev Termen invented his Theremin in 1924, a system which was capable of performing a continuous range of pitches by altering the frequency of an electronic oscillator. Many others also invented similar systems at that time, most of these systems however failed. This was because most of these systems were quite primitive in both construction and sound producing capability, also the composers at the time still preferred to use traditional instrument as their composing tool. In 1930s the electric phonograph was invented and frequently used for compositional and performance purposes. Many composers started using it as a tool for composition and thus produced many works. For example, John Cage's Imaginary Landscape No.1 was produced by using different turntable speeds to manipulate signals and mixed the results with muted piano and cymbal. As a result the works of these composers and the use of non-traditional instruments in composition gained wider acceptance.
Although phonograph were used by many composers, it was the development of the analogue tape recorder that created a working medium that allowed musicians to edit sound events for the first time in a meaningful way. Analogue tape recorder gave composers great flexibility accounting for several advantages. For example, the composer could re-record a portion of a piece of music in order to make changes or fix errors. Peter Schaeffer, a young engineer for the French national Radio, began producing tape recordings of natural sounds in 1948. These sounds included locomotive sounds, wind, thunder, and others. He used tape recorder to transform the sounds in several ways and performed it in Paris in October of 1948, this was the first public performance of music that was not played by humans. This kind of music was initially called "electronic concrete" because the sounds were concrete and sonorous objects that could not be plastically manipulated, and later it was changed to a more popular term "electronic music". At around the same time many other similar experiences were also conducted with analogue tape recorders and many other works were composed. Among them, Karlheinz Stockhausen's Elektronische Studien II was famous because it was first electronic composition to be formally notated. The recognition gained by the works of Stockhausen, as well as interest in the instruments which he had exploited in their production, had a profound influence on worldwide research combining music and technology. A few years later, some American institutions attempted to use computers for musical composition but without much success. Luening and Ussachevsky eventually recognised this idea and successfully received a grant from the Radio Corporation of America (RCA). In 1959 they developed the first analogue synthesiser.
Many American institutions took part in the computer music research and many composers became interested in the equipment developed in RCA and started using them to compose. Milton Babbitt produced his first electronic work in 1961 called "Composition for Synthesiser", which was described by Manning (1976) as "the fruit of a seemingly effortless transition from his strictly ordered style of instrumental writing to an electronic equivalent". Compared to analogue tape recorders, analogue synthesisers eliminated not only the need for tape manipulation but also for the laborious task of interconnecting numerous electronic components. Babbitt and a few other famous composers' keen interest in using the analogue synthesiser increased the interest in electronic music even further. As the result of research at numerous institutions and commercial research, voltage controlled synthesiser was developed later. Voltage controlled synthesiser was basically a devise that contained a separate module that could control each individual variable of sound, and then allowed all of those modules to function together under a common voltage control. Microprocessors became available in the 70s and eventually making music with a home computer became reality in the later 70s.
The first real music program was written in 1957 by Max Mathews, an engineer at the Bell Telephone Laboratories in New Jersey. He called his program "MUSIC" which was capable of playing single line tunes. MUSIC ran on a mainframe computer which, by today's standard, was slow and expensive to run and took a long time to compose a small piece. The program however attracted quite a few researchers who were enthusiastic about this new development. As a result, they all worked with Mathews' system and made various updates and improvements over the years. As computers became smaller, faster, and cheaper in 1970s, computers became capable of performing some complex tasks such as handling live performance. As computers continue to become more powerful, an electronic composer nowadays does not need more than a powerful enough machine and some good software synthesisers to do the composition at home.
2.3 Musical Signal Synthesis
Any sound produced by acoustic instruments is the result of physical vibration of a resonating structure. The vibration activity can be described by signals corresponding to the evolution in the time of the acoustic pressure generated by the resonator. The fact that sound can be characterised by signals means that computers can used to generate sounds either for imitation of musical instruments or generation of new sounds. The problem for doing so earlier was because mainframes were too slow and expensive to use. But now even an average PC is powerful enough to handle the heavy number crunching required by real-time music synthesis.
Synthesis algorithm is the core of any synthesis software, each has its own characteristics that is preferred by different people. There are many sound synthesis algorithms currently available either commercially or in the academic community. Current algorithm development trend is towards computational efficiency and user friendlier interface. This means that it is now easier for composers to get access to many synthesis tools, and at the same time be also able to quickly use them without spending a great deal on learning. A sound synthesis algorithm can be thought of as digital model for a sound itself. A digital model can serve two purposes which are representing and generating a whole class of sounds through the appropriate use of control parameters. The class of sounds here means the sounds generated according to their generation mechanisms. For example, strings and woodwinds are two classes of sounds because the mechanisms used to generate them are different. The degree of the compactness of a class of sounds is determined by two factors, the sensitivity of the digital model to parameter variation and the amount of control needed to produce a desired sound. A digital model can be used to represent classes of sound sample by sample, in this case, the control signal of the digital model is represented by the sound itself. Therefore it is impossible to modify the model and the composer can not control the model, but on the other hand, the number of samples can be generated using the model is unlimited. In the opposite case, a digital model can be constructed as a physical instrument that can be used to generate different sounds that belong to the same class. The generation of different sounds is achieved through the use of parameters. Because the model represents only one specific sound generation mechanism, the number of sounds can be generated is much more limited than that of the previous model. The advantage of the second model is that the composer can control the model through the use of parameters of the model. For example, the composer can modify the pitch of a particular sound generated by changing the parameter that determines the pitch level of the sound. So in conclusion, the compactness of the class of sounds associated with a synthesis algorithm is in contrast with the playability of the algorithm. The playability of a synthesis algorithm is very important to a musician who replies on the synthesis software to compose. As most of musicians are not computer scientists any algorithms should provide an intuitive and easy access to its control parameters.
Most synthesis algorithms have different reasons for their original inception and different applicability to actual synthesis needs. That means there does not exist a general purpose algorithm that is good at everything. The usefulness of an algorithm is determined by some important factors that include the parameters the algorithm requires to work, the computational load an algorithm places on the hardware, the kinds of sounds the algorithm can produce without requiring extensive modification and/or tuning, the ease of controlling the algorithm, and the ease of implementation. Out of those the parameters is always the most important factor for an algorithm. Control parameters of a synthesis algorithm can serve different purposes. A very traditional way of the use of control parameters is to generate all the different sounds that belong to the class characterised by the algorithm. This application of parameters has become inefficient, as musicians nowadays are more concerned with other issues such as the timbral dynamics and musical expression problems. For example, timbral difference between soft (dark) and loud (brilliant) tones are usually obtained through parameter control. Algorithms must enable the composers to achieve these goals with the appropriate use of parameters.
Synthesis algorithms can be generally divided into two classes, class direct synthesis algorithms and physical modelling techniques. Some of the well-known algorithms are described as follows.
2.3.1 Direct synthesis algorithms
2.3.1.1 Sampling
Although some sounds are very difficult to synthesise with a synthesiser, it is possible to reproduce them through recording. The idea behind sampling is to store a large quantity of examples of complete sounds produced by musical instruments, then when a sound is needed just directly replay a sound from the repertoire.
Sampling has its advantages and disadvantages. On one hand, sampling is very versatile as you can almost sample every single sound with it, it is also easy and efficient to implement, leading to low cost design. Moreover, when combined with some additional processing, very convincing acoustical instrument simulations can be achieved. For example, sampling can produce very good result for drums. On the other hand, sampling requires a lot of memory and high performance computational device. Because sampling doesn't have many parameters, it is difficult to modify the sound. A common way to modify is to change the sampling speed (rate) which results in a pitch deviation and too many pitch deviations might lead to unnatural timbral modifications.
2.3.1.2 Subtractive Synthesis
Subtractive synthesis is often referred to as analogue synthesis as most analogue synthesizers employ this method to generate sounds. It starts with a complex sound that has a complex waveform, then obtain a desired sound by using a filter to remove unnecessary portions of the sound. Subtractive synthesis is a simple process, which involves the following steps in order to generate a sound,
* An Oscillator is used to generate a suitably bright sound.
* A Filter is used to cut-off or cut-down the brightness to something more suitable.
* An Amplifier is used to control the loudness of the sound over a period of time so as to emulate a natural instrument.
Diagram3.1
Because most low order filtering is very intuitive, subtractive synthesis is very easy to use. Most of its parameters also have proper psychoacoustical semantics as timbre is created by taking a proper starting waveform and shaping its spectrum with filters. Modulation is then used to adjust the sound and make it sound more lively and organic. Sounds generated by subtractive synthesis are very similar to those we used to hear. On the negative side, it is very hard to generate accurate acoustical sounds using subtractive synthesis because of its simplicity. Digital implementations are often problematic and require extensive modification and addition of features in order to sound good.
2.3.1.3 Additive Synthesis
Additive synthesis works the opposite way from subtractive synthesis. While subtractive synthesis produces a new sound by removing portions of an initial sound, additive synthesis builds a complex sound by adding simple sounds together. Additive synthesis is based on Fourier theory that is: every sound can be created by combining multiple sine waves at different frequencies, phase angles, and amplitudes.
Implementation of additive synthesis requires the creation of many sine waves. This is because most instrumental sounds include rapidly varying and stochastic components that arise from nonlinear interactions in the instruments. This structure means the synthesis ...
This is a preview of the whole essay
Additive synthesis works the opposite way from subtractive synthesis. While subtractive synthesis produces a new sound by removing portions of an initial sound, additive synthesis builds a complex sound by adding simple sounds together. Additive synthesis is based on Fourier theory that is: every sound can be created by combining multiple sine waves at different frequencies, phase angles, and amplitudes.
Implementation of additive synthesis requires the creation of many sine waves. This is because most instrumental sounds include rapidly varying and stochastic components that arise from nonlinear interactions in the instruments. This structure means the synthesis also needs to generate hundreds of partials which are all time varying and multiply interconnected. Although in theory additive synthesis can synthesize a sound perfectly, in practice, the large amount of partials make additive synthesis less efficient to implement.
Additive synthesis is probably the most versatile synthesis method in existence. Additive synthesis can produce any sounds accurately. It can also create new timbres from scratch as well as being able to analyze and re-synthesize an existing sound. Additive synthesis is also an exceptionally accurate synthesis method which can capture the slightest changes of a sound. Additive synthesis, however, requires high demand on computational resources. It also requires a large amount of control data, even in reduced form. Modification of a sound often involves large changes in synthesis parameters and this largely reduces the psychoacoustical significance of a single parameter. Also because the complex harmonic structure of a sound generated is so easy to destroy due to the difficulty of automatic spectral editing, thin sounds are often generated as a result of inappropriately change in parameter. In addition, additive synthesis takes a lot of programming time and is difficult to master.
2.3.1.4 FM Synthesis
The idea behind FM synthesis is that quite rich and deliciously time variable timbres can be created by modulating the frequency of a carrier sine oscillator by a modulator. The pattern of change comes from another waveform with a frequency in the hearing range.
Frequency modulation is a waveform is actually a technique used for radio broadcasting and was first explored in its capabilities for musical purposes. Frequency modulation requires two oscillators, one is used to modulate the frequency of the second oscillator and the output of the second one is used to listen to. There is no limit on the use of sine waves but one should remember that the more complex the modulating waveform the more complex the resulting waveform, and the most complex waveform of all is actually noise. The trick of FM is not to end up with only noise, as you can always use noise generator to generate noise directly.
FM synthesis is cost efficient and easy to implement. In addition, the control parameters are acoustically significant and easy to predict because a firm mathematical theory exists for the formation for the sidebands. Because most implementations of FM synthesis include many options and enhancements, they are very suitable for original synthesis which creates many new sounds. On the other hand, because FM synthesis has no resemblance to the formation of sound in nature, the synthesis is poor at simulating acoustical instruments and the synthesised sounds are not very realistic.
2.3.1.5 Granular Synthesis
The idea behind granular synthesis is to create rich sound textures superimposing large number of small sound grains. A grain is a unit of sonic energy possessing any waveform, and with a typical duration of a few milliseconds, near the threshold of human hearing. Granular synthesis employs a sound generation technique which combines these sound grains stochastically, with parameters such as density, mean frequency, mean length, variance and envelops of the previous controlling the overall sonic experience. This sound generation method can generate very rich timbres. Also, by using more sophisticated forms of control and substituting richer grain material, the kinds of sounds that can be generated almost become unlimited.
Granular synthesis requires a huge amount of processing power. A simple granular sound may consist of a only a small amount of particles, but a sophisticated one may be comprised of a lot more. Real-time granular synthesis requires an endless supply of grain generating devices, which are normally microcomputers capable of implementing real-time granular synthesis. These machines are expensive and are not practical for the composers to use at a regular basis.
2.3.2 Physical Modeling Synthesis
Physical modelling refers to the use of digital computers to model acoustical instruments. Instead of modelling the sounds created by instrument, modelling the instrument directly helps to understand the mechanism of the instruments and give musicians more techniques for producing sonorities and variations.
If we want to understand a physical phenomenon, we can explain it by drawing a mathematical model and describing it mathematically. Same technique can be employed in order to understand how a musical instrument works. When modelling a musical instrument, it is important to model the tonal characteristics produced by the instrument, including all of their performance gestures. Then equations can be used to model the properties of sound wave propagation caused by the instrument. For example, we can now use a powerful computer to compute in real time (while playing) the sound emits, based on typical inputs, such as breath pressure on a clarinet reed assembly or bow pressure and speed in a violin. For sound synthesis, the models must be intuitive enough so that musicians can use them easily both during composition and performance.
Physical modelling exhibits some attractive characteristics. Firstly, timbral richness is determined by the model structure rather than the complexity of parametric control. Secondly, there is a precise relationship between the reaction of the reference physical instrument to a certain action, and the reaction of its model. (Gianpaolo Borin ET AL, 1997) This means good physical models should be able to produce a certain timbral richness, as the physical instruments they reference do. For physical models. Parametric controls are very important as they reference the physical meanings the musicians have to the instrument. Controlling the physical model with the parameters should be as easy as the musicians playing the instrument themselves. Therefore the parametric controls must be intuitive for the musicians to use and less need to learn so that they can easily pick up the model. In addition, physical models also allow us to access the simulation from different points that corresponding to spatially distributed locations on the vibrating structure. This provides the musicians with more compositional parameters and flexibility in using the model.
2.3.2.1 Mechanical models
A typical mechanical model is based on the atomisation of excitation and resonance into elementary mechanical elements such as springs, masses, and frictions. These elements are connected through appropriate liaison modules that describe the interaction between the elements. Such method is suitable for simulating several vibrating structures such as strings bars and plates. On the other hand, it's computationally expensive and not s suitable for the simulation of acoustical tubes and wind instruments.
Mechanical models can describe physical structure of a resonator accurately but they rely on high computational costs, as they describe the motion of all points of the simulated system. This sometimes leads to the redundancy of parametric controls. Physical models are particularly useful for modelling elements such as the mechanical parts of a exciter.
2.3.2.2 Digital waveguides and wave digital models
Waveguide modelling represents a different approach in physical modelling, as it is based on the analytical solution of the equation that describes the propagation of perturbations in a medium (Smith, 1987). Waveguides can model complex systems such as the bore of a clarinet, or a group of strings that are coupled through a resistive bridge. Digital waveguides are very suitable for simulating flexible structure as they model the propagation of perturbations in an elastic means through the solution of the wave equation.
One of the problems with non-linear wave digital structures is that instantaneous reflections of wave variables at non-linear ports are unavoidable which makes it difficult to solve non-computability problems when connecting individually discretized elements of the structure.
2.3.3 Synthesis control signals
As mentioned before, a sound synthesis model's playability is important to the musician. When the control signal is represented by the sound itself, the number of sounds that can be generated is unlimited. When the model represents the actual mechanism of the instrument, the type of sounds that can be generated is much more limited but the model is easier for the musician to control and play. Because the musician can not physically play the instrument, he will rely on the control signals of the model during composition or performance. Control signals of a synthesis model can be categorised into two types, each responsible for a particular function. The first type of signals is responsible for the expressivity of the instrument. It allows the musician to act in a similar way as the conductor of an orchestra. The second type of signals is responsible for the spectral dynamics. It controls the spectral dynamics of the note and determines the passage from expressive parameters to the underlying algorithm.
Most instruments have limitation on the number of actions that can be performed on the instruments themselves. On a synthesis algorithm there is also a control interface which enables the musician to interact with the algorithm. The control interface contains all the information about the instrument and how to interact with it. All possible actions are mapped, in a consistent way, to a set of control parameters, which are used by the musician according to what and how he wants to perform the instrument. The use of programmable computers, allows the interface to be adapted to the needs to of the player, so that different levels of abstraction can be achieved. (Borin, 1997)
2.3.3.1 Reproduction
It is possible to transcribe control signals from a performance or from an analysis of an acoustic signal even though there is no model available. Similar to the sound synthesis sampling techniques, this technique is based on a recording-and-reproduction process. For example, the short time Fourier transform technique is used in additive synthesis for estimating model parameters from an acoustic sound in order to reproduce the original sound. The control signals obtained can then be evaluated and used for other purposes. This method though, like sound synthesis technique based on sampling, suffers from a level of rigidity. Therefore it is difficult to modify the signals generated with this method.
2.3.3.2 Learning-based synthesis
If the signal to be synthesised belongs to a class of which a variety samples is available, then it is possible to estimate parameter signals through some learning processes applied to the signal samples. For example, neural network technology ate used to construct some signal generators that can then be used to useful control signals.
2.3.3.3 Rule-based synthesis
The rule-based-synthesis assumes that it is possible to roughly model the behavior of a human performer by means of a control model operating in a symbol space rather than a signal space. The basic idea is to extract complex "behavioral rules" of a performer through a heuristic approach. The rules are then further evaluated through the analysis of the performance from acoustic samples of different performers.
There are many methods existing that can be used for synthesis of control signals. It is in practice common to find hybrid methods that combine a few methods to generate the desired control signals.
Many synthesis techniques can be used to generate the same result, some might be more suitable that others. The most important feature for a synthesis algorithm is to allow the musician to specify the control parameters to build the desired result in an intuitive manner. Without this feature the algorithm is unlikely to simulate either the composer or the performer.
2.3.4 Musical notation and interface
Computer technology has been applied to musical tasks for decades and many achievements have been made over the years. One of the most significant achievements of course is the highly sophisticated synthesis algorithms that are now used both commercially and in the literature. At the same time there are also issues remain unsolved, the problem of representing musical signals on computers is one of them. Many researchers and composers are still using virtual machine languages that have evolved from early work developed by people such as Max Mathews (Music V). These languages are however developed as tools for developing sound synthesis techniques, and not for high level compositions. Many of these languages lack an intuitive interface and are complex to use. Therefore these languages are extremely hard for the composers use as a compositional tool.
2.3.4.1 The notation problem
Computer-based music notation is a difficult issue which is still waiting for an appropriate resolution. Common musical notation has been in use for many years and at the same time, new forms of music have emerged such as electronic and computer music. As a result of the growth it is becoming more difficult to use common musical notation to handle many aspects that this kind of music requires. Many composers therefore started to create their own notations to represent their work. All these modifications however failed to make a significant impact because traditional music education and performance still depend on common music notation. The growth of new musical symbols, nevertheless, increased the rigidity of performing music. However, increased rigidity still does not guarantee more precise and repeatable performances. This is because common musical notation itself is ambiguous and inherently subjective. For example, it is hard to tell the difference between mezzoforty and pianoforte. Common musical notation can not be realised because of natural human inaccuracies (Sica, 1997). By the late 1950s experiments with computer generated sound proved that individual sonic events could be specified with precise numerical values. For example, pitch, duration, spectral content, amplitude envelope, and spatial position can all be represented with precise numbers. On the other hand, these extended possibilities of definition, control, and processing of single sonic event caused difficulties in representing globally the compositional process in a clear manner. For example, sound synthesis languages such as Csound allow great precision in the local definition of a sonic event, but on the contrary are practically unreadable in a global level. Common music notation however allows us to easily scan the overall shape of a composition.
2.3.4.1.1 Notational ambiguity
As mentioned in the previous section, the use of symbolic representations often leads to ambiguities because symbols are highly subjective. Although graphical representations of electronic and acoustic musical scores provide great precision, due to the nature of being symbolic they sometimes suffer even more ambiguities than common musical notation.
2.3.4.1.2 Macrostructure and microstructure
A flexible representation must handle both microstructure and macrostructure. Microstructure is a synonym of a basic element in a logical relationship with other elements on the same time scale, while macrostructure is a synonym of a superset that includes many of these elements (Sica 1997). Csound presents an excellent example of macrostructure and microstructure. Csound's orchestra file contains information about the instruments, while its score file describes each individual note event within specific time scale. Csound employs the granular technique, each note event in the score file defines a specific sound known as "grain" generated by the instrument in the orchestra file. This technique helps to create a well-defined hierarchy between microstructure and macrostructure.
2.3.4.1.3 Representation of musical time
The problem for representation of musical time lies in the difference between local time and global time. For example, in some graphical scores there exists a high density of points that it is impossible to distinguish them individually. This indicates a dense gathering of events that each has a short duration. Identifying these events individually requires another scale of representation, which often involving subdividing the global score into individual pages each measured in different time scale. The hierarchical structure of representation however needs to be suitably implemented for computer music. This suggests that new symbols might need to be invented to meet this requirement.
2.3.4.1.4 Representation of timbre
The representation of timbre which includes spectrum, envelope, and articulation, remains the most complex problem in computer music. In a traditional score, composers can use common notations to specify the timbre. For example, staccato can be used to note the string to play and martellato can be used to note the bow stroke. But in a computer music score, where control parameters are rigorously specified on an event by event basis, a universal notation is simply not possible for controlling the timbre of a given instrument. Graphical functions are often used to represent timbre for computer music, but the graphs they generate only give a rough idea of the timbre. Detailed analysis still needs to be carried out in order to understand the timbre evolution generated by a synthesis algorithm. Csound also provides a good example to demonstrate this problem. For example, Csound provides an opcode, which can be used to display in a curve graph, the process of modulation between two ocsil units. We can get a general idea of how the process evolves over time, but to understand more we still need study the actual data within each note event in the score file. This means there is a gap between the use of graphical representation and the actual data, when we use one of them we might lose the meaning of the other. This is only one example of the problems facing how to represent timbre. A general solution regarding this problem still remains unseen at the moment, as there are too many different approaches have been used in many programs and no agreements so far have been made on a standard solution for the problem.
2.3.4.1.5 Iconic and symbolic notation
Most software packages typically have only an iconic representation or mixed iconic-symbolic representation. Symbolic representations are familiar from text s and mathematics and seem to be too complex to use, Csound is an example for its complexity for creating its score and orchestra files. Iconic representations are intuitive and easy to use, but they do not provide the same precision and flexibility as symbolic presentations do. Also some iconic representations software packages do not allow direct performance of their instruments on the computer. Instead the sounds generated needs to be transferred to a sampler first then to be played by a performer or a sequencer. A good solution would be something combines the best of the iconic and symbolic representations, which means a program that has a user-friendly interface and is easy to use, at the same time also allows the possibility of control via a score.
2.3.4.1.6 Notation readability
New musical notation must be easily legible both in local and global ranges. The use of graphical interface and algorithmic technique should resolve the data redundant problem. A good representation must also consider performance gestures, which involves the design of a musician-machine interface.
2.3.4.2 The interface problem
One of the major interface problems is how to control the parameters of real-time synthesis. The musician must be able to control parameters such as pitch, duration, amplitude, spectrum, and spatial distribution, in a live performance. There have been many attempts on achieving maximum control over parameters by many over the time. For example, Max Mathews developed an instrument called Radio Baton three-dimensional controller. With his instrument, the computer plays the notes that are predefined by the composer and the performer controls the onset time of each note, its timbre, loudness, etc during the performance. Other people such as Robert Moog developed quite different instruments but these instruments all aim at one objective which is to develop a way in which the performer can control the parameters easily. Another important issue regarding control over parameters is the possibility of exact reproduction of performance. That is how an interface can enable the performer to reproduce the same performance. The solution for this could be achieved by neural network or by creating some sort of learning instruments, which can learn the performer's actions and reproduce them.
Based on the current experiments, Giancarlos Sica (Musical Signal Processing, 1997) suggests the future musical interface must include the following features,
* Flexibility to adapt to various situations furnished them from several different kind of sensors.
* Programmability of the feedback between the musician and the interface itself.
* The ability to generate graphical representations of the input process.
Representations of musical form and process are inherently difficult to adapt to computer technology. Although there have been many attempts by many researchers to find a general solution for the problem of musical representation. These attempts have not been successful due to the fact that representation criteria and modality are difficult to define because different people have different needs and tastes. There are also different philosophies towards resolving the problem, which make it different to agree with a general solution. What the musician actually needs towards a useful musical interface is that something which can allow the musician to control, from a high level of abstraction, all aspects of musical signal, from both musical and technical perspectives.
2.4 Musical Processing Programs
This section introduces some of the popular programs that are used by many composers.
2.4.1 Protools
Protools is a computer audio recording software which is popular among many composers. Protools is used for sound recording and sound editing for motion pictures in many studios in Hollywood.
Protools is a multi-track recorder that can record and playback 24 tracks simultaneously. Sound is represented graphically and the user can make various changes on the sound's properties. Protools has many built in effects for its user to apply on the sound they generate.
Diagram3.2
3.4.2 Max/MSP
Max/MSP was originally developed at the French National Computer Music Studio, IRCAM and is a graphical programming environment with audio processing capability. Max/MSP is capable of performing real time music processing where the system processes and playbacks musical signals in real time. Max/MSP is a powerful tool for live music performance.
Max/MSP is the combination of two separate programs: Max and MSP with Max providing the programming environment and MSP with the audio processing capability. Unlike a text-based programming language, Max/MSP allows its users to program using objects it provides. There are two types of objects in Max/MSP, regular Max objects that deal with events (such as MIDI and timing pulses), and MSP audio objects that deal with signals.
Diagram3.3
In a Max/MSP programming environment, the user does not need to write to any code, instead, the coding process is replaced with connecting the objects which are represented as boxes with each other. All the users need to do is to set the parameters and connect the objects together to generate the sounds.
2.4.3 Csound
2.4.3.1 Brief history of Csound
Boulanger (2000) describes "Csound is a powerful and versatile software program. Drawing from a toolkit of over 450 signal processing modules, one can use Csound to model virtual any commercial synthesiser or multi-effect."
Csound is a freely distributed software tool for audio synthesis, analysis and processing. Csound functions as a high level interpretative language, in which a user programs synthesis instruments in an "orchestra" file that are compiled into digital sound samples specified by note events in a "score" file. To initiate the sound generation, a user can either form a "command line" containing all the file names and other information needed to create the sound, or select program options from a window style menu.
The history of Csound can be traced back to Max Matthews' general-purpose sound synthesis programs, Music 3 and Music 4, developed at the Bell Telephone Laboratories in the early 1960s. While working as an instructor at M.I.T, Barry Vercoe developed MUSIC360 in 1968 based on Matthews' previous work. Vercoe made further improvements in 1973 to create MUSCI11 which was then the first computer music language written for a minicomputer: Digital Equipment Corporation's PDP-11. In the mid 1980s, Vercoe rewrote MUSIC11 in C programming language and called it "Csound" as it was written in C. Csound can be compiled easily on different platforms and operating systems including Windows 9x/NT and DOS, Macintosh (Power Mac and 86k), Linux and Unix (SGI and Sun).
2.4.3.2 The working process
Csound works by first translating a set of text-based instruments contained in the orchestra file into a data-structure that is machine-readable. Then it performs the instruments by interpreting the list of note events and parameters defined in the score file. The sound generated can either be auditioned in real time or written directly as a soundfile in the hard disk.
The orchestra file consists of two sections which are the header and the instrument. A Csound user specifies the rates at which the instruments are performed and the number of channels in the output in the header section. In the instrument section the user designs the instruments that are used to generate the sound.
The score file also consists of two sections which are the table and the note. A Csound user defines the function-tables by selecting Csound's mathematical function-drawing subroutines (GENS) in the table section. The user defines of the values of various performance parameters such as frequency and amplitude in the note section.
Csound users create the orchestra and score files with a text editor such as notepad and store the files in the hard disk. Csound complies the files and creates the sound file in the hard disk. The following diagram shows the basic interaction between Csound and the user, example of the score and orchestra file can be seen in Appendix D.
Diagram3.4
Csound is a large software program. The user must provide three types of information in order for Csound to work. The types of information are: the various performance parameters that set and control detailed aspects of the way Csound works, the orchestra file, and the score file. The information provided are in turn processed by Csound's three main functions: general control and house-keeping, orchestra translation and score translation.
As mentioned before the user can input the performance parameters either as "command-line flags" or options from a menu depending on the system Csound is run. Both flags and options selected from the menu determine values of the parameters controlling aspects of the way Csound works, such as the form of output, the name of the listing file used for debugging, and the quantity of the messages the Csound generates. Csound checks the validity of the parameter inputs and generates error messages when errors are found.
In the orchestra compilation process Csound first checks the syntax of the orchestra file provided and generate error messages if any serious errors are found. Csound then initialises the opcodes needed to perform the instruments and call them with note information provided in the score file.
In the score compilation process Csound performs two tasks. First, Csound sort the notes in the score file in an ascendant order in time. Second, Csound takes account of any non-numerical characters found in the score file and translates them into numeric values.
The below diagram shows how Csound works.
Diagram3.5
2.5 Requirements Specification
2.5.1 Requirement Engineering
Requirements engineering is the process of establishing the services the proposed system should provide and the constraints under which it must operate. The requirements engineering process consists of a set of activities that lead to the production of the requirements definition and requirements specification.
Requirements definition is a statement written in natural language plus diagrams of what services the system is expected to provide and the constraints under which it must operate. The requirements definition document is written using information supplied by the customer.
Requirements specification is a structured document which sets out the system services in more detail. Requirements specification is a precise document which serves as a contract between the system buyer and the system developer.
Requirements definition and requirements specification together form the requirement document of the system. The requirements definition sometimes can be presented as an introduction of the requirements specification. As a more effective approach, the requirements specification can also be presented as an appendix to the requirements definition.
There are four stages in the requirements engineering process:
* Feasibility study
The feasibility study is a study aiming at finding out whether the user needs may be satisfied using the current software and hardware technologies. The feasibility study will decide if the proposed system will be cost-effective and whether or not it can be developed under the current budgetary constraint.
* Requirements analysis
Requirements analysis is a process to derive the system requirements through a number of tasks including observation of existing system, discussions with potential system end user, detailed task analysis etc. A system model may be developed in order to help the analyst to understand the system.
* Requirements definition
Requirements definition is the process of translating the information gathered during requirements analysis into a document that defines a set of requirements. The requirements definition must be written so that it can be understood by both the end user and system customer.
* Requirement specification
Requirements specification is a detailed description of the system requirements that is to act as a basis for a contract between the client and the developer. The design and requirements activities influence each other during the development of the system. Changes on requirements might be made when errors are realised during the development.
2.5.2 Requirements Validation
Requirements validation is about finding out whether the requirements actually define the system that the customer wants. Requirements validation is important because the cost of errors in requirements is high if the errors can not be detected in the early stage of the development. If a serious error in requirements is only discovered after the system is implemented the developers will have to make a lot of changes in order to correct the error resulting in high costs.
There are a number of methods for requirements validation. In an abstract approach the clients will read the definition and specification and picture how the system would fit into their work. This is however not a practical approach since it would be difficult to validate the requirements just by imagination. Many failed systems are delivered because validation is not carried out properly. Prototyping is a more effective approach for requirements validation. The system developers will demonstrate a system model to the users and therefore allow them to have hand-on experience with the system. Requirements review is however the most effective approach for requirements validation. Requirements review can be informal or formal. An informal review involves the contractor discussing requirements with clients, and a formal review requires the development team to go through the entire system requirements with the clients explaining the implication of each requirement. When errors are identified the contract and client can negotiate a solution for the problems.
Sommervile (1995) suggests that the following aspects of requirements need to be checked the project goes any further:
* Validity
The requirements must generally meet the needs of diverse users of the system, the users of the system are likely to have different requirements and need different functions from the system. The set of requirements defined should be a compromise across the user community.
* Consistency
Any one requirement should not conflict with any other
* Completeness
The definition of requirements should include all functions and constraints intended by the users
* Realism
The requirements defined must be realistically possible to meet, considering the resources available and the technical competency of the development team.
2.5.3 Requirements Specification Document
The requirements specification document is normally presented with the system model developed during the requirements analysis. The requirements specification and the system model together should describe the system to be designed and implemented.
Although requirements specifications are often written in natural language, they always cause misunderstandings that are often not discovered until the design or the implementation phrases of the project. There are some alternatives for writing requirements specifications which can be used to reduce ambiguity.
* Structure natural language
This approach depends on defining standard forms or templates to express the requirements specification.
* Design description language
This approach uses a language that is like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.
* Requirements specification languages
Various special-purpose languages that are designed for writing requirements specification such as RSL.
* Graphical notations
Graphical notations are mostly used by specialists.
* Mathematical specifications
Notations based on a formal mathematical concept such as finite-state machines, or more basic concepts such as sets. These approach however often are too hard for customer to understand and are rarely accepted as system contracts.
Non-function requirements define system properties and constraints. Non-functional requirements are sometimes more critical than functional requirements. For example, if an aircraft is not certified as safe by the aviation authorities it simply can not be used.
There are many types of non-functional requirements and can include the following types.
* Product requirements
These are requirements that must be met in order for the delivered product to behave in a particular way. For example, the speed of the system, memory space, acceptable failure rate, and usability requirements. Product requirements are normally derived from user needs.
* Organisational requirements
These are requirements which are a consequence of organisational policies and procedures. For example, the process standard which must be used, programming languages, and method used. Organisational requirements may be derived from both the customer's and the developers' organisation.
* External requirements
These cover all requirements coming from factors external to the system and its development process. For example, the interoperability requirements for the system to interact with systems in other organisations, legislative requirements that must be followed for the system to operate within the law, and the ethical requirements to ensure that the system will be acceptable to its users and the general public.
3 Methodology
Although currently there are various software packages available either commercially or in the academies, there has not been a package that seems to be designed specifically from the perspective of professional composers. In most of the case, when designing such packages the developers place great emphasis on how to simplify the use of Csound with their graphical interfaces. On the other hand, what more important from the composer's point of view is how such interfaces can help them compose with a high level of abstraction, rather than just use Csound. In order to address this problem, a new set of user requirements had to be gathered to develop an interface that will help the composers to compose with Csound. This was done by conducting interviews with PhD students studying composition in the music department at City University. A 10-minute presentation was conducted in order to encourage the PhD students to participate in this project.
3.1 The Presentation
Invitations for interviews were initially sent out to a list of PhD students via emails. This way of communication was not very effective in getting any response and therefore a 10-minute presentation was arranged in order to give the PhD students a better understanding of the project. The presentation was conducted before the start of one of the students' seminars.
The presentation was designed to be concise in order to give a maximum amount of information without lasting too long. The presentation gave me the opportunity to introduce myself and my project to the students, therefore allowed me to motivate them to take part in the project. OHP slides were the main materials I used for the presentation and the contents of the presentation were divided into two sections. In the first section I introduced myself to the students, I also present them the title of my project, my contact details and my supervisor. The second section of the presentation included 4 key points which were important to pass to the students.
The points are as follows:
* The purpose of my project
* The reason for conducting such a project with regards to what similar software products already exist
* The structure and content of the interview
* The reward for participation
The presentation took place in the Performance Area at City University and was attended by two professors and 15 students who mostly studied composition. The presentation lasted for about 15 minutes which was longer than it was expected, due to extra time spent on discussions and answering queries from the audience. The presentation was in fact successful and positive response was received from the PhD students soon after the presentation. Presentation slides can be found in Appendix C.
3.2 Interviews
Six interviews were conducted in total. The majority of the interviewees were PhD students at City University who had extensive experience in composition and solid backgrounds in music.
NAME AND DEGREE TITLE OF INTERVIEWEES
Ian Stewart
PhD Electroacoustic Composition
Joanne May Thomas
PhD Electroacoustic Composition
Martin Stig Andersen
PhD Electroacoustic Composition
Eric Pessel
PhD Electroacoustic Composition
Katerina Tzedaki
MSc Composition
Hiromi Ishii
PhD Electroacoustic Composition
There are many fact-finding methods that can be used to collect data in system analysis and design. During this project a method which combined both interview and questionnaire was used to collect information from a number of composers. Questionnaire is a good way to get quantitative results from users, however, for this project letting the composers answer some open and closed questions on a questionnaire sent to them was simply not feasible in getting any detailed information. Interviews with the composers were held because it was the best way of finding out what they really needed from an interface to help them in composition. As well as getting answers for pre-designed questions, interviewing the composers also led to the discovery of some significant relevant information which was not thought of before the interview.
For a few reasons the preferred interviewees for the project were the PhD students who studied Composition at City University. This was because: first, City University has an excellent reputation for providing quality education in music and it is one of the first institutions in the UK to offer a range of degree courses in music study. The experience in musical teaching and research and facilities at City University made it an ideal place for carrying out this project. The project was also well co-ordinated since any assistance required would be made possible via inter-departmental communications, for example professors at the music department helped in organising the project presentation. Second, musical researchers like the PhD students were better in providing information needed by the project because they had deeper understandings in music. Although composers outside the academies could have been invited for the interviews to provide information from different perspectives, composers from the industry are often locked up in a particular type of music because of the specific areas they are engaged in, for example composers of pop music might have limited knowledge in classical music. Whereas PhD students would generally have more complete knowledge in different areas within music because of the complete education they have received. Moreover it would have been difficult to arrange an interview with composers in the industry because of the lack of contact with them. As all of the interviewees were from City University they were supervised and influenced by the same group of lecturers in the department, also they might even adopt the same set of methods and tools in composition. The similarities among them inevitably led to similar answers obtained during the interview and this became a noted weakness of the project since the findings of the interviews might be too specific to people at City University. A better approach probably could have been conducting interviews with researchers in other institutions. But again considered the number of institutions needed to visit had this approach been adopted, it would have required a large number of interviews and more time and money to carry the extra research.
The six students interviewed during the project came from very different academic backgrounds. Some of them had done all their degree courses in music throughout their studies and others studied courses in different areas such as Mathematics or Philosophy. However, they did have one thing in common which was that they all had been making music for a long time, and some of them even had been composing for more than five years. They were well informed of the latest technologies employed in composition and were familiar with a range of popular tools being used by most composers. Diverse interests also existed among them as some were more interested purely in composition and some were more into combination of composition and live performance. Their knowledge, experience, and awareness of technologies made them the ideal people to interview. Some of interviewees however, were concerned about the questions they were going to be asked because they were not familiar with Csound. Therefore it was explained during the presentation that the questions were not directly related to Csound, they were designed to gather information of what they needed.
Interviews with each student were arranged by appointments and were conducted at City University. This was because empty lecture rooms were normally available for interviews and it was also convenient to meet the students at the university. For a couple of times we did have coffee at the canteen before the interviews and this was aimed to develop an easy atmosphere between the interviewees and the interviewer.
Because the interviews were relatively informal, most of the interviews lasted actually longer that the original plans due to extensive discussions. The interviews covered their academic background, experience in composition, and career aspirations. Open questions in the questionnaire required the interviewees to explain their answers in details. One of the benefits gained from open questions for the project was that the interviewees often expanded topics and went into areas that were significant but not originally thought of during the design of the questionnaire. However, sometimes the interviewees also went too far in which case it became completely irrelevant to scope of the discussion. Closed questions were used to gained factual information such as their course title, age, and institutions had been studied at. Before the interview I purposely did not send out the questionnaires to the interviewees, this was in order to prevent bias. If the questionnaires were sent out before hand, the interviewees would think about the questions and try to give a "perfect" answer to each question. Too much thinking and re-consideration however might not reflect their real views on certain issues. Asking the interviewees unprepared questions helped to get the answers that they could only think of on the spur of the moment hence reflects more accurately their real thinking. Also when asking the interviewees questions I tried not to give them hints of some obvious answers to some questions. On one hand this was trying not to influence their thinking even though the answers might be obvious, on the other hand letting them think individually might lead to some interesting way of thinking towards certain aspects. Conversations during every interview were recorded using a mini tape recorder after gaining the permission of the interviewees. When the interviews completed the conversations were transcribed into writing in order to carry out the analysis, also the writing was the evidence of interviews carried out.
All interviewees were helpful and committed to the project and as a reward for their participation there were two CD tokens given to two interviewees who were chosen by luck draw. They were also interested in seeing the result of the research I carried out and had asked for a copy of the final outcome of the project.
Recording all the conversations in the interviews used up six 60-minute mini tapes and they were transcribed into eighteen A-4 size sheets. Copies of the sheets can be found in Appendix A.
3.3 The Questionnaire
3.3.1 Purpose of the questionnaire
The questionnaire was designed to achieve maximum impact on its subject. The goal was to ask meaningful and precise questions so as to gather useful information from the interviewees. In order to address the problems facing traditional and electronic composers separately two different questionnaires were designed for interviews with them. Each questionnaire was consisted of 14 questions. The selection of questions to ask was discussed with the supervisor of the project during the construction.
The ways in which traditional composers and electronic composers compose are very different and the methods and tools used in composition by them are also very different. Further more they might even think of sound in a totally different way, therefore it made sense to prepare different questionnaires for them. This idea was also supported by the supervisor of the project.
The style of the questionnaire was set out in a format such that different responses could be received. The majority of the questions were open questions and others were closed questions simply requiring a "Yes" or "No" answer.
3.3.2 Construction of the questionnaire
The questions were spread over two single sided A4 sheets. The number of questions was kept to minimum but without compromising obtaining maximum information, interviewees might lose patience if there were two many questions to ask so a number of between 10 or 15 questions were appropriate and it took approximately 30 to 40 minutes to answer.
The first set of questions was focused on getting general information from the composers about the way in which they compose a piece of music. The way in which a traditional composer and an electronic composer compose music is different. While traditional composers use real musical instruments to compose, electronic composers might compose in a very different way using different tools and equipment. Questions here were focused on finding out the tools that the two types of composers use in composition, the general procedures that they follow in order to generate the sounds they want to create. Whether it's for a traditional composer or an electronic composer it is always assumed that there would be some kind of bottlenecks that make some processes or procedures difficult for each individual. This is particularly the case for electronic composers as there still seems to be plenty of improvements on various musical processing programs. Therefore there were also questions designed to find out the difficulties facing composers in composition. The composers would also be asked the kind of assistance they would like to receive in order to overcome the difficulties. Finally there were some questions set out to find out the level of computer skills that the composers have. The level of technical skills between the two types of composers might be different and it is assumed that the electronic composer might have a higher level of technical skill, as computer would be involved in their compositional processes. The questions here would be asked to find out if the composers use computer in composition and how they use it to compose. It was assumed here that once the degree in which computer is involved in composition and the level of technical skill that the composers have were found out, the proposed system can be designed according to their technical competency.
The second set of questions was concerned about musical notation and interface. Overall, this project addressed the problem of musical interface and aimed to investigate the requirements for building a user friendly system for synthesis. That was, how to make an interface that was easy to create the score and orchestra files for Csound. Questions here were focused on finding out how the composer would go about creating a sound using various notations and also the kind of notations that they preferred to use in composition. Once these notations and symbols were found out then effort could be spent on investigating the feasibility of employing these notations in software synthesis and how to implement the notations in the system.
The last set of questions was concerned about sound. Here the questions were designed to find out how composers "think" of sound. The composing techniques each composer uses are different, for example, a traditional composer might start composing using a piano and finishes also with a piano. An electronic composer on the other hand has more options in choosing methods. He can start with a sound generated by piano for example, by editing the properties of the sound using various electronic equipment he then might finish with a sound that sounds like generated by a violin. The information gathered here would explain how the composers think of sound when they compose and the way in which the composers prefer to compose. The system can be designed to assist the composers to achieve their goals in the way they prefer. In other words, we can push the technologies closer to composer's side without forcing them to learn more about computers once we find out the way that is natural for them to compose. Copies of the questionnaire can been seen in Appendix B.
4 Results
Although all six interviewees studied Electroacoustic Composition some of them did traditional composition occasionally, questions regarding traditional composition were also asked during the interviews. Interviews with the six composers were tape-recorded and the conversations were transcribed and documented which can be seen in Appendix A.
NAME
AGE
EDUCATION
PROFESSION
INSTITUTION
TYPE OF COMPOSER
Ian Stewart
27
PhD
Electroacoustic Composition
City University
Electronic Composer
Joanne May Thomas
29
PhD
Electroacoustic Composition
City University
Electronic Composer
Martin Stig Andersen
28
PhD
Electroacoustic Composition
Royal Academy of Music
Electronic Composer &
Traditional Composer
Eric Pessel
24
PhD
Electroacoustic Composition
City University
Electronic Composer &
Traditional Composer
Katerina Tzedaki
38
MSc
Electroacoustic Composition
City University
Electronic Composer
Hiromi Ishii
25
PhD
Electroacoustic Composition
City University
Electronic Composer &
Traditional Composer
4.1 Questionnaire Results
A set of answers for the questions were generated after the interviews, the answers obtained from the six interviewees are as follows.
QUESTION 1: PLEASE DESCRIBE IN GENERAL HOW YOU COMPOSE A PIECE OF MUSIC?
Name
Answer
Ian Stewart
Method used to compose music changed from piece from piece for Ian. There was no fixed method for all pieces. Ian generally had a kind of concept of what piece he wanted to compose first. The concept would then guide him to the types of sound that were needed to create the piece. He then would search and collect the sound material for the piece. With a selection of musical processing programs he edited the sounds that made up the piece. Finally he would use multitrack programs to sequence the tracks and create the final piece.
Joanne May Thomas
Joanne normally had imagination of the piece in her mind. She would draw the flow and movement of the piece on her "score book". She then further specified the sounds that she wanted by analysing the flow and movement of the piece. She then would record sound materials that were similar to the sounds she wanted. She then used a selection of musical processing programs to edit the sound materials and generate the exact sounds she wanted. Finally she used mixing programs to sequence the sounds and create the final piece.
Martin Stig Andersen
Martin had an idea of the sound he wanted first and search and record the sound he wanted to use. Once he obtained the sound he wanted he would use a set of musical processing programs to filter the sound he recorded and obtained a set of separate sounds from the original sound. Then he used musical processing programs to further edit the sounds and combined the modified sounds to create the final piece.
Eric Pessel
Eric would search and record the sounds that were useful to compose the type of music he wanted e.g. dance music. Starting with the sound recorded he would select the musical processing programs to edit the sound and create the final piece with mixing programs.
Katerina Tzedaki
Katerina would first decide the music she wanted to compose and record the sound she thought that would be useful. She then would select a set of musical processing programs to edit the sound and create the final piece.
Hiromi Ishii
Hiromi was more interested in combination of electronic music and live performance. She would first create the score for the performer. She then would record the sound that was useful for the electronic music she wanted to create. She then would use a selection musical processing programs to edit the sound and create a set of fixed sound files. She would then use real time computer music programs to combine live music and the fixed sound files to create the final piece.
QUESTION 2: WHAT TOOLS DO YOU USE TO COMPOSE AT THE MOMENT?
Name
Answer
Ian Stewart
SoundHack, SoundMaker, Hyperprism, AudioSculpt, Cecilia, SuperCollider, CRM Tools, Protools
Joanne May Thomas
SoundHack, SoundMaker, AudioSculpt, Protools, TDM 5.1, SoundDesigner, Peak
Martin Stig Andersen
FFT, Protools, AudioSculpt, Peak
Eric Pessel
Protools, Peak, Hyperprism, Csound, MAX-MSP, Cubase, LogicAudio
Katerina Tzedaki
SoundEditor, Csound, C-Mix, Rt-Cmix, MAX-MSP
Hiromi Ishii
AudioSculpt, Protools, MAX-MSP, SoundMaker, SoundHack
QUESTION 3: ARE YOU SATISFIED WITH THE TOOLS YOU ARE USING?
Name
Answer
Ian Stewart
Yes
Joanne May Thomas
Yes
Martin Stig Andersen
Yes
Eric Pessel
Yes
Katerina Tzedaki
Yes
Hiromi Ishii
Yes
QUESTION4: HOW DOES COMPUTER HELP YOU IN COMPOSITION?
Name
Sound Retrieval & Storage
Sound Synthesis
Sound Transformation
Sequencing
Electronic Score Creation
Ian Stewart
*
*
*
Joanne May Thomas
*
*
*
Martin Stig Andersen
*
*
*
Eric Pessel
*
*
*
*
Katerina Tzedaki
*
*
*
*
Hiromi Ishii
*
*
*
QUESTION5: PLEASE DESCRIBE YOUR COMPUTER SKILLS?
Name
Software Development
Experience
Programming Experience In Musical Applications
Computer Literate
Computer Games
Ian Stewart
*
*
*
*
Joanne May Thomas
*
*
*
Martin Stig Andersen
*
*
Eric Pessel
*
*
*
Katerina Tzedaki
*
*
*
Hiromi Ishii
*
*
*
QUESTION 6: WHAT IS THE BOTTLENECK IN COMPOSING A PIECE OF MUSIC FOR YOU?
Name
Answer
Ian Stewart
The most difficult part in composition for Ian was at the stage of creating new sounds from old sounds. He found it difficult to create some specific effects for sounds with the musical processing programs he's currently using. Because of the limitation of the programs on certain function he wanted to have he realised he did not have enough control over his sounds. The limitations of the programs limit his ability to realise his imagination.
Joanne May Thomas
The way most musical processing programs present music on a computer screen was the major problem for Joanne. Because most programs present the evolution of sound over time on two-dimensional form, Joanne always was often confused when editing sounds. For example, if the spectrum of the sound in a time block was flat but the one in the earlier time block was high Joanne would then think that spectrum in the later time block should also be raised to the same level as the earlier one. But when she completed editing the spectrum and listened to the resulted sound, it did not actually meet her expectation. So the way in which the programs present sounds always made Joanne feel tempted to make unnecessary changes on sounds.
Martin Stig Andersen
The lack of intuition of parameters in musical processing programs was the main problem for Martin. Often when using musical processing programs to edit sounds Martin would generate very good sound effects by setting a set of parameters in the program. Martin however would often have no idea of why he achieve the effects with the parameters. For example, the set of parameters used to generate a particular effect on a sound might not generate the same effect on another. Because the lack of understanding in using the parameters Martin would not be able to comfortably apply the parameters to achieve the effects he wanted to have. Consequently he often wasted a lot time on learning the use of the parameters.
Eric Pessel
Eric's problem in composition was finding a way to synthesise new sounds without having long processes. Eric thought that a lot of the processes in musical processing programs were unnecessarily redundant which could be simplified. He thought the problem of redundant processes in musical processing programs was similar to the one facing Csound. These long processes in synthesising new sounds did not encourage composers to compose because they had to spend a lot of time on typing in code every time they wanted to create a new sound.
Katerina Tzedaki
Katerina often found that she could only use functions in the musical processing programs to work on her sounds, she could not achieve some specific sound effects with programs.
Hiromi Ishii
Hiromi found it hard to sequence the fixed sound files and live music with the programs she was using.
QUESTION 7: WHAT DO YOU NEED TO HELP YOU IN COMPOSITION?
Name
Answer
Ian Stewart
Ian would like to have more control over sounds, more functions in the program that he could use to perform on sounds to generate various effects. Although he could have complete control over sounds in Csound, because of the complexity of using it and the long processes needed to go through in order to achieve control Ian would still rather suffer from lack of control in order to avoid the complexity and long processes.
Joanne May Thomas
Joanne would prefer a better way of representing music on computer screen. The way music was represented on the screen was not necessarily the way she heard it.
Martin Stig Andersen
Martin needed intuition in parameters in various musical processing programs.
Eric Pessel
Eric would like to have more long processes to be simplified in order to save time and energy and concern more on composing.
Katerina Tzedaki
Katerina would like to have a silent and flexible compositional environment.
Hiromi Ishii
Hiromi would like to have an easier way to sequence music.
QUESTION8: WHAT TYPES OF SYMBOL OR NOTATION DO YOU USE IN COMPOSITION?
Name
Traditional Notation
Personal Notation
Ian Stewart
*
Joanne May Thomas
*
Martin Stig Andersen
*
Eric Pessel
*
Katerina Tzedaki
*
*
Hiromi Ishii
*
*
STION 9: HOW DO YOU USE THESE SYMBOLS / NOTATIONS IN COMPOSITION?
Name
Answer
Ian Stewart
Ian used a set of his personal notations to find out a form to start with his compositional process, drew it and changed it in his computer.
Joanne May Thomas
Joanne drew the flow and movement of the sound she imagined on her score book.
Martin Stig Andersen
Martin did not use any notation in composition, however he sometimes needed to transform his music in scores in order for it to be performed live.
Eric Pessel
Eric drew the flow of music on paper to remind him where his imagination was.
Katerina Tzedaki
Katerina frequently reviewed her written material that reminded her imagination and combined both types of notations to create the final piece.
Hiromi Ishii
Hiromi created the score with traditional notation and used musical processing signal to represent fixed sound files.
QUESTION 10: WHY ARE THEY (NOTATION AND SYMBOL) IMPORTANT TO YOU?
Name
Answer
Ian Stewart
Ian did not reply on notation to compose.
Joanne May Thomas
There were two reasons why notation is important for Joanne. First, she needed her notation to document her working process. Second, she needed her notation to remind her where her imagination of sound was.
Martin Stig Andersen
Notation was not important to Martin in terms of composition.
Eric Pessel
Notation was important to Eric for traditional reason because he needed it to transform his work in score. Notation was however not very important for electroacoustic composition according to him.
Katerina Tzedaki
Notation was not very important in terms of composition to Katerina, the only reason notation was involved was to use it to achieve the realisation of the composition.
Hiromi Ishii
Notation was important for Hiromi because she used it to create the score for the performer of her music.
QUESTION 11: IF YOU HAVE A SOUND IN YOUR MIND, HOW WOULD GO ABOUT CREATING IT?
Name
Answer
Ian Stewart
If there was a sound in his mind, Ian would try to record something similar to the sound and select suitable programs to edit it.
Joanne May Thomas
Joanne drew the flow and movement of the sound based on her imagination first, then she would explore different sound samples that might be useful and select one that was most similar to her imagination. She then used a selection of musical processing programs to modify the sound.
Martin Stig Andersen
Martin would try to look for the sound that had similar characteristic to the sound he imagined. When he found something similar he would record it to his computer and edit it with a selection of musical processing programs. When he realised the sound he selected was not suitable then he would continue to explore more sound samples and repeat the editing process.
Eric Pessel
Eric would start with a sound sample either chosen from his sound records or newly recorded somewhere, depending on how similar it was to his imagination. He then edited the sound with a selection of musical processing programs.
Katerina Tzedaki
Katerina would listen to sound samples and select the most similar one to his imagination and edit it with a selection of musical processing programs, She sometimes also used Csound to synthesise new sounds.
Hiromi Ishii
Hiromi would listen to sound samples and select one that had the most similar characteristics to her imagination and edit it with a selection of musical processing programs.
QUESTION 12: WHEN COMPOSING A PIECE OF MUSIC, DO YOU NORMALLY LOOK FOR A PARTICULAR SOUND THAT YOU HAVE IN MIND OR DO YOU EXPLORE A RANGE OF DIFFERENT SOUNDS FORST AND FIND THE ONE THAT YOU LIKE?
Name
Looking for a particular sound
Exploration of sound
Ian Stewart
*
Joanne May Thomas
*
Martin Stig Andersen
*
Eric Pessel
*
Katerina Tzedaki
*
*
Hiromi Ishii
*
*
QUESTION 13: WHAT TYPE OF SOUNDS THAT PARTICULARLY INTEREST YOU?
Name
Type of sounds
Ian Stewart
guitar coming form experimental pop music
Joanne May Thomas
noise based sounds have different parameters, also granular sounds
Martin Stig Andersen
big...spectrum envelop...large shape with peaks lasting for 5 seconds
Eric Pessel
strange sounds that have something to do with something real such as natural reverberation
Katerina Tzedaki
natural sounds
Hiromi Ishii
voice production of Buddhistic chant, or
reading koran, or Noh singing, 'insects' singing
QUESTION14: HOW DO YOU MODIFY A SOUND WITHIN A PIECE OF MUSIC?
Most interviewees would import their sound into their computers and edit them with a selection of musical processing programs.
QUESTION15: WHAT PROPERTIES OF SOUND DO YOU MODIFY SUCH AS PITCH, VOLUME, AND SPECTRUM?
Main properties that were modified by the interviewees included pitch, volume, spectrum, and space. The selection of properties to modify depended on the effects the interviewees wanted the sound to have.
QUESTION16: ARE THERE ANY PARTICULAR TYPES OF SOUND THAT YOU USE TO START THE COMPOSITIONAL PROCESS?
There didn't exist any particular type of sounds that the interviewees used to start with to compose. The choice of sound to start with depended on the imagination of the composers on a particular piece. The choice of sound to start with was not limited in a few types of sound.
4.2 Analysis and Discussion
The following analysis and discussion are based on the results obtained from the interviewees.
4.2.1 The compositional process and tools
Most composers interviewed during the project used a similar strategy in composition. According to the answers to question one, composition is a iterative process during which the composer repeats the sound discovery, sound transformation, and sound evaluation processes until he finally create the desired piece. Although there might be different techniques employed in each sub-process, the compositional process as a whole can be seen in the following diagram.
Diagram5.1
Most of composers normally would have an idea about the piece that they liked to compose and the idea would then guide them to look for useful sound materials. For all the composers interviewed none of them would actually use musical synthesis programs to synthesise sounds directly and the reason for this will be discussed later. Once the composers found the sound materials they would then use a set of musical processing programs to edit the sound materials, editing would involve changing the various properties of the sound materials to create the desired effects. When the editing process is completed the composers would listen to the results and decide if the sounds meet their expectations, if the sounds meet the expectations then the composers would use multitrack programs to mix the sound tracks and create the piece. Otherwise the composers would continue editing the sounds, if the results were still not acceptable then the composers would go back to the recording process and explore more sound materials and repeat the following processes.
For the composers, computer is the ultimate tool for the compositional process. They use a selection of musical processing programs to carry out the transformation process. There were nineteen musical processing programs in total mentioned in the interviews, the composers were generally satisfied with the tools that they were using although some of them indicated that they were not 100% happy with the tools and were willing to try new applications. The fact that most of the composers were happy with the tools indicates that the functions provided in these tools generally meet their requirements
The composers generally had good computer skills and most of them had used musical processing programs which require a certain level of programming e.g. Max/MSP. However, answers to questions two indicate that most of the composers preferred to use programs with graphical interfaces which require less programming tasks. More than half of the composers interviewed had used Max/MSP and one-third of them had used Csound, although very rarely would they use it for compositional purposes. According to the technical difficulty of using the programs mentioned in the interviews, they can be allocated to groups. For example, Protools, which is a purely graphical program, is in the "Non Programming" group. Max/MSP, which is half way between graphical and purely coding environment, is in the "Middle-level Programming" group. Csound, which is a text-based programming language, is in the "High-level Programming" group.
Diagram5.2
CATEGORY
PROGRAMS
NUMBER OF USER
PERCENTAGE
OF USER POPULATION
Low-level programming / Non programming
SoundHack, SoundMaker, Hyperprism, AudioSculpt, Protools, TDM 5.1, SoundDesigner, Peak, Cubase, LogicAudio, SoundEditor
6
00%
Middle-level programming
SuperCollider, Cecilia, FFT, MAX-MSP, C-Mix, Rt-Cmix,
4
67%
High-level programming
Csound
2
33%
Diagram5.3
Diagram 5.3 indicates that most composers used programs with graphical user interface, for example, almost every composer interviewed used Protools to mix tracks in the final stage of the compositional process. In contrast to this only two composers actually used Csound to compose and they mentioned that they did not use Csound very often due to the fact that it's very time consuming and difficult to use. Plus the fact that they were also far from mastering Csound therefore making it even more difficult to use. During the interview Ian Stewart gave his comments on musical programming languages including Csound. He said "...I would have complete control over my sounds in a coding environment...but if you're going to write a piece of code every time you have an idea what you want to do, it's going to be very time consuming. You have to write a separate program each time you realise a different thing you want to do, and so I would rather have a friendly application...". Joanne May Thomas also had her comments on musical programming languages, and she said "...I mean I do work very quickly...if I have to spend 3 or 4 hours at the desk just typing in code...it's going to be impossible for me to work...". The two composers' comments on musical programming languages indicated that these languages do suffer from problems which prevent the composers from using them. These may be because of the technical ability required to use them or the generic processes necessary to go though in order to use them.
Most composers experienced certain difficulties in composition with the programs they used. Because the composers preferred programs with graphical user interfaces, they had to rely heavily on the functions provided in those programs. Graphical user interface, on one hand, is a friendly environment to work with and the users will find it easier to work in such environment because everything provided is very straight forward. On the other hand, graphical user interface also suffers from the lack of flexibility and limited functionality. A common problem that exists in music graphical user interface is the lack of control over sounds. In other words, the composer is often limited in how much he can do within such an interface. Although most music graphical user interfaces nowadays provide considerably powerful functionality, they sometimes remain as the bottleneck for composers to fully realise their imaginations. As a result they have to either give up the idea or use musical programming languages. Ian Stewart mentioned his the problem with music graphical user interface. Although he was satisfied with the graphical tools he was using, sometimes he found it impossible to find a tool which would had the functionality to help him to create the sound he imagined. As a result he's going to learn Csound in order to solve the problem.
Another problem that was discovered in the interview was the way most musical processing programs represent music on a computer screen. Although the discovery might not be a significant problem as only one composer pointed it out, while others were relatively comfortable with the way music is represented. A larger scaled survey might be needed in order to justify the problem. The problem could be very subjective to specific individual, however it might suggest that there is still room for improvement on how to represent music graphically. Joanne May Thomas was often confused with the way music is represented in most musical processing programs.
Diagram5.4
For example, in the above diagram Joanne would obverse the spectrum difference between the two time blocks in shadow. Then she would think that because there is something happening in time block on the left there should also be something happening in the second time block. She would then edit the envelope in order to "synchronise" them.
Diagram5.5
However, when she finished editing the sound and listened to it, quite often she realised it was not what she was expecting.
Representation of music is important to composers when they are composing. The composers need an intuitive way of visualising music and understand it, so that they can make exactly changes on properties in order to achieve the desired effects. The representation of music must therefore allow to composer to view music from different angles considering all properties that affect how the sound will sound like. Joanne's problem was probably because she could only view music in a two dimensional form with the tools she used. Consequently she could only consider two properties of sound that affect how the sound would sound like every time she made a change.
A better way of representing music is to allow the composer to view music in a multidimensional way that allows the composers to consider more sound properties when making a change. In fact, Joanne did mentioned that she would be happier to view sound on a three-dimensional form so that she could have a better view of the sound. An example of how sound would be better visualised is seen in diagram5.6.
Diagram5.6
Parameters in musical processing programs seemed to create certain difficulties for their users. Martin Stig Andersen found it hard and time consuming to use some programs because of the lack of support for the use of their parameters. The problem for Martin was that it normally took time to test the parameters in generating a sound effect and there is no right or wrong for the effects generated by the parameters. The final decision on the sound only depends on whether the composer likes it or not. Therefore the composer could spend a lot of time in exploring the parameters. Moreover, the set of parameters used to generate an effect on sound will not necessarily generate the same effect on another. Martin often generated unexpected sound effects with the set parameters that he thought should be used. Because there was no conventional rules on how to apply the parameters, Martin always had to learn how to use the parameters every time he wanted to generate a new sound.
Although most musical processing programs provide help files on its overall functionality including the use of their parameters. The best way to learn parameters would be through listening the different sound effects generated by them. Quite often when the composer finishes editing a sound he has to wait for the program to compile the sound file so that he can hear it. A more intuitive way to help the composers would to implement real time processing. If the composer can actually change the parameter settings while the sound is being played he would have a much better understanding of how the parameters work. This in fact would be very efficient and effective way of learning parameters. However, real time processing could be difficult to achieve due to the technical difficulty and hardware requirements. If a system is to be developed with real time processing functionality, detailed feasibility study must be carried out in the first place.
4.2.2 Notation and Interface
Answers to question one show that electronic composition is totally different from the traditional way. Electronic composers only need computer, musical processing program, and sound recorder to carry out the compositional process. The fact that electronic composers rarely use score in composition means formal musical notation is not significantly important for them to compose. Answers to question eight show that most composers interviewed did not use formal musical notation in composition. The majority of composers interviewed used formal musical notations occasionally only because they had to transform their work into score for it to be performed live.
Some composers however did have their own personal notations which they used when they composed. As mentioned in the literature survey in the early chapter, these various personal notations are highly subjective to individuals which might be meaningless to others. For example, Joanne May Thomas had developed a set of her own notations which she used to remind her where her imagination was.
Diagram5.7
Most of us would not understand what the above diagram actually means and yet Joanne used this to document the flow and movement of the sound in her mind so that she could recall her imagination after a period of time.
Musical signal, on the other hand, is important in documenting electronic music. Electronic music can be represented in a two dimensional form.
Diagram5.8
For example, the above diagram shows part of a piece Hiromi Ishii composed. Hiromi was more interested in the combination of live music and fixed sound files therefore she had to create the score for the singer to perform. The above diagram shows that the singer starts singing at time "t1". The singer's voice is transformed into digital signals and processed by the computer and the signals are played back immediately after being processed. Starting at "t2" the computer starts playing fixed sound file "Seq1" which is represented by its corresponding signal until "t8".
Musical signals are therefore essential in representing and documenting sounds during the after the compositional process. Traditional musical notation, on the other hand, is unimportant from the electronic composer's point of view; unless traditional composition is also involved such as in Hiromi's compositional process.
As mentioned before the answers to question one indicated that most composers had to rely on graphical musical processing programs such as Protools. The kind of programs such as Max/MSP, which is graphical but and require the composers to some programming, is also popular among the composers. Text-based synthesis languages such as Csound are rarely used by the composers in composition due to the difficulties of using it and its time consuming processes. Graphical user interface is a friendly compositional environment and easy to use, but suffers from limited functionality. Musical synthesis languages, on the other hand, provide immense compositional power and control over sounds. An interesting finding that was discovered in the interviews was that most composers expressed their desires of learning a standard synthesis language. They had not made enough progress either because it's too difficult or time consuming. Four of the six composers interviewed however had used programs which require "Middle-level Programming". Eric Pessel mentioned "...Programs like Max/MSP which is half graphic and programming could be an example of my ideal program in composition..." he opinion might shed some light on the current development trend of musical processing programs. On one hand purely graphical user interfaces will never match the power of synthesis languages due the limitation of how much can be achieved in a graphical way, they can only provide part of the functionality of synthesis language. On the other hand, synthesis languages, if they are to be useful, must be made more user friendly and graphical user interface seems to the obvious solution. Therefore a coding environment with a suitable graphical user interface seems to be a compromised solution for the capability and usability problems. For example, the current process of building instruments in Csound may be replaced with a process using graphical icons representing the various opcodes. Instead of writing lines of codes the users can build a sophisticated instruments by simply connecting the necessary icons. Programs such as Max/MSP make use of object technologies might also suggest that there is a possibility of an object approach towards Csound interface implementation.
4.2.3 How composers think of sound
Most composers will think of sound as an idea when they compose, the idea of sound will determine the sound materials needed for composition. No composers interviewed would look at what sounds that were already available and search for an idea for composition. This means composition is a process triggered by ideas that purely depend on the composer.
Properties of sound such as pitch and spectrum need to be modified in order to generate a desired piece and the selection of properties to be modified depends on the idea of the composers, although quite often all properties need to be modified.
There is no limitation on the choice of sounds to start with the compositional process and the composers can choose any sounds for their composition. The limitation of the tools the composers use however can prevent the composers from realising their imaginations.
4.3 Results summarisation
The results of the questionnaire gives a good insight on how composers at City University compose with musical processing programs, the problems they encountered, and the needs they would like to have in order to overcome the problems they were facing. The information gathered from them can obviously be translated into a requirements specification document to design a system specifically for them. The information however might be too specific for the composers at City University and perhaps a more complete insight would have been gained by conducting another research in other institutions. This was difficult to achieve due to the constraints of the project. Moreover, most of the composers interviewed had very little experience in Csound and therefore it was difficult to find out what they expect from Csound to help them. A set of requirements was summarised based on the existing information gathered. Some requirements were based on considerations of how Csound can help the composers within the current structure they were working, therefore it is important to conduct a requirements review with the composers when the requirements are finalised to validate the requirements.
To fully utilise Csound's functionality the users inevitably has to carry out some programming tasks even within a graphical user interface. Although sophisticated and specific sound effects are likely achieved only through coding, the users can be assisted with the extra functions and facilities provided in such an interface. For example, instead of suing text editors the interface can provide a user friendly graphical environment with suitable tools such as icons and tool bar for the users to write code. When the compilation is complete the interface can graphically display the resulting soundfile so as to let the user have a better view of the sound they have just created. Instead of going back to the source code to make changes on the sound created, the interface can allow the users to make changes directly on the graphical representation of the sound, therefore avoiding the painstaking task of reading lines of code.
The set of main requirements for the proposed interface system for Csound is as follows.
* The system should be able to allow its user to import a recorded sound
* The system should be able to display a graphical representation of the sound
* The system should be able to allow the user to edit the properties of the sound graphically with appropriate tools
* The system should be able to transform the sound's graphical structure into a data structure that can be recognised and processed by Csound
* The system should have real time processing ability
* The system should provide facility for its user to program in Csound
* The system should also provide a graphical menu for its user to input various performance parameters
* The system should provide facility for the users to create the score and orchestra files
* The system should provide function for the users to sequence different sound tracks
6 Conclusions and Recommendations
6.1 Test of objective
The set of requirements gathered in the project was translated into a requirements specification document which can be seen in Appendix E. A requirements review was conducted in order to ensure that the requirements actually defined the system that the composers want. The requirements review was attended by two of the composers who were interviewed during the project. All functions stated in the requirements specification document were explained in detailed to the composers during the review, the main requirements for the review are as follows.
* Verifiability: is the requirement as stated realistically testable?
* Comprehensibility: is the requirement properly understood by the end users of the system?
* Adaptability: is the requirement adaptable?
* Traceability: is the origin of the requirement clearly stated?
The composers understood the requirements in the document properly and were happy with all functions the system would provide to help them in composition. However, there were in fact some requirements gathered during the interview which were not included in the document. For example, Joanne's requirement for three-dimensional representation of sound was not specified in the document. This was because most of the other composers did not specifically require this function and also they were fairly satisfied with the way sound was represented in the tools they were using. A two-dimensional sound representation was the compromised solution. It is however always easy to add new functions to the system, if the need for a three dimensional representation is realised later. There were also additional functions that were discovered during the review, there were later added to the document. Overall the requirements specification defined the system that the composers at City University wanted. However it is important to mention that requirements specification is not a fixed document. System design and requirement are two activities that influence each other during the development of the system, therefore requirements are likely will be adjusted at a later development stage.
6.2 Conclusions and recommendations
This project was an attempt to improve Csound's usability. Csound's problem in fact represents a common problem facing all synthesis languages. Despite their powerful functionality, composers will use these languages if they can provide an intuitive interface which allow the composers to compose with a high level of abstraction. Composers do not concern too much about what tools they use or what these tools can do, composers simply want something which can help them realise their imaginations with ease. The result of the project can only be assessed by an attempt to actually build the proposed system and analyse the feedback from the composers who have used the new system. Conclusion then can be made on how accurate these requirements are to develop the system.
In terms of the approach of utilising Csound's functions, graphical representation of timbre seems to be an appropriate choice. Graphical functions can be used to generate graphs for spectrum, envelope, etc that give the composers a very good understanding of how sound evolve over time. These graphs can then be transformed into a set of data structure that can be processed by Csound. This seems to be popular as many other musical processing programs also adopt similar approach. Nevertheless, this still does not resolve the problem of representing timbre in computer music. Although the composers understand how the sound evolves by looking at its graphical representation, but to get a complete understanding of the sound the composers still have to look at each note event. After all, the graphs do not tell the composers how the sounds will sound like. But if the composers have to look at note data every time they want to understand the sound then graphical representation will become meaningless. But despite this graphical representation is at least at the moment the best choice for timbre representation for computer music. The conclusion of a coding environment combining iconic and symbolic notation for the composers to create instruments in Csound corresponded to what was mentioned in the literature survey. The approach is similar to conventional programming languages such as Visual Basic and C++. The programming task will be easier with iconic notation facility. For example, Visual Basic is very easy for anyone to pick up because a lot of the coding tasks can be reduced by the use of "controls". Similar approach may be applied to Csound in order to reduce its difficulty. Real time interaction is an important approach to achieve control of parameters in any musical interfaces. However, this might be difficult to achieve due to the need for extensive computational power. If the system only runs on very powerful computers which is hard for the composers to get access to, the system then might not be widely used.
To validate the set of requirements gathered, the best way is to build the system based on the requirements and assess how effectiveness of the system in helping the composers. The information that was gathered in the project would serve as reference to others who attempt to tackle the same problem.
It was also realised during the project that Csound is indeed a very large program with many functions. To fully utilise Csound's functions it would be better to develop separate applications to make use of each of Csound's major functions. For example, programs can be developed separately to utilise Csound's synthesis function and signal process function.
6.3 Learning from the project
In general this was a challenging project which required a lot of learning in the field of computer music as well as discipline. The project started in early October and the learning process took up a large portion of the project period. The project was slightly delayed due to the lack of response from the composers for the interviews, and a presentation had to be conducted in order to arrange the interviews. The delay consequently reduced the time allocated for the analysis and documentation tasks, otherwise a more in depth requirements specification would have been produced in time. Nevertheless, the project was indeed very enjoyable and a lot of new knowledge was learnt during the project period. Conducting such a project is also a good practice for project management.
If the project was to be conducted again, arrangement for interviews would be the priority since managing people is always a difficult task.
References
C. Roads, S.T. Pope, A. Piccialli, and G.D. Poli. Musical Signal Processing. Swets & Zeitlinger B.V., Lisse, the Netherlands 1997.
P.R. Cook. Music, Cognition, and Computerized Sound: An Introduction to Psychoacoustics. MIT Press, Cambridge, Massachusetts London, 1999.
R. Boulanger. The Csound Book. MIT, 2000.
D. Baggi. Computer-Generated Music.IEEE Computer Society Press, 1992
I. Sommerville. Software Engineering. Addison Wesley Longman Ltd, 1995.
D. Yeats, M. Shields, and D. Helmy. System Analysis and Design. Longman Group, Londo, 1994.
A. Dix, J. Finlay, G. Abowd, and R. Beale. Human-Computer Interaction, Pearson Education, Essex, 1998.
T. Warner. Communication Skills for information Systems. Pitman London, 1996.
R. Bain. Computer-Assisted Approach to the Study of Musical Acoustics. Music Journal, University of South Carolina, 1997.
M. Pearce and G. Wiggins. Towards A Framework for the Evaluation of Machine Compositions. City University, London, 2001
M. Thies. Working with Csound. Csound Journal, Csound Magazine, 2002
H. Cole. Sounds and signs : aspects of musical notation. Oxford University Press, London, 1974
C. Williams. The story of notation. Greenwood Press, NY, 1969.
M. Gogins. Musical Graphs for Algorithmic Composition and Synthesis with An Extensible implementation In Java, NY. Http:// http://www.pipeline.com/~gogins/
R.B. Dannenberg & E. Brandt. A Flexible Real-Time Software Synthesis System. Carnegie Mellon University, 2000
A.F. Blackwell, T.R.G. Green, & D.J.E Nunn. Cognitive Dimensions and Musical notation Systems. ICMC 2000.
History of computer Music, Computer Music Articles, University of South Carolina
Http://arts.ucsc.edu/ems/music/equipment/computers/history
D. Normer. Music Modelling.1998. Http:// www.web800.com/music/vl/physmodl.htm
BC4: Yuhua Guo Confidential Requirements Investigation for
Final Project Report an Interface for Csound
Page 1
