Freedom Squared

Free Improvisation in the Free Software World

by Michal Seta

Abstract

In this paper I draw a parallel, based mostly on my own experiences, between the sense of freedom involved in the use of Free Software and Free Improvisation in music. I have been making music with the Linux operating system and software libre for the past ten years. Incidentally, I have been involved with so called “free improvisation” for about the same amount of time. Recently I have given some thought to the fact that there are points, on the ideological and/or philosophical level, common to these two concepts, otherwise seemingly unrelated. For an electroacoustic musician/improviser, the use of software is simply unavoidable. Below I explain why, in my understanding, a free improviser in the context of electronic music will feel right at home with free software. This paper is simply a collection of personal reflections and thoughts about the subject.

The Setting

Music First

I would like to point out that I am writing this paper from a musician’s point of view. My music education and experience precedes that of computer science. At some point I followed the classic route: I started using a computer to notate music, then started experimenting with various computer assisted composition techniques, along the way I became interested in electroacoustic music and eventually I focused on so-called “live electronics”. Incidentally, in my various experimentations with software that was available and meant for this kind of activity I was introduced to the Linux operating system and the software available for a computer musician. At this point in time I am an end-user programmer. I like to design my own tools that complement existing software in order to accomplish my goals. I concentrate here on software but I must admit that I also explored circuit bending, designing my own electronic circuits and modifying my guitar.

I had the privilege to learn about electronic/electroacoustic music using the analog gear. I spliced tape and I used a modular Moog synthesizer. I built my own sounds and was encouraged to do so by instructors. I was taught about the value of a good initial sampling/recording. I was taught about the kind of processes that can make my sounds alive and interesting. I learned many details of sound creation, composition and manipulation in very minute details. I looked inside the sound and enjoyed manipulating it. The computer existed already at the time and many tools allowed this kind of control. But those were mid-90s. The boom of music computer software. An increasing number of ready-made tools for music-making, a lot of them cloning some analog gear or some processes. The music production was slowly becoming a race. Bedroom musicians were popping up and all kinds of self-produced music was hitting the market (and the internet, of course). By the end of the 90s we have reached a moment when just about anyone who dreamed of making music owned some kind of a home studio.

Freedom

Free Improvisation

I am mostly concerned with what Derek Bailey calls “non-idiomatic improvisation” which, in a very general way, is the kind of musical performance practice that situates itself elsewhere than the idiom of jazz, folk music, baroque, etc. In other words, a “free improviser” is not bound by the rules of one or another idiom she finds herself in but has the freedom to use whatever tools, language, musical semantics which serve the purpose of “here and now.” I write mainly from the point view of electroacoustic improvisation as this is the kind of practice that will most likely use a computer in a live performance situation.

Free Software

Free software, as advocated by Richard Stallman, the founder of Free Software Foundation and initiator of the GNU software project, is supposed to allow enough freedom to the end user or programmer to be able to modify it, adapt it to one’s needs, (re)distribute it, sell it, learn from it and allow any, unrestricted use. (1) Free/Libre Open Source Software (FLOSS) has grown in popularity throughout the late 1990s and early 2000s and it is increasingly being adopted by digital artists (Mansoux and De Valk 2008). There exist festivals devoted to artists using only free tools and promoting free artistic culture (Piksel, MakeArt, Linux Audio Conference etc.).

I do not intend to trace the history of free improvisation or free software here but I would like to focus on the meaning of the word “free” in this context. It is important to note that both free improvisation and free software share the concept of freedom. Both of the above practices stress the fact that “free” does not necessarily stand for “gratis”. (2) While open source software or open media (visuals, music, text) are often provided free of charge, the user is often expected to make some kind of contribution. The contribution could be monetary, in form of donation, there may be some paraphernalia for sale, books or manuals or other artifacts. The contribution could be in the form of the user’s time spent on submitting bugs, writing documentation or promoting the artist or the software. While some artists may make their works available online free of charge, there will certainly be a cover charge to attend a performance or to buy a hard copy of a CD or book. But the important factor is that the central idea of FLOSS is not the market model but the freedom to use, modify, redistribute (the market model can be built on such ideas afterwards as several free software distribution companies have shown in the past decade or more).

The Toolkit

The Surface

For many practical reasons the use of free software is important to the artist working in the digital domain. Having free access to the software, including the operating system, gives the necessary flexibility to manipulate the resources to one’s needs. In fact, access to any free content is (or at least should be) important to any artist. Creative work is never an individual’s cognitive process. “To a certain extent, all creativity is collaborative in that it draws from the ideas and products of past creations as raw materials, and depends on publications, audiences, collectors, etc. to propagate the new idea” (Moran, John-Steiner). In the post-modern culture we constantly remix and mashup (3) existing artifacts, and it is particularly true of music. Certain practices raise various intellectual ownership concerns but the details of legal implications are beyond the scope of this paper.

An increasing number of computer applications provide some way to extend their functionality, often beyond the intended use. Besides the obvious contenders, such as, AppleScript, Visual Basic, enormous control over spreadsheet behaviour, we have witnessed a growing number of vendors including some way of scripting or otherwise extending their applications through programming. Today, it is not uncommon that an electronic musician/composer is actually an end-user programmer. In fact, this is nothing new if one looks at the work of Max Matthews, James Tenney, Paul Lansky and others who pioneered the use of machine as a system for sound generation, composition or both. There is a plethora of systems that cater to the electronic musician. Some are based on legacy tools (Csound comes to mind), others address the needs of the modern market with spiffy graphical user interfaces and huge libraries of loops and effects that represent the current trends in music-making. Then there are hundreds of applications and systems that fall somewhere in between these two extremes. An electronic musician has a choice. Some systems are chosen for ease of use, flexibility in achieving desired results, user support, community’s support, documentation, workflow consideration, hype, maturity, user-base. Some systems are considered standard in the sense that they are in common use internationally (although they offer nothing in terms of format standardisation). Ask anyone who has ever studied sound recording and you will be instructed that Pro Tools is a de facto standard for studio use. Unfortunately, that does not hold anymore for small home studios, Pro Tools system, together with a all-powerful control surface, is out of reach for most of those who would like to create music at home. Various alternatives abound and are available in various formats and range from free (as in beer and/or freedom), shareware, adware, to commercial with various price tags attached, depending on package contents and, often, hype. However, a vast majority of today’s music software is catered towards a public that favours a point-and-click GUI (Graphical User Interface). Some offer a certain level of programming/scripting capabilities or, alternatively, some way of control over signal flow logic.

While a lot of electronic improvisation practice on a computer uses mainly real-time manipulation of pre-recorded material (such as field recordings, for example) there is a growing interest in real-time composition, synthesis and various levels of human-machine interactions. This kind of sophisticated use of computers in music requires a greater control over the data and therefore requires some kind of a programming language.

Under the Hood

For certain types of electronic improvisations the composer requires a greater control of the tool. Such types include, but are not limited to, generative music, artificial intelligence, synthesis or composition using genetic algorithms and various combinations of the above. There is also an important body of work involving various new musical interfaces, the International Conference on New Interfaces for Musical Expression (NIME) should be a good source of information to the curious reader. It goes without saying that such work cannot happen without resorting to some sort of programming language. There are various programming languages used for sound synthesis and/or composition available today that can be used in a live situation and, interestingly enough, most of them are already open source: Pure data, Csound, SuperCollider, ChucK, Faust, to name a few. All of these can be used in a FLOSS as well as commercial operating system.

There are many reasons why one may want to consider using a FLOSS operating system for such low-level musical activities. A total control over one’s environment is certainly a good reason (de Valk), the free operating system is an open book to anyone wanting to better integrate with the low-level parts of such system. One may need the kind of flexibility that will facilitate stripping the system down to a minimum to ensure the maximum CPU power is given to the DSP processes at the lowest latency. What if exercising this kind of control involves recompiling some of the system components in order to provide for better optimization? Obviously this cannot happen with a commercial, closed system.

Is it a coincidence that many live coding practitioners use/write FLOSS software? In live coding practice reusing of existing pieces of code is important.

In the context of live programming, existing bases of code by the performer and by others are an extremely valuable resource. Fragments of code are assembled like jazz licks or scratch samples. The resulting borrowings of musical intellectual property are so ubiquitous that the critical vocabulary and economic context of music production must constantly describe and attribute ownership. In contrast, the early traditions of software production are more closely based on single- authored literary works. This is clearly inappropriate in the context of some open source software development, and probably even less appropriate for the work of end-user programmers, who often borrow and adapt samples of programs created by friends and colleagues. End-user programming could benefit greatly from closer attention to the way that musical components are assembled for new audiences. (Blackwell and Collins 2005)

For end-user programmer, it is important to have access to other people’s software. End-user programmer can learn from more experienced programmers, can adopt other people’s tools and adapt them to his/her needs, he/she will then, hopefully share with other people. And then there is also collaborative live coding where several improvisers can work on the same code (that exist on the same canvas) [Zmölnig 2007]. In collaborative live coding there is the obvious immediacy of exchange of ideas, which is a basis of any improvisation. While this kind of collaborative digital instrument could be implemented in any programming language, it has arguably greater chance of survival if the users of the system have the possibility to modify and shape it in such a way that will facilitate future improvisations independently of goals set by the company providing the software.

Free Creativity

Striking a Groove

“Once empathetically attuned an atmosphere of trust allows for creative risk taking, which can result in the production of spontaneous musical utterances that may be regarded as examples of empathetic creativity” (Seddon 2004). This is regarded in jazz as “striking a groove” (Berliner 1994). This kind of attunement that Seddon is talking about could be achieved on several levels among musicians if they also collaborated on developing tools for improvisation. The collaboration does not need to be specifically programming but contributing experience, offering help, documentation, feature requests etc. to the existing body of software suitable for improvisation can enrich the tools tremendously. This kind of collaboration will most likely happen in an open source setting where source code can be investigated, corrected, tested on a regular basis and where community collaboration is already a de facto standard. While one cannot discard the genuineness of commercial software companies, it is quite relevant that the business model of commercial software is not necessarily based on providing features according to wishes of random users. Also, the testing of commercial software usually happens behind closed doors by select beta testers and features (and bug fixes!) are released in bulk and therefore at longer time intervals than in open source counterparts.

Rosenboom proposes that today music communication is shifting from that of a composer’s unilateral communication to audience’s creative experience (Rosenboom 1995). In fact he defines a composer as a “creative music maker” and gladly includes programmers, designers and listeners, to list just a few, as potential composers. What is important to note is that in recent years not only the hardware became much more accessible to those wishing to use digital technology to make music but the internet is providing increasingly cheaper and more robust ways to share information, learn, communicate, collaborate, exchange, remix, mashup etc. The existing technologies that facilitate such are perfect tools for improvising electronic musicians. Improvisers communicate, share, collaborate, exchange, remix, mashup and learn in real-time. The overlap is very clear here. The software that does not offer the necessary transparency prevents the user from “looking under the hood” and thus, quite possibly, stifles the tool’s progress and evolution. Collaboration between improvisers contributes to the enrichment of playing techniques, musical language and the overall evolution of such practice. This kind of experience can be acquired though interaction with others and, to a limited extent, through listening to archived improvisations. If one considers the case of instrumental improvisation, the tools used are well known to the players. The acoustic instruments’ properties are well known to those using them and therefore various extended techniques are easily communicated and deducted. The computer, used as a digital instrument or as an extension of an acoustic or electronic instrument, lacks that kind of transparency and intuitive deduction. Having access to source code provides to electronic improvisers the equivalent of instrumental literature and helps in understanding of historical developments as well as laying foundations for future developments.

Digital Performance Longevity

Another consideration in favour of FLOSS in relation to live electroacoustic music is the life span of scores calling for live electronics or live improvisation software. Hardware becomes obsolete. Software becomes obsolete and discontinued and often impossible to run on modern operating systems. Some music utilising live electronics composed in the 70s or 80s is nearly impossible to perform today due to the above limitations of software and hardware. The safest way to ensure that today’s performance software is runnable on future hardware and operating software is to publish its source code. Miller Puckette has initiated and effort to facilitate performance of some such historical works (Puckette 2001).

Shades of Failure

I do not mean to say that open source software is always successful. The examples of failed software abound and the reasons are as varied as the software itself. However, this also happens to commercial software. The symptoms are similar: the user will become aware that he may need to start looking for some other tool that will eventually replace the dead software, the user will continue coming up with some workarounds and continue working with a software that may be irreplaceable, the user will change his/her workflow habits and adapt some other solution or a set of solutions. If the software was useful (or known) only to a handful of people there is a strong chance that it will simply be phased out and forgotten, eventually. If there was some kind of community built around it, the community may help it to survive even if that means coming up with various workarounds to make it work with newer versions of the operating system. Open source project has a greater chance of survival. An abandoned project can always be picked up by anyone with enough skill to keep it afloat. Or an abandoned project’s source code can be picked up at any time and be adapted for a current operating system. On the other hand, there are situations that arise where the community of users or developers is divided as to the future of the project or its functionality (or even design) and a so called “fork” occurs, where another version is being created which takes a different direction with different development goals. Such forks ensure the necessary evolution of software tools without the necessity of cloning similar functionality and reinventing the wheel.

Conclusion

Using FLOSS and electroacoustic improvisation in the same sentence is still a very fresh idea. While FLOSS is gaining ground in the domain of music in general, it is too early to assess its usefulness, robustness and historical relevance, perhaps with a few exceptions of certain applications which have survived years or even decades of continual use, development and support. While I understand that changing our habits and tools is not always possible on the spur of the moment, I still think that Linux with its offering of many real-time applications is a viable choice for today’s electroacoustic improviser. The user base and users’ experience are very crucial criteria for any software’s survival and evolution. FLOSS software is sometimes far from neatly packaged commercial software in shiny boxes but risk-taking improvisers should not shy away from the unbeaten path of software adaptation. After all it is the freedom and infinite flexibility that helps us shape our moves.

Notes

1. See the article “The Free Software Definition” on the Free Software Foundation website. http://www.fsf.org/licensing/essays/free-sw.html
2. A humorous explanation of the differences of thesse terms can be found at http://c2.com/cgi/wiki?FreeAsInBeer.
3. For more info, see the Wikipedia article “Mashup.” http://en.wikipedia.org/wiki/Mashup_(music)

Bibliography

Berliner, Paul F. Thinking in Jazz : The Infinite Art of Improvisation. Chicago: The University of Chicago Press, 1994.

Blackwell, Adam and Nick Collins. “The Programming Language as a Musical Instrument.” Proceedings of the 17th Annual Workshop PPIG 2005 (Psychology of Programming Interest Group), pp. 120–130. Available on the PPIG website. http://www.ppig.org/workshops/17th-programme.html

Eigenfeldt, Arne. “Intelligent Real-time Composition.” eContact! 10.4 — Temps réel, improvisation et interactivité en électroacoustique / Live-electronics—Improvisation—Interactivity in Electroacoustics (October 2008). Canadian Electroacoustic Community. Available online at https://econtact.ca/10_4/eigenfeldt_realtime.html

de Valk, Marloes. “Tools to Fight Boredom: FLOSS and GNU/Linux for artists working in the field of generative music and software art.” Contemporary Music Review 28/1 “Generative Music” (2009). Edited by Nick Collins and Andrew R. Brown. Pre-typeset version available at http://no.systmz.goto10.org/tools-to-fight-boredom.html

Mansoux, Aymeric and Marloes De Valk (eds.). Floss+Art. City: OpenMute, 2008.

Mauro-Flude, Nancy. “Linux for Theatre Makers: Embodiment & Nix Modus Operandi.” Floss+Art. Compiled and edited by Aymeric Mansoux and Marloes de Valk. City: OpenMute, 2008. pp. 206–222.

Moran, Seana and Vera John-Steiner. “How Collaboration in Creative Work Impacts Identity and Motivation.” Collaborative Creativity, Contemporary Perspectives. Edited by Dorothy Miell and Karen Littleton. New York: Free Association Books, 2004, pp. 11–25.

Puckette, Miller. “New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics.” Proceedings of ICMC 2001.

Rosenboom, David. “Improvisation and Composition — Synthesis and Integration into the Music Curriculum.” Proceedings of The 71st Annual Meeting of the National Association of Schools of Music 1995 (Reston VA, USA). Available on the author’s website at http://music.calarts.edu/~david/writings/NASM.html

Seddon, Fred, “Empathetic Creativity: The Product of Empathectic Attunement.” Collaborative Creativity, Contemporary Perspectives. Edited by Dorothy Miell and Karen Littleton. New York: Free Association Books, 2004.

Zmölnig, IOhannes M., “Patching Music Together: Collaborative live coding in pure data.” Proceedings of the 2nd International Pd Convention, Montréal, 2007.