- 1 Re: Software Art: The Learning Algorithm
- 1.1 »Software Art«
- 1.1.1 What is Software Art?
- 1.1.2 The history of Software Art
- 1.1.3 The approach of Software Art
- 1.1.4 Relations
- 1.2 Generative Art?
- 1.3 Software Studies
- 1.4 Framework culture
- 1.1 »Software Art«
- 2 References
Re: Software Art: The Learning Algorithm
/////////this is a comment, help for the structure /////////still sketchy – this is not so polished yet, especially when looking at the language, sorry!
Placing learning algorithms in the realm of Software Art enables a productive discussion about their cultural implications.
After recognizing common patterns in the discussion around Software Art / Generative Art and in the current development of machine learning algorithms I want to analyze Software Art. The insights will then be helpful in order to discuss potential approaches towards learning algorithms.
In this chapter I want to describe the approach of Software Art to then point out the important realizations of it in relation to artistic engagement with software and algorithms. Further, I will relate that insight to machine learning and current approaches towards artificial intelligence in the field of art. In a broader sense I hope this will also be applicable to other kinds of "new" algorithms.
/////////general definition of software art, tracing different opinions / movements
What is Software Art?
»The term ‘software art’ has become popular to describe the contemporary artistic preoccupation with software production« (Cox, 2007, p.147). According to Cox Software is being used as the main subject of the artwork instead of a pure tool (2007, p.147).
There are several approaches to outline Software Art. As Cramer realizes, there have been two major influences: Firstly, the group around Matthew Fuller / Graham Harwood and secondly, the movement around "Adrian Ward (whose Auto-Illustrator won the transmediale.01 software art prize) and Alex McLean (whose forkbomb.pl won the transmediale.02 software art prize) [and] the theoretician Geoff Cox", both part of the so called eu-gene group (Cramer, 2002b). "While Fuller/Harwood regard software as first of all a cultural, politically coded construct, the eu-gene group rather focuses on the formal poetics and aesthetics of software code and individual subjectivity expressed in algorithms" (Cramer, 2002b). (Later Fuller took his ideas about cultural software further, initiating Software Studies, reflecting on Software as a cultural / political phenomenon.) So this two different approaches can be used to further refine the understanding:
"[S]oftware art could be generally defined as an art of which the material is formal instruction code and/or which addresses cultural concepts of software." (Cramer, 2002b) This takes the different possible engagements into account and reflects on the main aspects of Software Art.
/////////examples on runme as support for definition of software art
runme.org is a repository that collects projects around Software Art. An attempt of definition and positioning can be found on http://runme.org/faq.tt2. It is a very practical attempt to make the engagement visible and I think it makes the definition of Software Art even clearer. What also becomes visible, unfortunately, is that the site hasn't been updated since 2012. This decline of activity can also be determined with Software Arts. But through this essay I also want to argue that this fade of attention is not due to lost relevance, but rather because of other reasons, like the use of other terms. The opposite is the case indeed, the concept of Software Art is becoming more relevant with more complex software entering our lives. In this context cultural and artistic study of these phenomena is inevitable, just like Software Art and Software Studies propose.
Thus, Software Art provides an interesting framework »describing not merely software used to produce art, but rather software itself as the artwork« (Cox, 2007, p. 147). In contrast to that, other movements that happened in the beginning of the 2000s where much broader in their focus, e.g. New Media Art. But interesting about Software Art is the specific focus on software, taking it as an - to a certain degree isolated - object of study. What is of most importance for this thesis is the framework and the approach that Software Art chooses.
The history of Software Art
/////////relation to there is no software by Kittler (find reference)
The argument of the essay might not go without referring to Kittlers "There is no Software" essay. Even though Kittler was arguing that there is no Software and it is intrinsically connected to its hardware, Cramer points out that »if any algorithm can be executed mentally, as it was common before computers were invented, then of course software can exist and run without hardware« (2002) Following this argument of Cramer this also points to the idea of software in a very conceptual way, not only defining software as a program that is running on a certain hardware.
/////////relation to conceptual art
This is also what enables Software Art to find its own pre-computational history partly in Conceptual Art. What connects them is, that they both use language as their main material, and in both "the collapsing of concept notation and execution into one piece" can be recognized (Cramer, 2002b). Connecting it to artists like Sol LeWitt, who used instructions for the execution of his artworks, not only creates a history but makes the ideas more profound and for the purpose of this essay it makes the connection between conceptual art and software art even clearer.
/////////relation to pre-software-availability artists
One reason that also contributed to the need for further engagement with software in itself, is the increase of existing software. Early computer artists had to write their own software in order to create art, while nowadays there is basically no need to write your own software to generate artistic output. (Cramer, 2002a) Even when writing your own program, there is a bunch of frameworks that abstract the actual programming. I will discuss this and its influences later on in the chapter [framework culture]. At the same time it is worth mentioning that there is rarely any work that can be done without the use of computers or software (Cramer, 2002). Every mail, every online search or even public means of transport are heavily based upon software. It’s only that we became so used to it and/or that it is hidden in invisible layers of our daily life.
»One thus could say that contemporary software art operates in a postmodern condition in which it takes pre-existing software as material — reflecting, manipulating and recontextualizing it.« (Cramer, 2002a)
"Software culture is the living culture of programmers and users, as active participants in a world of or mediated by software. In its heart it circumscribes the field of intensive immaterial production, if on the level of coding, use, speculation or critical reflection and at the periphery every aspect of human life which is somehow driven or controlled by software. Software art is reflecting the realities and potentials of this culture." Pit Schultz, from a closed mailing list discussion. -> Software that drives our life, can be also seen more and more by machine learning applications. -> Cultural discussion.
The approach of Software Art
focus on the actual thing & not take it for granted:
According to Cramer it is important to realize that artists often »take [Software] for granted« (2002). But within Software Art this shouldn’t be the case, it is rather supossed to »pay attention to how and by whom programs were written« (Cramer, 2002).
What we can see from this are important key questions and should be important for further research:
- »not take software for granted«:
- »by whom programs were written«: Google and Amazon provide infrastructures and frameworks, that are layered libraries, that make the core of the application hard to see.
- »the software itself as the artwork« (Cox, 2007, p.147)
To put focus on the process instead of the end product is not new in the art world, but Software Art exemplifies this approach »appropriate to contemporary conditions« (Cox, 2007, p.147).
This means not only the relation to the processbased approach of Software Art, that I already mentioned above, it also includes new influences, pointing for instance on performance. While the result is not nescessary a fixed product, that is visible, it can be a runtime application, that never reaches the state of finishing. An approach like this opens up new discussions and new ideas.
material vs. tool
By taking software as a primary object of study it acknowledges the role of Software in a cultural manner, and realizes that software »is not merely a functional tool, but is itself an artistic creation. (amsterdam.nettime.org/Lists-Archives/rohrpost-0101/msg00039.html) This implies also that the code, which software is made of, becomes the material [Think this is from Cox, but need to check].
software determinism: What can be seen from examples of process based art: » They demonstrate how the producer can concede control to some extent – and this is an important qualification – over the production of the work but that human intervention is paramount to (software) production« (Cox, 2007, p.150)
»Although one can of course use computers without programming them, it is impossible not to use programs at all. The question only is who programs. There is, after all, no such thing as data without programs, and hence no digital arts without the software layers they either take for granted, or design or manipulate themselves. To discuss “software art” simply means to not take software for granted, but pay attention to how and by whom programs were written« (Cramer, 2002)
Software needs Hardware to run on. »This link to performance also clarifies something about the use of the term ‘software art’, in describing not merely software used to produce art, but the software itself as the artwork.« (Cox, 2007, p.147)
Software Art & Free Software
»The first subculture which understood software as something intertextual was the Free Software and Open Source movement, i.e. the movement which produced software like GNU and Linux, from which Steven Levy’s notion of the “hacker” was largely derived.[…] GNU/Linux provides many examples of software which would be wildly successful as software art if it only were properly advertised or, if you prefer, contextualize« (Cramer, 2002a)
Why Software Art and not Algorithmic Art?
When looking at learning algorithms like deep learning and neural networks it might seem confusing to approach them within Software Art, while there is also Algorithmic Art. In its use Algorithmic Art is a sub category of Generative Art (which will be discussed later) and mainly preoccupied with visual output.
On the other hand "Software Art can base itself on a number of different levels of software: source code level, abstract algorithm level, or on the level of the product created by a given piece of code" (Arns, 2005)
This means that Software Art includes indeed algorithmic approaches, that may or may not become Software in the end. The different terms reflect more on different ways of thinking than on the actual refinement of the field specified. Software Art and Algorithmic Art of course find overlaps and intersection, but I want to emphasis that the term Software and Algorithm are not equal [a reference would be good here]. Also there is no need for binary classification, it is only that Software Art provides the more interesting approach for the use of this reseach.
not used yet
aesthetics of software art
"But as a contemporary art, the aesthetics of software art includes ugliness and monstrosity just as much as beauty, not to mention plain dysfunctionality, pretension and political incorrectness." (Cramer, 2002a)
[THIS IS STILL CHAOS]
In comparision to Software Art the term Generative Art has been around for way longer, following up on Computer Art. They both seem to have their own use and field, while the term Generative Art seems to be more popular. In this part I quickly want to elaborate on the differences between the two movements.
»[G]enerative art stress the formal rule-based and syntactical properties of software, and thus do not place sufficient emphasis on semantic concerns and social context« (Cox, 2007, p.148)
Definition by Philip Galanter:
»Generative Art refers to any art practice where the artist uses a system, such as a set of natural language rules, a computer program, a machine, or other procedural invention, which is set into motion with some degree of autonomy contributing to or resulting in a completed work of art.« (Galanter 2003)
Galanter and McCormack emphasise focus on end product
Generative Art as a term that is preoccupied by this -> a nesseciary shift towards the process, as Cox proposes »generator […] that which generates« (2007, p.151)
Inke Arns describes some key differences of Software Art and Generative Art in her essay Readme, runme, execute_me. As she points out Generative Art (following the definition of Philip Galanter, 2003):
- runs autonomously or in a self organized way
- generates unforeseeable results
"It does not regard software as a pragmatic aid that disappears behind the product it creates, but focuses on the code it contains" (Arns, 2005)
»There is broad agreement that generative art is a term applied to artwork that is automated by the use of instructions or rules by which the artwork is executed« (Cox, 2007, p.148)
There is a tension between the understanding of Generative Art and Software Art that can be productive and helpful to understand new technologies.
Next to Software Art computational phenomena are also investigated by Software Studies. While leaving out the Art it engages more with Software (in a broad sense digital objects and phenomena) on a philosophical and theoretical (?) level.
"Software Studies uses and develops cultural, theoretical, and practice-oriented approaches to make critical, historical, and experimental accounts of (and interventions via) the objects and processes of software." (Cox, 2013)
The stack of libraries and frameworks make creating a neural network super easy, but at the same time very abstract.
The question is also: what kind of programming is being used (Cox, 2007, p.153)?
As mentioned earlier former artists had to write Software to generate, nowadays Software is widely available, so it is not necessary to engage with it. This of course means a decline in engagment with software and comes with the risk to take software for granted, without qustioning it. But the positive consequence is that this frees programming from certain aspects and gives room for a new engagement, "just as previously the invention of photography perhaps freed painting from figurative representation" (Cox, 2007, p. 155)
Relation to the rawness of code. What Software Art means for the interaction with code and how code brutalism offers an interesting concept for programming.
»High-level programming approaches can be very successful in achieving certain ends, but the very imposition of higher-level constructs and metaphors also limits awareness of how code operates in and for itself and what may be achieved through that. Arguably it is the changes in low-level systems that have provoked the biggest paradigm shifts, such as the development of binary computation and Turing machines, and such as Wolfram is suggesting will be the case in fully understanding simple programs.« (Yuill 2004)
Arns, I. (2005). README , RUNME, EXECUTE_ME. In: O. Goriunova and A. Shulgin, ed., read_me: Software Art & Cultures, 1st ed. Aarhus University Press.
Cramer, F. (2002a). Contextualising Software Art. [pdf] Cramer.pleintekst.nl. Available at: http://cramer.pleintekst.nl/all/conceptnotationssoftwareart/softwaredecontextualizaton.pdf [Accessed 6 Dec. 2018].
Cramer, F. (2002). Concepts, Notations, Software, Art. [online] Cramer.pleintekst.nl. Available at: http://cramer.pleintekst.nl/all/conceptnotationssoftwareart/conceptsnotationssoftwareart.html [Accessed 6 Dec. 2018].
Cramer, F. (2003). Exe.cut[up]able statements: the Insistence of Code. in Stocker G. & Schöpf C. (eds.), Code – The Language of our time, Linz: Hatje Cantz, pp. 98-103
Cox, G. and McLean, A. (2013). Speaking code. Cambridge, Mass.: The MIT Press.
Cox, G. (2007). Generator: The Value of Software Art. In Rugg, J., & Sedgwick, M. (ed.) Issues in Curating Contemporary Art and Performance. Intellect Books, pp. 147-162.
Galanter, P. (2003). What is Generative Art?. [pdf] Available at: https://www.philipgalanter.com/downloads/ga2003_paper.pdf [Accessed 6 Dec. 2018].
Yuill S. (2004). Code Art Brutalism: Low-Level Systems and Simple Programs in Goriunova O. and Shulgin A. (ed.) Read_me: Software Art and Cultures, Aarhus:Digital Aesthetics Research Centre.