Software is often seen exclusively as part of the technological side of new-media art. And, indeed, all art based on computers has to lean on one and many layers of software systems enabling the artist to use and control computers and peripheral devices from an artistic perspective. Some of these layers approach extremely the realms of art production, sometimes from an operational side, others from an underlying techno-scientific knowledge layer. Certainly, the better one knows the medium with which one works, the better; the deeper the understanding of all those side fields of knowledge, the stronger, but everything has its limits, and each one has to find a boundary from which it is better to leave computer scientists and engineers that for which they are better suited. There are many artists, however, that not only deal with software at very basic levels, but that even move into the design of hardware, as a need for their artistic expression.
In my approach, a fundamental question is that the computer brought in/back the potentiality of text formalization into the composition of electroacoustic music. This has been a major achievement but a long meandering process, in which the artist has had to adjust himself to use one or other of the computer languages, following local possibilities, trends, discoveries. I had, as an example, to program in some assembly language in order to be able to make a particular musical piece. Things have changed though, and already for some decades the possibility to formalize artistic ideas into a computer language has flowed with much more ease. Being able to formalize means also, let us not forget, being influenced/inspired by the medium which one uses to express ideas.
There are two distinct levels where software acquires an undeniable artistic taint, and I will refer now exclusively to the realm of electracoustic music. In the first one the artist builds up or at least tailors a system with which to compose. This is a meta-level and, to my understanding, fundamental because it will be with this system that the artist will be able to express his ideas for one or many pieces. This is text, these are concepts, these are formalized poetics. Software has to allow the artist to express his ideas as they are thought, and not to be forced to decompose them into action procedures alla old analogue studio. As I often joke, one has to be able to express ideas in the way they are thought, in as far as one knows what kind of ideas are expressible in the medium one will be using. I assign a very important value to this meta-level, and I have personally built or collaborated in the design of many of these systems all along the years.
The second level is that of the composition itself, that in which the particular musical ideas are expressed in the frame of the underlying meta-system. This is text, these are formalized musical ideas, this is a score. Even if it may look as cryptic and as inartistic as an algorithmic function (to the layman, traditional musical notation looks as cryptic and far-away from what the senses capture), it is a score in that it describes a musical flow in a formalized way. Certainly, each particular piece will probably require its own frame, its own context, will probably require tailoring the meta-level, whether as adjustments or extensions, whether as an intermediate layer before the actual “score”, but it is at this moment, at this stage where the importance of the underlying system acquires its true signification and validity.
The CoS software
In such a specialized setup as we needed for our research, the requirement of a system addressing our particular questions was clear and notorious. However, we decided from the start, at the time of writing the proposal, that we would not attempt the building of such a system as part of our project goals. Designing and developing one such system for ‘general use’ –as an assumed goal of the project would have required– is a major work which would have consumed a large part of our energy and time in the project and many more resources that we could count with. We decided, therefore, to build only the fundamental, the basis of such an architecture, and each one would have to write his own ad hoc code for further work. With this idea in mind we wrote a joint text specifying a first approach to the fundamental layers on which it would be based. Only partly was it realized because, as I mentioned in the Introduction, the development of the VM (Virtual Mumuth) system took precedence, and that was a major development in itself.
One of the things that was implemented was the GR (Geometric Representation) layer, a basic underlying layer to our architecture, where space is codified in geometric terms. This formal representation included the possibility to act upon it through geometric transformations: an opened door to other conceptual approaches. Its importance is paramount when thinking in combining different spatialization techniques which may need one or other form of data relative to the geometry of the structure, but it is also important as an element for the visual representation of the space and the setup, and as a tool for a more abstract approach into a structured space. Having a geometrical representation of space opens up the possibility to apply virtual transformations, and create algorithms to decompose a given setup into structures and substructures. It is also a first element with which to attempt a leap into another way of dealing with space. The GR is part of the CoS-software and will be available as a SuperCollider extension, with its documentation.
The ScoreReader
Just before starting the project I built up a system, a meta-level system as described above. This ad hoc system, written for the starting CoS period, was built with a dual objective. On the one hand, to have a software platform with which to work from the very start: a system that would allow to sketch drafts, build first tests, realize experiments or even build up some more refined examples. On the other hand, it could serve as a trigger of discussion on the benefits and inconveniences of its assumptions and potential developments, helping thus to encourage reflection and invention concerning conceptual questions related to the project's topics and the design of a refined software prototype. The system derives from the original software written to create an auto-generative sound-installation piece, modified and extended later to compose multichannel pieces. Before starting the project I still developed it further to adapt it even more to its new role in this first phase of the project.
At a given moment I realized that, for different reasons, I would have to keep using it much further into the project than was the original intention, and its development had to continue with the new ideas and the new requirements that the project was posing. In the end it has been the main software system with which I have worked during the project, and although it has only been able to fulfill a certain subset of the conceptual advances of my research, it has allowed me to formalize essential questions and foresee potential paths. Its personal origin and protean history has made of it a rather obscure, unfriendly system to share amongst a community, even more so because the software was considered as a real pool for experimentation, and neatness in its design was not a principal concern.
Sharing a software system with other composers is a difficult question, for we enter a realm in which details become extremely important. How to express things? What nuances, what functionalities are there to be? Unless the system is extremely open and clear, and very well documented, and even in such circumstance, it is very probable that a colleague composer would rather absorb the ideas, the concepts, eventually a method to do or implement some functionality or other, than use the system as such, particularly when the system addresses composers who know how to code themselves. In the next paragraphs I will, therefore, comment only the fundamental concepts on which my software system, ScoreReader as I called it, is based. I am absolutely convinced that this conceptual level and the consequences and potentialities that can be extracted from them are the only important thing at this stage. I though at a certain point, and I even started the task, on writing a sort of manual, where ideas and usage information would combine to give a true view of the software –practical and conceptual–, but the demands of the project did not allow me to advance with this task. In any case, now that the project is finished, it is probably the moment to rethink the whole afresh and start implementing a new architecture.
The ScoreReader (SR) is a small software system written in SuperCollider to synthesize sound in space according to a set of parameters described in a score. Following a simple time-hierarchy structure, the system is able to synthesize sections (pre-defined blocks) or time-intervals of a score. The score basic element is a time-tagged ‘event’ (a score line) with a duration, and the basic synthesis mechanism is granular synthesis. The term event has been written between inverted commas because it does not necessarily have the meaning of a musical event, but just simply of some element in the music flow that can be formalized by itself and transcribed by the score-parameters. Score lines are grouped into sections, blocks of score-lines with certain global parameters on which the synthesis depends.
SR has two types of score-lines. The main granular synthesis score-line, and a soundfile score-line. This second one reads a multi-channel soundfile or a section of it, with sampling increment and amplitude envelope controls, and allows a relatively flexible dynamic mapping of soundfile channels into system outputs. The inclusion of this type of score-line was thought as the door to introduce elements which could have been generated by other systems. With the granular synthesis score-line one may define as much a simple element –a surface or a body– as a complex one like the Sigma-micro-object (see On the Plastic Sound Object), either static (i.e. at one single place) or dynamic (i.e. moving between places). I would only like to add here that it does not address directly a grain, but an element from a database of sets of granulation parameters associated to each grain, the idea being to approach more intuitively pre-defined classes of ‘sensual qualities’ (colour, texture, materiality).
The most characteristic aspect of SR is the way it deals with spatial processing. It is intimately linked to the idea of the Plastic Sound Object, so it will not be a surprise to learn that the basic unit is the surface, hence what I call a Group (i.e. a set of at least three speakers). As I mentioned in the Plastic Sound Object text, three-dimensional bodies are conceived only as the volume contained between two surfaces, thus SR includes mechanisms to deal with two-surfaces units. One of the global parameters of the section (a block of score-lines as described above) is a Constellation (i.e. a set of Groups) and each score-line within that section makes reference to that Constellation when describing its spatial behaviour. With a rather synthetic format the score-line describes the (dynamic) display on a surface and its evolution across surfaces. With a somewhat more complex syntax, the same can be said of bodies. The whole mechanism to deal with these relatively complex units is a unique feature of this system and although there are many developments to be done, I think it includes many interesting possibilities that make it rather powerful conceptually.
Discussion
Due to its origin as software for a generative piece as well as to the nature of the application on which it is based (SuperCollider), an algorithmic approach can substitute completely or partially the time-tagged structure of the input. Particularly, the insertion within the global score of algorithms that generate score-lines is, I think, a very interesting characteristic. To combine a “classical” score-line approach with an algorithmic one to describe the flow of music is a very powerful possibility.
Almost for the same reason, the information that the score-line requires for each of its parameters is rather flexible. The user can define the data that governs one parameter with maximum detail, or almost in a tachygraphic style, in which case internal procedures would complete the missing data. An example: the global amplitude envelope can be described with a full detailed envelope, or simply with a symbol from a list of possible shapes (but also, of course, with a number of intermediate possibilities). From an algorithmic approach to know the shape will probably be enough, but within a detailed compositional perspective, every little nuance is of maximum importance. This duality between open and close score-line descriptions is, I believe, a very important characteristic to be developed even further. Not only because sketching becomes easier, but also, and mainly, because this openness is like allowing a certain width for performance.
An internal eye has been constantly watching, during the project, at the doors to performance, and as I mentioned before, the openness of the algorithmic approach partly matches or may match the degrees of freedom assigned to performance. As a matter of fact all pieces I did during the project are slightly different every time they are played, and more different would they be were it not for technological reasons which forced me to fix more than I would have liked some of the openness.
Let me just add one more issue concerning this performance aspect. The first thing the system does is process the score. Amongst other things it reorders the score-lines in time, so that when writing the score there is no need to keep a time order. This initial global processing is at the time being relatively simple, but led me to think on the possibility of introducing some type of score-line or of cue of some type which could derive further processing of sections or lines into another type of mechanism. One such mechanism could expect, for example, some kind of external message to evaluate. Would it not be extremely interesting to be able to formalize in one same document, one same score, performing/interactive, algorithmic and fixed-score elements?
The next step should be, as I said before, to design afresh a new architecture, departing from the GR, and including as many spatial processing algorithms as possible. Building up a modular system which would profit from all that we have learnt throughout the project and include all those pointers I have been signaling in the previous paragraphs. A major task, no doubt.