sdf PhD





Exploring visual representation of sound
in computer music software through
programming and composition



Selected content from
a thesis submitted with a portfolio of works to the University of Huddersfield in partial fulfilment of the requirements for the degree of Doctor of Philosophy

December 2013

Samuel David Freeman

Minor amendments
April–June 2014

3.7 Software as substance

To explore aspects of this thing we call software when it is viewed as the medium of new music, and bringing conclusion to the chapter, this section combines thoughts that were first presented in the 2010 end of year report – particularly the start of §3.7.1 and the model of composition described within §3.7.3 – with perspectives that are held at the end of the project in 2013.

A definition of the word software:

Term used for the instructions or programs executed by a computer, as opposed to the physical hardware that enables the machine to follow them. The comparison of a psychological description of a person to a software description of a machine is exploited in functionalism.
(The Oxford Dictionary of Philosophy (2 rev. ed.), Blackburn, 2008)

3.7.1 One-line programs

To some extent we can often look upon software itself as substantive of an artistic work, as for example with the following one-line BASIC program written by Noah Vawter for the Commodore 64 (C64), which was discussed by Nick Montfort in July 2010, after the release in November 2009 by Keith Fullerton Whitman of an 18 minute recording of the code running on an iPhone emulator of the C64:

10 poke 54272+int(rnd(1)*25),int(rnd(1)*256) : goto 10

The program code is given as the title of the piece and, by seeding the random number generation, it will (Montfort writes) always produce the same sequence of numbers to 'poke' into the 'memory locations beginning at 54272 [which] are mapped on the Commodore 64 to the registers of the SID (Sound Interface Device)' (Montfort, 2010).

We might think of this one-line program as a type of score to be performed by the C64, or perhaps it is a software-instrument native to the C64 which is then performed by the human user who must type RUN and press Enter to invoke the sound. I have found, while running this program within Power64 (Lieger, 2006),[n3.46] that pressing Esc will 'freeze' the audio to give a sustained sonority determined by the contents of the SID at that moment, and that sound will sustain until RUN is entered and the one-line software loop continues. This such behaviour goes little way toward that of a musically expressive instrument; Vawter's one-line BASIC program for the C64 is a limited example of software as substance, but it begins to illustrate some of the ambiguity which can accompany the question of exactly what constitutes a piece of computer music. It also serves to remind that for as long as there has been the widespread availability of programmable computers, those computers have been used for making music; see, for example, Micro-music for the Commodore 64 and BBC computer (Herman, 1985). Aesthetic appreciation of this piece by Vawter, for me, includes reflection on the influence of the Commodore 64 on my perception of technologies as a child: I remember using a C64 in the family home, and that it was a thing of some wonder that the computer would 'listen to an audio tape-cassette' in order to load programs.

[n3.46]   Power64 is a Commodore 64 emulator that I downloaded (20100729) from

Another example of the one-line program paradigm is found in the installation A Show Case for SC Tweets [sic] (Bartetzki, 2011) exhibited at the 2011 International Computer Music Conference (ICMC), featuring the audio and visual display of one-line programs for SuperCollider:[n3.47] the programme note for that installation suggesting that the SuperCollider tweets – meaning 'pieces of code limited to the short length of 140 characters' and sent via – might be thought of as 'mini compositions, smart algorithms, complex rhythms, compact soundscapes, evolving textures, syntactic adventures…', and relates the brevity of the program code to 'when composers decide to use only limited base material (a sound, a theme) as a starting point but make rich and complex pieces out of them'. Bartetzki's description supports the notion of code as the substance of a composition – of software as the medium of the work; further agreement is found with the idea that composition is about choosing limits, and then working within, and against, and around them.

[n3.47]   SuperCollider was originally developed by James McCartney (1996), 'and is now an open source (GPL) project maintained and developed by various people' (, accessed 20130818).

The pursuit of creating new worlds within worlds through computer programming (as mentioned in the introduction to this chapter), is part of a compositional strategy that seeks to narrow the realm of possibilities that a computer promises. All software-based systems are limited, and not least by the assumptions that underly the forms of representation that are used within them. The six studies described in this chapter have brought question to some of the assumptions that are involved in visual representation of sound in software, on screen, during the processes of music composition; they, and their findings, form the bedrock upon which the later works of the project emerge both technically and aesthetically.

A final example of one-line programs is included here because it is one which also features direct visual representation of the data being output as audio (which is an important idea within this project); bitop videos contribute to what Aymeric Mansoux describes as a 'bitop chiptune craze' of the time (Mansoux, 2011):[n3.48]

[n3.48]   The hyperlinks – linking to the video examples of the works with titles that are in fact the software code of the piece – are preserved in this quotation as they were within the cited source. It is of interest to note the issues, reported by Mansoux, in properly presenting these works through YouTube; but it is beyond the scope of this project to discuss those matters here.

Unfortunately Youtube was not very happy when I tried to use the shiftop codes as video titles, and it was refused even inside videos description, so here is the detailed playlist with authors:
  1. ((t>>1%128)+20)*3*t>>14*t>>18 (harism)
  2. t*(((t>>9)&10)|((t>>11)&24)^((t>>10)&15&(t>>15))) (tangent128)
  3. t*5&(t>>7)|t*3&(t*4>>10) (miiro)
  4. ((t*(t>>8|t>>9)&46&t>>8))^(t&t>>13|t>>6) (xpansive)
  5. (t*(t>>5|t>>8))>>(t>>16) (tejeez)
  6. ((t*(“36364689″[t>>13&7]&15))/12&128)+(((((t>>12)^(t>>12)-2)%11*t)/4|t>>13)&127) (ryg) […]
  7. (t*t/256)&(t>>((t/1024)%16))^t%64*(0xC0D3DE4D69>>(t>>9&30)&t%32)*t>>18 (ultrageranium)

3.7.2 Expressivity and technê in programming and composition

Toward answering the questions posed near the end of §3.5.3 – of what acts may be called 'composition' in contrast to those that may be called 'programming' – it seems false, now, to distinguish the two when the software that one is programming is specifically intended to facilitate the composition of a piece music. One may counter that perspective with the conception of a computer music programmer as a digital-luthier of sorts, and there is merit to that view, but the separation that is there suggested – between 'the instrument' and 'the piece of music' involving that instrument – fails to fit with conceptions of the art that have developed during my practice.

Programming itself can be thought of as a form of creative expressivity. In live coding, the real-time manipulation of software, at the program coder rather than end-user level, is a key aspect of the paradigm; the software medium is exposed as a malleable substance that can be shaped extemporaneously. In a different context, Mark Bokowiec (2011, p. 41) has described how, in the composition of a work, programming is one of several different forms[n3.49] of expressivity that

[n3.49]   For Bokowiec, composing V?Oct(Ritual) with the Bodycoder system, there were four integrated forms of expressivity: 'sonic (electroacoustic), programmed, gestural (kinaesonic) [and] vocal'. (Bokowiec, 2011, p. 41)

are inter-related and interact with each other in various ways and degrees. An awareness of the interconnectivity of principle forms of expressivity, their interaction and influence on each other, shapes the compositional [process].

To contextualise my own work, awareness is also brought to the interrelatedness of compositional processes, aesthetics, and the technology that is employed in the expression of these as music. While the primary focus of this project is on soundmaking software as the medium through which creativity is expressed, it is recognised that the field of computer music exists within the wider context of electronic/electroacoustic music, and that the historical discourse of these is inseparable from the technological basis of praxis.

The Greek word technê is defined as 'the knowledge of how to do things and make things' (Blackburn, 2008), and contextualisation is provided by an article by Peter Manning (2006), titled: 'The significance of techné in understanding the art and practice of electroacoustic composition'. Manning cites a 1958 paper by T. Adorno as discussing this concept in a relevant context (Manning, 2006, pp. 82–83):

The meaning of the Greek word techné from which both ‘technique’ and ‘technology’ are derived offers an indication of the unity of this concept with art. If art is the external representation of something internal, the concept of technique embraces everything which pertains to the realisation of that interior substance. In the case of music, not only the realisation of spiritual substance in the score is involved, but the transformation which makes this score accessible to sensory perception as well. In short, both production and reproduction are involved. Musical technique embraces the totality of all musical means: the organisation of the substance itself and its transformation into a physical phenomenon. (Adorno 1958: 11)[n3.50]

[n3.50]   Adorno, T. 1958. Musik und Technik. Gravesaner Blä?tter 4: 11–12.

[n3.51]   The essay – cited by Manning as: Boulez, P. 1977. Technology and the composer. Reproduced in S. Emmerson (ed.) The Language of Electroacoustic Music, pp. 5–14. London: Macmillan Press, 1986. – is available online as published in Leonardo (Boulez, 1978), and that is the version which appears in my bibliography.

[n3.52]   Di Scipio, A. 1995. Inseparable models of materials and of musical design in electroacoustic and computer music. Journal of New Music Research 24: 34–50.

Manning (ibid., p. 83) cites both Pierre Boulez (1977)[n3.51] and Agostino Di Scipio (1995)[n3.52] as having 'identified the fundamental dilemma which continually confronts electroacoustic composers' which is a question of choice: either to make use of available technologies in the realisation of compositional ideas, or (in Di Scipio's words) to 'design the tools that are necessary to realise [one's] own idea of composition?'; Boulez is cited as criticising 'the tendency to favour the former approach'. From the outset of this project, my directive has been rooted in the latter of those choices, and the pieces that have been described in this chapter, demonstrate some of the investigative steps taken toward formalising just what my own idea of composition is within this project.

Contemporary projects coming out of IRCAM, such as InkSplorer (Garcia et al., 2011), can be seen as being inline with the mission that was set out by Boulez to 'place the technology of the computer centre-stage in the quest […] for a fully integrated environment' (Manning, 2006, p. 82). In 1977, Boulez wrote: 'What is absolutely necessary is that we should move towards global, generalizable solutions' (appears as: Boulez, 1978, p. 62), but that was written at a time technologically removed from the computer as we know it today. Boulez (ibid.) also writes that:

one can imagine possible works where material and idea are brought to coincide by the final, instantaneous operation that gives them a true, provisional existence […] Certainly, the finite categories within which we are still accustomed to evolve will offer less interest when this dizzying prospect opens up: of a stored-up potential creating instant originality.
  Before we reach that point, the effort will either be collective or it will not be all. No individual, however gifted, could produce a solution to all the problems posed by the present evolution of musical expression.

Perhaps then, one may ask if that point has been reached by now? While collective efforts continue to further technological gains for all, the individual now has at their disposal the means by which to go beyond the surface of technological availability and investigate real-world manifestations of their imagination. Solution to 'all the problems' is not my objective; through critical engagement with software as substance, I seek to express something of my own technê in the composition of new works: software is conceptualised as the medium through which my computer music is made, and programming thus forms a significant part of what I do in my compositional practice. Whereas Boulez wrote in opposition to 'particular solutions that somehow remain the composer?s personal property' (ibid.) it is precisely my 'solutions' that I wish to share as contributions to knowledge.

3.7.3 Composing as an artist-programmer

It seems appropriate to accept applicability of the term artist-programmer: the artist-programmer is described, by Alex McLean (2011, p. 16), as 'directly engaging and interacting with their code as an integral aspect of their work'. The attention of McLean's thesis is directed (p. 17):

towards the intimate relationship between artist-programmers and their systems of language, understanding programming as a human interaction. The artist is considered for their role as a visionary, in exploring and extending their human experience. [McLean considers] technological support in terms of extending their vision through processes of perception and reflection in bricolage creativity.

(3.7.3.a) Bricolage programming

Much of the work in this project, in retrospect of its development, can be seen to fit closely with the conception of bricolage creativity presented by McLean. Figure 3.41, below, is from McLean's 'Figure 6.2: The process of action and reaction in bricolage programming', and of which McLean (2011, p. 122) writes that:

[it] characterises bricolage programming as a creative feedback loop encompassing the written algorithm, its interpretation, and the programmer?s perception and reaction to its output or behaviour. Creative feedback loops are far from unique to programming, but the addition of the algorithmic component makes an additional inner loop explicit between the programmer and their text. At the beginning, the programmer may have a half-formed concept, which only reaches internal consistency through the process of being expressed as an algorithm. The inner loop is where the programmer elaborates upon their imagination of what might be, and the outer where this trajectory is grounded in the pragmatics of what they have actually made.

There are two points to make here: the first is to compare that cyclical model of bricolage programming to a cyclical model of composition devised during this project, and the second is to pick up on McLeans's choice of word in referring to 'the programmer and their text' (see §3.7.4 below).

McLean's bricolage programming
Figure 3.41: McLean_bricolageprogramming

(3.7.3.b) Composition model

At the end of the first year of this project, I drafted a diagrammatic representation of a compositional model: it was the combination of (A) an introspective analysis of the ways I had previously been using software in composition, with (B) an idea of how I would like to go on to work in future. In other words, and relating back to the questions of technê above, the model was created as an attempt to clarify what my own idea of composition may be. The model has been redrawn as Figure 3.42, below. While the contents of this model had been somewhat informally defined – and were then adhered to even more loosely as the project progressed – it provides significant insight to my thinking at that time, which can now be contextualised as comparable to the more generalised understanding of creative practices provided by McLean.

My model identifies six stages of a cyclical process, beginning with abstract thought and leading to an experience of sound that, in turn, re-triggers the first item of the cycle:

  1. abstract thought;
  2. specification of concepts;
  3. implementation of specifications (as visual representations);
  4. control of data via visual representations;
  5. render performance of data control;
  6. temporal experience of the performance.

Composition Model
Figure 3.42: CompositionModel

Set as text, this cyclical model might read as follows: Abstract thought (1) can lead to the specification of particular concepts (2); these specifications are implemented in software as visual representations (3); those representations are controlled to manipulate data within the software system (4); a performance of that data control is rendered – though not necessarily in real-time (5); the rendered performance is then experienced as a real-time happening (6), and the experience of that feeds more abstract thought (1). The cycle may continue as a closed loop, but do notice that there are points of external connection (at 1 and 4) through which undefined factors may add to or divert the flow of this process. There are also paths of flow variance within the model that imply processes of internal feedback (via 1) at various stages along the cycle. A bypass of performance rendering (5) is shown because the (1–4–6–1) loop may be seen as the typical cycle of interactivity when experimenting with software, but without editing it, and before making the compositional decisions for control that based on that experience.

(3.7.3.c) Comparison of cyclical models

The autonomous and introspective origins of my composition model (Figure 3.42) are emphasised while the superimposition of it and the cited 'process of action and reaction in bricolage programming' is demonstrated in Figure 3.43:

model of composition + model of bricolage programming
Figure 3.43: model of composition + model of bricolage programming

From my aesthetically focused perspective, the close resemblance in the spatial arrangement of conceptual items in each model is appreciated as somehow reaffirming my practice based research methods in the context of more formally recognised creative processes. A structured analysis of types of creative process that are, apparently, exhibited within my work is provided by McLean with contextualisation that employs the 'Creative Systems Framework' and 'the extended mind hypothesis (Clark, 2008)'[n3.53] (McLean, 2011, pp. 124–125).

[n2.53]   Clark, A. (2008). Supersizing the Mind: Embodiment, Action, and Cognitive Extension (Philosophy of Mind Series). Oxford University Press, USA. []

3.7.4 On the context of text in programming

Further to the definition of software – cited at the start of §3.7, and which refers to the 'instructions or programs executed by a computer' – is the following written by Ge Wang, which also connects to the significant conceptual themes both of layers of abstraction, and that this is a project concerned with human activity and perception:

A program is a sequence of instructions for a computer. A programming language is a collection of syntactic and semantic rules for specifying these instructions […] The programming language acts as a mediator between human intention and the corresponding bits and instructions that make sense to a computer. It is the most general and yet the most precise tool for instructing computers.
(Wang, 2007, p. 55)

(3.7.4.a) Programming with text

Getting now to that second issue arising in the quotation given at §3.7.3.a: where McLean writes of 'the programmer and their text', the word text is loaded with significance. It is to the text of source code that reference is there being made, and the significance is contributory to the aesthetics of seeing software as substance.

It is important to note that so called 'visual programming' paradigms – such as in the MaxMSP environment – are still based on text, albeit that the text is enclosed in spatially arranged 'boxes' within the patches that comprise the source code; this is as opposed to the (rectilinear) lines of plain text that comprise source code in the more textual programming languages. Any programming language, however, 'can be considered in visual terms, we do after all normally use our eyes to read source code' (McLean, 2011, p. 103). In my quest to explore visual representation of sound in computer music software, the appearance of text, as and when it is used in code toward soundmaking, must also be considered.

The concept of programming and the concept of text are in many ways inseparable: 'computer programs were first conceived in terms of weaving', writes McLean (2011, p. 68) with reference to the Jacquard loom technology of the early-nineteenth-century – see Figure 3.44 (after Knight, 1858) – which inspired Charles Babbage[n3.54] towards 'the first conception of a programmable universal computer' (McLean, 2011, p. 13):

[n3.54]   By toughing on this aspect of computing heritage it necessary to make mention also of Ada Lovelace who is said to have been 'the first person known to have crossed the intellectual threshold between conceptualizing computing as only for calculation on the one hand, and on the other hand, computing as we know it today: with wider applications made possible by symbolic substitution.' (Fuegi and Francis, 2003, p. 16)

[n3.55]  Carpenter, E. and Laccetti, J. (2006). Open source embroidery (interview).

Although Babbage did not succeed in building the analytical engine, his design includes a similar card input mechanism to the Jacquard head, but with punched patterns describing abstract calculations rather than textile weaves. While the industrial revolution had troubling consequences, it is somewhat comforting to note this shared heritage of computer source code and cloth, which contemporary artists still reflect upon in their work (Carpenter and Laccetti, 2006).[n3.55]

Jacquard Cards
Figure 3.44: JacquardCards

Further to that shared heritage of programming for both computer and cloth, McLean (p. 68) adds that 'perhaps the same is true of writing, as the word text is a dead metaphor for cloth':

An ancient metaphor: thought is a thread, and the raconteur is a spinner of yarns – but the true storyteller, the poet, is a weaver. The scribes made this old and audible abstraction into a new and visible fact. After long practice, their work took on such an even, flexible texture that they called the written page a textus, which means cloth. (Bringhurst, 2004, p. 25)[n3.56]

[n3.56]   Bringhurst, R. (2004). The Elements of Typographic Style. Hartley & Marks Publishers, third edition.

(3.7.4.b) Source code text as a layer of abstraction

The text of source code in programming today is many layers of abstraction removed from the actual hardware that is physically controlled by it. Harman (2008) has described the layers abstraction involved for the example of a program written in Java; in Figure 3.45 I have added my understanding of the parallel layers of abstraction for the maxpat 'source code' which runs in MaxMSP:

layers of abstraction as a flow-chart
Figure 3.45: layers of abstraction

At its lowest layer of abstraction, the modern computer is a machine based on manipulation of binary changes between states typically thought of in terms of as on and off;[n3.57] programming at that level would be analogous to controlling the presence and absence of holes in a punched card control sequence for a system like that of the Jacquard loom (as the humans depicted in Figure 3.44 are shown to be doing). Multiple layers of abstraction reduce the complexity of the computer to the point where text can be used to describe algorithms in the code that then constitutes software. The artist-programmer is then at liberty to devise their own, additional, layers of abstraction in order to bring the available methods for control of the computer closer to their own conceptions of (how) reality (could be). In the creation of sdfsys – more fully described in its own chapter (§6) – a microcosm is conceptualised in which multiple levels of abstraction are represented: there is abstract access to audio hardware; there is a concept of different data types; it operates as a sort of virtual machine that is a modular system which must be programmed, via text, to do things. All of that is extending beyond what, in Figure 3.45, is the maxpat layer of abstraction.

[n3.57]   The actual behaviour of the transistors inside real hardware of a computer is 'extremely complex to model accurately. You need complex partial differential equations to even approximate the behaviour of each transistor.' (Harman, 2008). For another perspective on how transistors work see (accessed 20130801).

3.7.5 The medium is the meta-medium is the tool is the message

Given that the artist-programmer is creating new levels of abstraction with which to create, the question again is brought to mind of the distinction – if there indeed be one – between the 'tool' and the 'work'.

The following quotation from Alan Kay can be found in The Art of Human-Computer Interface Design (Laurel and Mountford, 1990, p. 225) and is also repeated by Lev Manvovich in Software Takes Command (2008, p. 83) where it is described as being 'as accurate and inspiring today as it was when Kay wrote it':[n3.58]

[n3.58]   The source – Kay, Alan (1984) “Computer Software.” Scientific American 25:3, pp. 52–9 – is cited widely, including (I thought it of interest given the above discussion of text as in textiles) by Cathy Treadaway in Textile: The Journal of Cloth and Culture (Treadaway, 2004).

It [a computer] is a medium that can dynamically simulate the details of any other medium, including media that cannot exist physically. It is not a tool, though it can act like many tools. It is the first metamedium, and as such it has degrees of freedom for representation and expression never before encountered and as yet barely investigated.

I have been writing of software as substance, and placing it as the medium with which I work, but software – or as for Kay, the computer in general – is often described as a meta-medium. Within the conclusion to his thesis, McLean describes the artist-programmer as being 'engaged closely both with their target medium, and the meta-medium of the source code' (2011, p. 150). Is not a meta-medium yet a medium itself? Approaching this subject matter is like peering down a rabbit hole upon the walls of which the words 'the medium is the message' appear in print, paint, light bulbs, needlework and laser beams,[n3.59] and into which one falls at risk of going way beyond the scope of their own domain of practice. To exclude those thought patterns from discussion, however, would be to deny an important aspect of the aesthetic contemplation that has emerged during the project.

[n3.59]   Marshall McLuhan's Understanding media: The extensions of man was first published in 1964, five years prior to the first audio controlled laser light show (see §3.3.7).

Coming from the title of the first chapter in Marshal McLuhan's many times republished book Understanding media: the extensions of man, the statement that the medium is the message has attained 'the status of clich?' (Gordon (ed.), McLuhan, 2003, p. 18), but in order to better understand the significance of working with software as substance – of a medium that is also seen as a meta-medium, and as a tool – it seems necessary to look beyond the surface of that meme. The 'message' of the substance is not found in that which it conveys because (ibid., p.31):

the “content” of any medium is always another medium. […] the “message” of any medium or technology is the change of scale or pace or pattern that it introduces into human affairs. […] “the medium is the message” because it is the medium that shapes and controls the scale and form of human association and action. The content or uses of such media are as diverse as they are ineffectual in shaping the form of human association. Indeed, it is only too typical that the “content” of any medium blinds us to the character of the medium. (McLuhan, 2003, p. 20)
[…] For the “content” of a medium is like the juicy piece of meat carried by the burglar to distract the watchdog of the mind. The effect of the medium is made strong and intense just because it is given another medium as “content.”
[…] The effects of technology do not occur at the level of opinions or concepts, but alter sense ratios or patterns of perception steadily and without any resistance. […] the only person able to encounter technology with impunity [is one who] is an expert aware of the changes in sense perception.

Douglas Rushkoff provides a more contemporary continuation of related themes; in Program or Be Programmed: Ten Commands for a Digital Age (Rushkoff, 2010), Rushkoff promotes awareness of the changes in sense perception that the now omnipresent software medium has created whilst proposing remedy to their effects.

Kim Cascone, during a presentation at the University of Huddersfield (in May 2011) speaking primarily about live performance of electroacoustic music, suggests a twist on the old McLuhan-ism (transcript from my audio recording of the presentation):

My observation over the past five years or so has been that the medium is no longer the message: the tool has become the message. Invariably people will respond by saying that 'the tool is immaterial, that you can make music with anything' and that may be true except that that isn't necessarily the case: any tool that is created for creative use is designed by somebody else – [unless] you're designing your own software – but a lot of the off-the-shelf applications are designed by engineers fighting with marketing departments [… who are] for the most part, not really of that world that they are trying to market to; […] they may be on the periphery [… but] there's always this kind of not-quite-getting-it that takes place.

So these applications that are made for the public are always designed, and the features that are revealed for the public are thought up by people, its kind of like design-by-committee; again, unless you're using MaxMSP or something and designing your own tools.

So in this way, our attention, our focus, our tools are kind of only allowing us to play in certain areas of the total features that are under the hood, and because they think 'why would anyone want to plug the stove into the refrigerator' [… because] they don't see that people want to really experiment and try weird things, they don't want those areas necessarily played with because something might break, or there's no demand for it, or they just don't see the importance […]

[The tool] directs us towards a certain type of creation […] I really have, unfortunately, come to the conclusion that the tool has really become the message, that if you are working with [off-the-shelf live performance based software] it does sort of transmit its own identity through the constraint or the subset of features and of certain types of sound or plug-ins that it comes with that tend to shape and mould the output in certain ways.

Perhaps Cascone chooses to see a tool where others choose to see a meta-medium, and where I choose just to see yet another medium; in any case, the significance here is to question the influence of the software on the creative practice. Cascone's observation appears to pose a question of whose technê is being expressed in a work of computer music: if the 'knowledge of how to do things and make things' – which is the meaning of the word technê (§3.7.2) – is built into the software, then unless it was you that built the software that you are using to make music, you may be bound to the forms of expression of someone else's technê. Inevitably – and to phrase again what has already been described – the environment in which one works to make one's own tools for working with will similarly influence that creative process by bringing its own set of biases that shape the way that things are made.

3.7.6 In software, on screen: programming/composition

The smallest visual element of the screen is the pixel that is native to a cartesian matrix and the RGB colour-space. All visual representation of sound in computer music software is built upon layers of abstraction that extend from these things. Contextualisation of the six portfolio works described in this chapter has touched upon various techno-aesthetic considerations relating to navigation of those layers of abstraction in the pursuit of computer-based musicking. The title of this thesis states that this project is an exploration conducted 'through programming and composition', and from the start of this project I have felt that these things are intrinsically linked, but more and more it seems that they are, or at least can be, the same thing.


← 3.6 saw~onepole~noise~click~

4: Spiroid →