A Modular approach to music editing
Quince is a modular, non-media-centric, open source editor that presents time-based data in a very flexible way that enables quince to be used for a multitude of applications. Because of its open and extensible structure, quince could be interesting for all those who want to perform a variety of non-standard operations on different types of time-based data in a single project. Introductions to the basic concepts of the software and to some fundamental ideas that lead to its development are presented here. 1[1. This text is not intended to cover all the functionality of quince, or serve as a tutorial or user guide. For a more comprehensive discussion of features, please refer to the documentation provided on the quince website.]
Almost all artists working with digital media ask themselves at some point: “What tools fit my needs best?” The problem that one very often encounters is that computer programmes not only carry out tasks and give us options and possibilities, but also determine the ways in which we use them. In order to find out what tools we need, we first have to find out what we actually want to do. This is not as easy as it might seem. We tend to do what technology suggests to do and sometimes we even confuse those suggestions with our own ideas. In order to find out what we really want, it is necessary to critically reflect on our use of technology and to overcome the tendency to do what our tools were made for, what is easy and convenient. In his 2009 Commencement Address at the Rhode Island School of Design, Sir Ken Robinson put it this way: “Being creative means challenging what you take for granted.” But: “The problem in challenging what you take for granted is, that you don’t know what it is, because you take it for granted.”
There are many excellent programmes available for all kinds of specialised tasks. Usually, they are solutions to one particular problem. Quince, however, is not that. The process of composing music, as I understand it, is a complex network of many interconnected tasks that have to be carried out in an ever-changing order during different stages of the manipulation of various kinds of data. Quince’s structure is designed to reflect this nonlinear approach to the working process and is therefore not bound to any particular traditional working paradigm. Its flat hierarchy and flexible modular structure offer full responsibility and control of the working process and the “treatment” of data. Moreover, quince was designed to allow the user to carry out operations not anticipated at the time of its development.
The fundamental concept of quince is a genuinely digital approach that breaks with some traditional paradigms in order to help users find suitable workflows for their own specific needs. As a result, the structure and working paradigm are very different from those of traditional editors, digital audio workstations or sequencers.
Just like the fruit of the same name, usage of the programme quince requires a certain degree of prior knowledge about its features, strengths and weaknesses, and may take some getting used to. Once one knows how to deal with it though, the results can be delicious.
Quince breaks with the classic “tape recorder and mixing board” paradigm. Every digital audio workstation presents audio data in tracks that can be mixed using a digital simulation of a mixing board. The only aspect of these models that quince does implement is the timeline. Quince does not represent data arranged in tracks and since there are no tracks, there also is no mixer to mix them. Instead, data is hosted by “strips”, vertically aligned areas containing “layers” in which data can be displayed and edited. There can be virtually any number of layers in a strip, which are displayed on top of each other (Figs. 1, 2).
Almost everything that carries out significant tasks in quince is a plugin. The views that display data, the components that play back sequences as well as functions that manipulate data are all external bundles loaded at runtime. It is not necessary to rebuild the entire programme to add new functionality.
Quince is not media centric. The only constraint about data is that it has to be time-based if it should be edited in quince. Whether an event represents an audio or video file, a note in a score or the execution of a shell script, it does not matter as long as the data being represented somehow happens in time. However, in order to be drawn and for it to play back appropriately, there need to be plugins that can understand the respective media types.
Almost every piece of software is designed in a hierarchical way, so that some functions are easier to reach and some tasks are easier to achieve than others, depending on the judgement of the programmer(s). As stated earlier, it is my belief that a programme’s structure determines the ways in which we use it. In this sense, the design of the programme — its hierarchy of functionality — has a great impact on the supposedly creative and original choices that artists or composers make while using it.
To strengthen the decisions of the user and to give her or him more freedom, quince implements a flat hierarchy in which all functionality is directly in one’s grasp. Nothing is hidden in complicated drop-down menu trees and no function is considered to be more important than any other. Of course, there are always tasks and workflows that are complicated and involve multiple steps. Quince does however offer a way to combine multiple operations into one single step in order to create more powerful tools and to simplify the utilisation of complicated operations (see the Functions and FunctionGraphs sections, below). Of course, quince is not neutral; on the contrary, my convictions are reflected in the software in a way that is far from subtle. The design of the programme does however address the issues mentioned above and seeks to offer an alternative solution.
An event in quince simply is a set of parameters. A parameter is a combination of a keyword (e.g., “volume”) and a value (e.g., 0 dB). Every event is created with a basic set of parameters like “start”, “duration” and “description” that can be extended to virtually any number. Apart from a few reserved words, any string can be used as the keyword of a parameter.
There is actually no difference between an event and a sequence in quince. Every event can contain an arbitrary number of sub-events. If an event contains sub-events, it may be regarded as a sequence. Hence, it is a question of perspective whether something is an event or a sequence, which is why the term “object” is used instead. A selection of objects (events) can always be folded into a super-object (sequence) by the push of a button. Accordingly, a sequence can always be unfolded in a similar manner.
For a better understanding of how data is being represented it might be helpful to know about a few internal data types used to distinguish between different kinds of objects:
- QuinceObject — the most basic type of object, used for events and sequences, also the supertype of all other types;
- DataFile — a reference to any kind of file;
- AudioFile — a reference to an audio file;
- Envelope — a representation of a volume envelope, typically extracted from an audio file;
- PitchCurve — a progression of frequency values;
ContainerViews are plugins that display data and provide interfaces for the editing and arrangement of objects. There are different ContainerViews available for different types of data and for the display of different parameters. While the time-related parameters (“start” and “duration”) are always assigned to the x-axis of the ContainerView, the parameter that is displayed on the y-axis is determined by the view. Every Layer contains exactly one ContainerView to show its contents.
While ContainerViews display the contents of objects, ChildViews are plugins used to graphically represent the sub-events of the object loaded by the surrounding ContainerView.
Functions are plugins that perform operations on objects. The result of the execution of a function can be:
- A new object;
- A change in the object the function operated on;
- The export of data into an external file.
There are a great variety of functions already available. Presently there are 43 functions available for such tasks as:
- Alignment of objects;
- Mapping data onto objects;
- Peak detection;
- Data conversion and extraction;
- Creating grids;
- Data reduction;
- Equal distribution of objects;
- Context sensitive corrections;
- Sorting (automated folding);
- Importing data from external programmes, including Praat and SPEAR;
- Exporting data to external programmes, including LilyPond;
- Quantisation (time and pitch);
- Set operations;
- Transposition (time and pitch).
If a function requires one or more input objects to operate (as opposed to functions which create objects without manipulating existing data), it needs an object of the correct type in each of its input slots. For example, if a function maps a PitchCurve onto a Sequence it will have two input slots: the first expecting an object of type PitchCurve and the second expecting an object of type QuinceObject upon which the PitchCurve is mapped.
There is a way to create powerful customised tools from within quince: functions can be combined, in a similar manner to the way events can be folded into sequences. Using the FunctionComposer, two Functions can be combined into a bigger unit, called a FunctionGraph. Not all combinations of functions are possible, though. Two functions are compatible if the output object of the first is of the same type as one of the input objects of the second. For example, if the output of the first function is an envelope (an object of type Envelope), and the second expects a sequence (an object of type QuinceObject), they cannot be combined. Although only two functions can be joined together at a time, much more complex FunctionGraphs can be built: FunctionGraphs behave just like functions, so it is possible to combine a Function with a FunctionGraph.
Objects are played back using “Players”, that is, plugins which interpret an object’s parameters in a certain way and produce output in real time. During playback, quince sends all the data to the currently active player plugin. How the player reacts to the incoming data is dependent on its implementation.
There are currently two players available:
- The AudioFilePlayer that interprets events as references to audio files;
- The CsoundPlayer, an actual instance of Csound that converts events into Csound score lines and performs the resulting Csound score in real time using one of the built-in Csound instruments or a custom orchestra written by the user. (The orchestra files used for the playback of sequences using the CsoundPlayer can be written directly in quince, too. Thus, quince can serve as a front end for Csound.)
Quince is released under the GNU Public License. It is written in Objective-C and can easily be extended by writing plugins (also in Objective-C). The QuinceApi is lightweight and simple to use. It was designed in such a way that in order to create a new plugin, only a minimum of administrative code has to be written. Players, Views and Functions can all be added by users to customise quince to their respective needs.
It is a well known fact that new technologies can have a great influence on the works of artists. This is of course also true the other way around: whenever art changes in respect of content and æsthetics, new tools may be required. Quince was developed to implement a new working paradigm that corresponds to new ways of composing music. Its aim is to open up new possibilities for decision-making where many other programmes only offer black-box solutions.
Although there already are a variety of plugins available for quince, there are still many more to be written: FFT and pitch detection plugins, export and import to and from various formats (MIDI, SDIF, MusicXML, to name a few), players that support video, and OSC, amongst others. So far, quince only runs on Mac OSX but it will be ported to Linux/Unix and Windows using the GNUStep framework in the future.
Boersma, Paul and David Weenink. Praat [software]. 1992. http://www.fon.hum.uva.nl/praat [Last accessed 24 August 2012]
Klingbeil, Michael. SPEAR — Sinusoidal Partial Editing Analysis and Resynthesis [software]. 2003–09. http://www.klingbeil.com/spear [Last accessed 24 August 2012]
Nienhuys, Han-Wen and Jan Nieuwenhuizen. LilyPond [software]. 1997–. http://lilypond.org [Last accessed 24 August 2012]
Robinson, Sir Ken. “Commencement Address at the Rhode Island School of Design, 2009.” YouTube video [Last accessed 24 August 2012; no longer available]