Generative Creativity
Course Handbook

Introduction

Normally taken as a third-year or MSc option, Generative Creativity teaches computational methods for generating images, stories, poems, jokes, analogies and theories. Applicable theoretical issues are also covered. There are two lectures per week and a lab session in which students work through coursework exercises.

Lectures

There are two lectures per week (see Sussex Direct for times). The online notes (accessed via the `pr' links below) cover most but not all of the material. The syllabus is defined by the section headers. I find it hard to lecture to a wall of laptops so am very grateful to people who keep them shut in lectures. I will be doing attendance sign-ups for lectures and labs so please attend all sessions. Use the lab sessions (rather than email) to ask questions and make comments, but always make sure you've checked the website first.

Week 1
lec01 - Course arrangements
lec02 - The basics pr sl

Week 2
lec03 - Dice Games pr sl
lec04 - Applet graphics pr sl

Week 3
lec05 - Jokes pr sl
lec06 - Applet sound pr sl

Week 4
lec07 - Music pr sl
lec08 - Markov models pr sl

Week 5
lec09 - Soundscapes pr sl
lec10 - Generative instruments pr sl

Week 6
lec11 - Stories pr sl
lec12 - Hierarchical Markov chains pr sl

Week 7
lec13 - Images pr sl
lec14 - Aesthetics pr sl

Week 8
lec15 - Analogies pr sl
lec16 - Copycat pr sl

Week 9
lec17 - Theories pr sl
lec18 - Concept dynamics pr sl

Week 10
Demo sessions

Labs

From week 2 on, we have one lab session every week. Assessment and feedback for lab work will be through 1-to-1 mini-sessions, i.e., me coming up behind you and asking you to take me through what you're working on.

Week 2

Use google to find two examples of non-computer generative creativity not covered in the lecture.

Week 3

Having looked carefully at the code for the Blobs applet, do the first three code-modification exercises.

Week 4

Go over the code for the MovingImages applet (lec04) and make sure you understand every line. Then attempt the final exercise involving starting and stopping the animation.

Week 5

Using material from the Markov modeling lecture, generate (on paper) a 1st order Markov model for the sequence: `x z z y x x z y'. Use this model to generate a new sequence that is at least twice the length of the original. Finally, specify a sequence whose 1st order Markov model might yield the chain `a b b a'. The sequence you specify must be something other than `a b b a'.

Week 6

Look again at the lecture on Java sound and attempt the first three exercises.

Week 7

Attempt the final exercise from the Java sound lecture.

Week 8

Use this lab to work on the project from the second assignment.

Week 9

Use this lab to work on the project for your second assignment.

Week 10

This lab will be used for demo-rehearsals etc.

Assessment

Assessment for this course is 100% coursework divided between a practical assignment and an essay. There is no exam. The assignments are worth 50% each. Presentations are peer assessed, but this does not affect the formal assessment for the course. Prior to the relevant deadline I will publish peer-mark groupings on the website. From this listing you will be able to se who your peer-marker is, and who you are peer-marking for.

Essay (Thursday week 7)

The essay is due in on Thursday of week 7. This assessment is worth 50% of the marks. It should be made up from three parts, each of no more than 1000 words.

Part one should be an authoritative and critical study of the work or a particular GC practitioner. You could choose someone covered in the lectures (Cohen, Tinguely, Hofstadter, Cope etc.) or someone that you've come across in your reading or web-surfing (e.g., Brian Eno).

Part two should be a study of a particular creative genre (e.g., cubism or acid house). It should describe in detail any structural aspects of the genre which might be of use for GC purposes. For example, if the domain is drum-n-bass music, the analysis might focus on the way songs in this style are built up using particular types of rhythmic repetition and vocalisation, and the way in which exploitation of these structures might be used generatively.

Part three should be a discussion of the problem of evaluation. Your aim here should be to show that you understand what the problem of evaluation is, and why it is critical for the success of GC. If you have any ideas about how the problem might be approached in the future (particularly relating to the genre discussed in part 2), you can set them down them here but be careful to motivate any proposals that you make.

Credit will be awarded for

with the five factors being equally weighted, i.e., each one earning 20% of the overall mark.

When marking your own work, remember that marks are required for the first four criteria. You should justify the mark that you give for each criterion by cross-referencing material elsewhere in the submission. Include the self-marks as an appendix to your paper submission.

Programming assignment (Thursday week 10)

The second assignment (worth 50% of the marks) is to implement a working, generative-creativity system. You can replicate an existing system or implement something of your own design. The genre may be music, art, analogy, poetry or whatever you like. A demo of your work is required (both as an oral presentation and a web page/site) along with a conventional report following the guidelines below. The assignment is due on Thursday of week 10. You should be scheduled to demo and present your system at one of the sessions in week 10 (lab and lectures are all treated as labs in week 10). A paper sheet (to fill in informally at demos) can be accessed here.

The web-demo should take the form of a web page (html file) which uses text, images, subsidiary pages and (where possible) applets to showcase your work. You should email this to me as a zip file, whose name is lastNameFirstName.zip, replacing `lastName' and `FirstName' with your last and first name. (Note the reverse order.) I will install these somewhere accessible from the course website.

The marking scheme for this assignment is as as follows.

10% for writing (articulate, clear sentences?)

10% for discursive quality (strong arguments and debate?)

10% for presentation (figures, sections, citations, bibliog etc.?)

10% for range of research (literature used fully and critically?)

10% for system comprehensibility (modular, well-commented code?)

10% for system quality and sophistication (level of functionality)

10% for quality of output (degree of generativity and aesthetic/emotional/intellectual value)

10% for course awareness (reference to lecture discussions and digressions?)

20% for quality of self-marking (fair marks, detailed criticism?)
Self-marks are required for all criteria except `quality of self-marking'. Make sure to justify the marks you award by cross-referencing material elsewhere in the submission. Include the self-marks as an appendix to your hard-copy submission.

Feedback

I will return your paper submission to you together with a mark shouwing how well you did each of the criteria. Taking into account information on the website, it should be clear why you got the marks you did, and what you can therefore do to improve performance. If you want further clarification of the marks you received, please come to my 1-to-1 feedback session between 11 and 1 on the first monday of the Summer term. Bring along the paper copy of your submission and the marks awarded and be prepared to re-do your demo.

Peer-marking groups

Need to see up 4 peer assessors per student...

Requirements for program reports

The program report should have the following components.

1. INTRODUCTION AND BACKGROUND

An introduction to the theory, techniques, results and general area of work that the program relates to. This is where you should first attempt to justify and motivate your approach in terms of the work of others, although you may further explore such relationships in later sections.

2. ILLUSTRATION - Illustrations of the program working, with explanations. This could be based on an edited output listing, with annotations to show what is going on where. If the program uses a GUI, it could be based on a sequence of annotated screenshots. (If necessary `screenshots' can be drawn by hand. However, in this case you will need to demonstrate in some other way that the program works as described.) Edit out repetitive chunks from any program output and edit in explanatory comments. Annotate the most significant bits of the output to draw attention to them.

3. SYSTEM OVERVIEW - Explain precisely HOW the program works.

You should discuss the main steps the program goes through to achieve its results. You do not need to describe every line of the program. You should give an overview of what sorts of things are represented, how they are represented, where input comes from, how it is transformed, where output goes to, etc. The overview should refer to a copy of the program attached as appendix-1. (See below) In particular make sure you describe what kinds of objects are represented, and how you represent them (e.g. using lists, or vectors, or numerical values for variables or whatever). Explain what problems your program had to solve, and how it solved them. Use figures and diagrams productively so as to back up the text. Do not rely on an automatic documentation facility (e.g., javadoc) to write the system overview for you.

When writing the overview, don't write as if you are communicating with a tutor. Equally don't write as if for a novice. Try to write for an audience consisting of fellow students who may be a week or two behind you in their understanding. When describing what a method does, always adhere to the principles of modularity, i.e., start by stating what sorts of inputs the method takes, and what sorts of output it produces. Give an explanation of the relation between input and output, and one or two simple examples to illustrate. If there are no inputs, or no outputs, then say so.

4. LIMITATIONS

A discussion of the limitations and possible future developments. Don't be afraid to criticize your own program. If you have read about similar programs, or related programs, it may be appropriate to include some comparisons. If you have any ideas about the program could be extended, say something about that.

5. CONCLUSIONS

What lessons, if any have been learnt? Were your goals achieved? Is there anything you now think you should have done differently?

6. SELF-ASSESSMENT

This is where you make your own evaluation of the whole submission in terms of the given marking criteria. For each criterion, note how well you think you've done (and why) and give yourself a mark.

7. BIBLIOGRAPHY

List books, articles, web pages, files etc. considered to be relevant.

8. Appendix 1: The whole program, with comments explaining what the classes represent, what the methods do, what the global variables (if any) are for, etc.

Factors affecting system comprehensibility

The comprehensibility of your code is largely a function of the following factors.

  1. modularity: modular programs are made up from small, independent components (typically methods) that can be tested and debugged in isolation from the rest of the program. Such components get their data via formal input parameters. They only affect the rest of the program via the formal outputs (results) they return. They are, in effect, `black boxes'. Once validated, they can be eliminated from the debugging process. Modular programs make little or no use of variables for purposes of communication information from one part of the program to another. Writing your program in a modular way is a divide-and-conquer strategy. There is really no other way to do it.
  2. simplicity: don't introduce additional complications unless there is a demonstrable need. Always follow the KISS principle (Keep It Simple Stupid). Don't start playing around with advanced features of Java (e.g. final variables and inner classes) just because you've been told this is what object-oriented programming is all about. If you find that you are writing the same (or almost the same) code more than once, look for a way to eliminate the redundancy. You'll probably need to create a new method or class which can be used in a number of different situations. The goals of simplicity and modularity overlap considerably.
  3. transparency: choose your variable and method names so as to make the code self-explanatory whereever possible. (Of course this will only be possible if your code is modular.) The name of a variable (or method) needs to show what role is being played. Use inline comments when you are unable to find a way of making the code tell `its own story'. If you do use inline comments, keep them as short as possible and format them so as to minimise disruption to the indentation structure of the code. Don't let line-wrap problems obscure the indentation pattern of your code. (Printing in `portrait' mode is a way of getting around this problem.)

Misc resources

`A Computer in the Art Room: the origins of British computer arts 1950-80' by Catherine Mason.

Page created on: Tue Mar 9 11:50:58 GMT 2010
Feedback to Chris Thornton