Stakeholder Groups in Computational Creativity Research and Practice - Computational Creativity Research: Towards Creative Machines - page 21

the software. All of these features have the potential to convince audience members
that software is being more sophisticated, and can be taken as a preliminary indicator
of progress.
When dealing with actual external evaluation, where people don't know what the
software does, we suggest that the diagrams above (or verbalisations/simplifications
of them) can be used to describe the software to audience members, to explain what
the software does, and what the programmer has done in the project. Audience mem-
bers can then be asked whether they would project any of the essential behaviours
from Sect. 1.4.1 onto any of the creative acts undertaken by the programmer or by
the system. Thus, one method for estimating progress from version v1 of a creative
system to version v2 that takes into account features of both processing features and
artefact quality would be:

• show audience members the diagrams for v1 and v2 as above, and explain the acts

undertaken by the software, then

• show audience members the output from v1 and v2, and,

• ask each person to compare the pair of product and process for v1 with that of v2.

A statistical analysis could then be used to see whether the audience as a whole
evaluates the output as being better, worse or the same, and whether they think that
the processing is better, worse or the same in terms of the software seeming less
uncreative.

1.5.4 A Case Study in Evolutionary Art

Evolutionary art—where software is evolved which can generate abstract art—has
been much studied within Computational Creativity circles [ 50 ]. Based on actual
projects which we reference, we hypothesise here the various timelines of progress
that could lead from a system with barely any autonomy to one with nearly full
autonomy. Figure 1.4 uses our diagrammatic approach to capture three major lines
of development, with the (hypothetical) system in box 8 representing finality, in
the strong sense that the software can do very little more creatively in generating
abstract art. Since features from earlier system epochs are often present in later ones,
we have colour-coded individual creative acts as they are introduced, so the reader can
follow their usage through the systems. If an element repeats with a slight variation
(such as the removal of a bar), this is highlighted. Table 1.1 is a key to the figure,
which describes the most important creative and administrative acts in the systems.
Elements in the key are indexed with a dot notation: system . process-stack . subprocess
(by number, from left to right, and top to bottom, respectively). System diagrams
have repetitive elements, so that the timelines leading to its construction and what it
does at run-time can be read in a stand-alone fashion.
Following the first line of development, system 1 of Fig. 1.4 represents an entry
point for many evolutionary art systems: the programmer invents ( C p ) (or borrows)
the concept formation process of crossing over sets of mathematical functions to