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, also reviewing the theoretical issues which apply. 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 (via the `pr' links below) cover about 90% of the material and 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 don't have them out in lectures. I will be doing fairly regular attendance sign-ups for lectures and labs so please attend all the sessions. Use these 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, with a sign-up sheet somewhere at the entrance to the lab. When you sign your name, please add the (week) number of the exercise you have completed. Assessment and feedback for lab work will be through spot-checks; 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 demos, rehearsals and presentations.

Assessment

Assessment for this course is 100% coursework divided between a programming assignment and an essay. (There is no exam.) The assignments are worth 50% each. Assessments and presentations will be marked by myself and one peer marker. Every student should peer-mark the work of one other. 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.

By the submission deadline, you should submit the assignment to the dept. office in hard copy and either give it in hard copy to your peer marker or email it electronically to them as a single PDF, HTML or TXT document. (The electronic document should be an exact replica of your hard-copy submission.) This means that on the day of the deadline you'll be (a) handing in your submission in hard copy to the deptartment office, (b) giving it or mailing it to your peer marker and (c) getting a submission from the student whose work you are peer marking.

Having received the submission you should then evaluate it on the given marking criteria (see below), evaluating your own work in the same way at the same time. Then use the submission forms below to submit your marks and comments.

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.

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 in which 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.

Peer/self marks for the first four criteria are required. Submit them here.

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, poetry or whatever you like. A report is also required following the guidelines below. The assignment is due in on Thursday of week 10 and you'll be scheduled to demo and present your system at one of the sessions in week 10 (lab and lectures will all be treated as labs).

The arrangements for self- and peer- marking are much the same for this exercise as for the essay. The credit factors are different though. Credit for the assignment will be allocated using the following scheme.

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)

20% for quality of output (aesthetic, emotional, intellectual value?)

20% for quality of marking (fair marks, detailed criticism?)
Self and peer-marks are required for all criteria except `quality of marking'. As well as taking into account your own views, the mark you give for `quality of output' should, as far as possible, reflect audience response to the demo. Submit your marks here.

Feedback

When you get your assignment back there will be a mark sheet which shows the marks you got for the eight criteria. There may also be a moderated summary of peer comments. If you would like a `verbal consult' on the marks you received, you can come to the additional session which normally takes place at 11 in my office on the first monday of the Summer term. If you come to this session, be sure to bring your marked assignment with you and be ready to tell me which of your marks you would like to discuss.

Peer-marking pairings

Peer-marking allocations are as follows. Note that usenames are appended to full names, so to email your peer marker just add @sussex.ac.uk to the username part. Please try to submit peer marks by 5pm on the monday following the submission deadline. Remember that the submission to me must be in hard copy and submitted via the department office.

Peer allocations for GC essay 2009

  Submitter                           Peer marker

  Kevin-Adsett-ka72                   Scott-Hughes-smh38
  James-Campbell-jc208                Kevin-Adsett-ka72
  Arthur-Carabott-ajrc21              James-Campbell-jc208
  Jonathan-Davies-jd96                Fatima-Morales-fm93
  Charles-Edwards-cae22               Adam-Bales-atjb20
  Charlie-Fyvie-Gauld-cf42            James-Hannett-jah38
  Daniel-Gauden-djg27                 David-Tait-D.A.Tait
  James-Hannett-jah38                 Paul-McConnell-P.Mcconnell
  Scott-Hughes-smh38                  Charlie-Fyvie-Gauld-cf42
  Gregory-Lloyd-gpl21                 Scott-Friedag-Seaward-S.Seaward;
  Stephen-Martin-sm302                Robin-Watson-rfw21
  Fatima-Morales-fm93                 Paul-Asjes-P.Asjes
  Scott-Sheridan-ss323                Charles-Edwards-cae22
  David-Tait-D.A.Tait                 Gregory-Lloyd-gpl21
  Nicholas-Turnbull-nt57              Daniel-Gauden-djg27
  Robin-Watson-rfw21                  Stephen-Martin-sm302
  Paul-Asjes-P.Asjes                  Nicholas-Turnbull-nt57
  Adam-Bales-atjb20                   Scott-Sheridan-ss323
  Paul-McConnell-P.Mcconnell          Andrew-James-Noon-A.Noon
  Andrew-James-Noon-A.Noon            Arthur-Carabott-ajrc21
  Scott-Friedag-Seaward-S.Seaward;    Jonathan-Davies-jd96
Peer allocations for GC report 2009

  Submitter                         Peer marker

  Kevin-Adsett-ka72                 James-Campbell-jc208
  James-Campbell-jc208              Fatima-Morales-fm93
  Arthur-Carabott-ajrc21            Andrew-James-Noon-A.Noon
  Jonathan-Davies-jd96              Robin-Watson-rfw21
  Charles-Edwards-cae22             Paul-McConnell-P.Mcconnell
  Charlie-Fyvie-Gauld-cf42          Kevin-Adsett-ka72
  Daniel-Gauden-djg27               Stephen-Martin-sm302
  James-Hannett-jah38               Paul-Asjes-P.Asjes
  Scott-Hughes-smh38                Adam-Bales-atjb20
  Gregory-Lloyd-gpl21               Nicholas-Turnbull-nt57
  Stephen-Martin-sm302              David-Tait-D.A.Tait
  Fatima-Morales-fm93               Gregory-Lloyd-gpl21
  Scott-Sheridan-ss323              Scott-Hughes-smh38
  David-Tait-D.A.Tait               Scott-Sheridan-ss323
  Nicholas-Turnbull-nt57            Scott-Friedag-Seaward-S.Seaward;
  Robin-Watson-rfw21                Charles-Edwards-cae22
  Paul-Asjes-P.Asjes                Jonathan-Davies-jd96
  Adam-Bales-atjb20                 Daniel-Gauden-djg27
  Paul-McConnell-P.Mcconnell        Charlie-Fyvie-Gauld-cf42
  Andrew-James-Noon-A.Noon          James-Hannett-jah38
  Scott-Friedag-Seaward-S.Seaward;  Arthur-Carabott-ajrc21

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 relevant 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 what part of the program to another. Writing your program in a modular way exploits the 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 someone has told you that this is what object-oriented programming is all about. If you ever 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. (Of course this will only be possible if your code is modular.) The name of a variable (or method) needs to show exactly what role is being played. Only resort to 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.
Page created on: Mon Mar 16 14:22:29 GMT 2009
Feedback to Chris Thornton