Using the sketchbook-style coding environment Processing, we cover programming fundamentals from the artist's perspective, assuming no prior experience with programming. The art of coding will be approached from three points of view:
Code as Craft The concepts, terminology, syntax, and logic fundamentals of programming, which are applicable to interactive design, web applications, game coding, serial and networked communication.
Code as Art The use of math and data, combined with techniques such as iteration and recursion, to produce static and animating works of art.
Code as Tool The ability to create freestanding art-making tools, which artists may use themselves to facilitate their processes, and which other users might employ to generate art.
Having explored and experimented in the course , the student should be able to move on comfortably to using other programming environments — such as Actionscript, MaxMSP, Lingo, JavaScript, MEL for Maya, PHP, and similar languages — in pursuit of their artistic goals.
1.Create programs that:
•Draw, via...
Hard-coded procedures
Algorithms
Live data (as read from an array or network, or received via sensors)
Human input, eg. mouse/leyboard
•"Record, "Store, and "Play back" human input sequences
•"Detect collisions" of visual objects on screen
•Generate meaningful feedback to users
•Actuate physical objects
•Retreive data from the internet
2.Use Code to create their own tools.
3.Apply what they have learned to create new programs and debug existing ones.
Thinking with symbols.
Drawing with code
Examples. Goals for the course.
Origins of “computational art”.
Exercises in basic communication.
Introduction to Processing environment and web site
Statements & comments, Executing commands
Coordinates, basic drawing functions & attributes
(using Processing's “basic mode”)
Iteration and Repetition.
Making decisions.
Fundamental drawing functions.
The logical operators.
Variables, data types, math operators.
while(), for(), nesting.
FLOW CHARTING, introduction.
Working with pixels and color.
Processing’s draw() cycle.
Using loops..
Expressing color & transparency.
Limit testing.
Working with pixels.
Using True & False.
Using functions with parameters.
Using arrays to generate text.
Reading and manipulating characters and strings.
Arrays.
Beginning to use random().
Creating generalized, custom commands.
Linear and geometric motion.
Simple collision detection.
Using functions with parameters, more.
Trying diffrent motion recipes.
Using distance-to.
States: Keeping track of conditions.
Using data (in this case, time points) to control events and...
How images are represented in the computer.
Intervals, rhythm. Using the time functions.
An image as an array of pixels.
Setting and getting pixel properties.
Picking colors, generating palettes.
Object-oriented code design.
Designing independent actors.
Classes & Instances.
Public & private methods and variables.
Useful code structures for managing a bevy of objects.
(This topic will carry on in following weeks.)
Midterm Quiz.
Also, a survey of other languages and development environments.
More object work in class.
Object-oriented code design, continued.
Inter-object communication.
Inheritance.
Events: Responding to the mouse and keyboard.
Using mouse tracking and key input to influence the program.
Creating interface feedback.
Storing and recalling what happened between sessions.
Saving the image with saveFrame().
Further use of arrays.
Writing text files to the local machine.
Reading data from external sources, such as sensors or a network.
Using serial data.
Using the Net functions with URLs.
Work in class.
Debugging and critiques. Special topics by request.
Work in class
Debugging and critiques. Special topics by request.
Demo and critique of finished projects.
Pixels, Patterns, and Processing Daniel Shiffman [prepublication] Morgan-Kauffman
Additional references:
Art of the Digital Age Bruce Wands (Editor)
Creative Code John Maeda
Pattern in the Stone Danny Hillis
Exploring the Invisible: Art, Science, and the Spiritual Lynn Gamwell
Flash Math Creativity Manny Tan, et al. (Friends of Ed)
Generative Design: Beyond Photoshop Golan Levin, Lia, Meta, Adrian Ward (Friends of Ed)
The Computational Beauty of Nature Gary William Flake
Mathematics and Physics for Programmers Danny Kodicek
Algorithmic Beauty of Plants Przemyslaw Prusinkiewicz
Vehicles Valentino Braitenberg (MIT)
Turtles, Termites, and Traffic Jams: Explorations in Massively Parallel Microworlds Mitchel Resnick (MIT)
Being Digital Nicholas Negroponte (Vintage)
Primer of Visual Literacy Donis A. Dondis
Students are expected to demonstrate their weekly assignments in class and discuss, debug, and critique their own work and the work of others in the class.
Students are also expected to post their work-in-progress weekly on-line, including a narrative of their goals and problem-solving adventures.
· Participation and Attendance* 15%
· Weekly Assignment and Quizzes 25%
· Midterm Exam 10%
· Midterm Project 15%
· Final Exam 15%
· Final Project 20%
Grading criteria for each project = Aesthetics and Originality: 30%; Planning, Documentation, and Code Design: 30%; Appropriate functionality: 40%. Project grades include work-in-progress reviews and related presentations.
* Participation and Attendance. This portion of the student's grade rates how actively she/he asks questions, contributes to discussions, volunteers ideas, and engages in critiques without prompting. Obviously, if the student is frequently late and/or has many unexcused absences, his/her value in class will be impaired. (See also Attendance policy below.) Also, simply showing up every week but remaining silent is not participation.
Work-in-progress. If a student fails to demonstrate work-in-progress in any studio session where projects are being reviewed, one letter grade will be deducted from the final grade for each such occurrence. Finished projects turned in with no demonstration of work-in-progress will not be accepted.
Late work. There is a one-letter-grade per week deduction for work turned in late, for any reason. Work is late if turned in after the close of class. Major project work on formal presentation days is late if the student is late.
Incompletes. No incompletes will be given, except for documented medical or family emergencies. Refer to the official department policies for additional information.
Attendance
Students are expected to attend all classes. Only fully documented absences due to illness or significant hardship may be excused, solely at the instructor's discretion. However, even excused absences do not fulfill class participation requirements, and grades may therefore reflect this. Three unexcused absences constitute failure.
A student is counted as Late for arrival beyond 15 minutes from the published start time of class. Departure before the end of class is also counted as one Late. Two instances of lateness are considered equal to one absence.
DURING STUDIO SESSIONS
All students must attend studio sessions from the start of class.
Bring project elements to work on in class, and for work-in-progress review.
Unscheduled lecture/demos will be given on relevant topics.
DURING FINISHED PROJECT PRESENTATIONS
All students must be present from the start of class, since evaluation will be part of the review process. Lateness to or absence from these classes constitutes complete failure of the given project.
Technical failures are not accepted as an excuse for late work. Do not mis-read sympathy from the instructor as forgiveness. Expect the unexpected. Be paranoid and be prepared. Don't wait to do work until the last minute, and always save sequential work-in-process. Back up work frequently on CD-RW or other media. Make 2 copies, and keep them in different places. (Students can also use their personal storage space on the DDA server, but only consider this as temporary storage.)
Remember: It is always better to show what you are working on than to show nothing at all. Please do not "suffer in silence". A programming project is rarely perfect until the very last version. Learn to love your error messages! We can try to solve problems in class if necessary. Except during your presentation of the final versions of your exercises and final project, you must demonstrate "work in progress" (which includes unfinished visuals and bugs).
Course Plagiarism Policy
When you copy work that was actually created by another person -- from any book, web site, computer file, anywhere -- without giving credit to the original author, you are implying that you yourself did the work. This is called plagiarism. It is dishonest and is not acceptable in this Department or the Institute.
Getting help and collaborating with friends is acceptable, as long as the work a student submits in class is her/his own. Copying samples of code, or using images or text from another work, is OK but ONLY IF credit is given to the source of the original work. When no credit is given, that is plagiarism.
Beyond this, note that festivals, galleries, and competitions will expect that a student's work is completely original, or that -- for the portions which are not -- he/she has secured legal permission to use the works of others. It is also unwise to include work in a portfolio which is not entirely original.
It is the policy of DDA and Pratt to emphasize respect for the creative works of others. Infringement takes place when -- without permission -- a substantial part of a work is copied, made available to others, or adapted into a new form. Images, text, logos, software, sounds, film/video clips, email, postings to newsgroups, and other works distributed electronically are protected by copyright, just as they are in traditional media. Appropriate use of the internet and digital storage media implies responsibilities and is encouraged. Protection technologies such as watermarking and encryption are supported and must be respected. DDA does not condone copyright infringement and disciplinary action will be taken if this policy is violated.