PDF Processing For Visual Artists How To Create Expressive Images and Interactive Art 1St Edition Andrew Glassner Ebook Full Chapter

Processing for Visual Artists: How to
Create Expressive Images and

Interactive Art 1st Edition Andrew
Glassner
Visit to download the full and correct content document:
https://textbookfull.com/product/processing-for-visual-artists-how-to-create-expressive
-images-and-interactive-art-1st-edition-andrew-glassner/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Light for Visual Artists Second Edition Understanding

and Using Light in Art Design Yot
https://textbookfull.com/product/light-for-visual-artists-second-
edition-understanding-and-using-light-in-art-design-yot/
How to Create Manga Drawing the Human Body The Ultimate

Bible for Beginning Artists 12th Edition Matsu
https://textbookfull.com/product/how-to-create-manga-drawing-the-
human-body-the-ultimate-bible-for-beginning-artists-12th-edition-
matsu/
Understanding Kids, Play, and Interactive Design :How

to Create Games Children Love 1st Edition Mark
Schlichting
https://textbookfull.com/product/understanding-kids-play-and-
interactive-design-how-to-create-games-children-love-1st-edition-
mark-schlichting/
Deep Learning Vol 2 From Basics to Practice Andrew

Glassner
https://textbookfull.com/product/deep-learning-vol-2-from-basics-
to-practice-andrew-glassner/
Glassner
to-practice-andrew-glassner/

Glassner
to-practice-andrew-glassner-2/
Programming Kotlin Create Elegant Expressive and

Performant JVM and Android Applications 1st Edition
Venkat Subramaniam
https://textbookfull.com/product/programming-kotlin-create-
elegant-expressive-and-performant-jvm-and-android-
applications-1st-edition-venkat-subramaniam/
The Art of Communication How to Be Authentic Lead

Others and Create Strong Connections Judy Apps
https://textbookfull.com/product/the-art-of-communication-how-to-
be-authentic-lead-others-and-create-strong-connections-judy-apps/
3D Game Programming for Kids Create Interactive Worlds

with JavaScript 1st Edition Chris Strom
https://textbookfull.com/product/3d-game-programming-for-kids-
create-interactive-worlds-with-javascript-1st-edition-chris-
strom/
Glassner, Andrew. Processing for Visual Artists : How to Create Expressive Images and Interactive Art, CRC Press LLC, 2010.
16:03:24.
i i
i i
Processing
for Visual Artists
How to Create Expressive Images
and Interactive Art
Andrew Glassner
Boca Raton London New York
CRC Press is an imprint of the

Taylor & Francis Group, an informa business
AN A K PETERS BOOK
i 16:07:44. i
i i
i i
i i
Editorial, Sales, and Customer Service Office
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
First issued in hardback 2018
© 2010 by Coyote Wind, LLC

CRC Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works
ISBN 13: 978-1-138-46085-0 (hbk)

ISBN 13: 978-1-56881-716-3 (pbk)
This book contains information obtained from authentic and highly regarded sources. Reason-
able efforts have been made to publish reliable data and information, but the author and publisher
cannot assume responsibility for the validity of all materials or the consequences of their use. The
authors and publishers have attempted to trace the copyright holders of all material reproduced in
this publication and apologize to copyright holders if permission to publish in this form has not been
obtained. If any copyright material has not been acknowledged please write and let us know so we
may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced,
transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or
hereafter invented, including photocopying, microfilming, and recording, or in any information
storage or retrieval system, without written permission from the publishers.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and
are used only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
Library of Congress Cataloging-in-Publication Data
Glassner, Andrew S.
Processing for visual artists : how to create expressive images and interactive art / Andrew
Glassner.
p. cm.
Includes index.
ISBN 978-1-56881-716-3 (alk. paper)
1. Digital video. 2. Digital graphics. 3. Computer animation. 4. Image processing–Digital
techniques. 5. Computer art. I. Title.
T385.G5853 2010 006.6’96--dc22

2010014927
Set in Times, Officina Sans, and Courier using TeX
Cover design: Darren Wotherspoon
i 16:07:54. i
i i
i i
i i
In general, textbooks seem to confine the material solely to problem and solution,
or to technical analysis. . . . Since [in this book] we are dealing not with organic
material like nuts and bolts, but with human qualities like hope and ambition, faith
or discouragement, we must throw out the textbook formulas. . . . I cannot par-
ticipate in all your personal problems, but I can certainly remember my own, and
assume that yours will not be greatly different. Therefore this book anticipates the
solution of these problems even before you meet them. . . . It is my job here to give
you the working materials with which to make your own effort successful.
–Andrew Loomis, Drawing the Head and Hands, Viking Press, 1956
If the student is tenacious enough, barriers and problems will dissolve; forms
hitherto not seen or conceived will move freely and easily within the infinite spatial
realm of the picture plane.
–Burne Hogarth, Dynamic Figure Drawing, Watson-Guptill, 1970
i 16:07:54. i
i i
i i
i i
Web Materials
Complete programs for every project and every Processing-generated image in this book
may be downloaded, for free, from http://www.akpeters.com/processing.
One of the wonderful things about Processing is that people are constantly coming
up with new ideas and applications. The starting point for information on Processing is
the official website at http://processing.org.
You can also find updates to this book, locate more Processing resources, and con-
nect with other creative people by visiting http://coyote-wind.com/Processing.htm.
Legal Disclaimer
THERE IS NO WARRANTY FOR THE SOFTWARE CODE TO THE EXTENT PERMITTED BY AP-
PLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE SOFTWARE CODE IS
PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFOR-
MANCE OF SOFTWARE CODE IS WITH YOU.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
ANY COPYRIGHT HOLDER BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABIL-
ITY TO USE SOFTWARE CODE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE SOFTWARE CODE TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
i 16:07:54. i
i i
i i
i i
Processing for Visual Artists
i 16:07:32. i
i i
i i
i i
Contents
Preface xiii
1 Overview 1
1.1 What Is Processing? . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Experiment Freely! . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Commenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Entering Programs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Programming as Expression . . . . . . . . . . . . . . . . . . . . . 10
2 Setting Up and Getting Started 13

2.1 Hello, World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Working With Processing . . . . . . . . . . . . . . . . . . . . . . . 20
3 Basic Ideas: Variables 23

3.1 Naming Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Using = for Assignment . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Semicolons and Errors . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Comments and Printing . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Functions and Tests 43

4.1 Writing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 setup() and draw() . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Curly Braces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Integer Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Combined Operators . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Starting a Program . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.7 Animation and Global Variables . . . . . . . . . . . . . . . . . . . 61
4.8 If Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.9 Conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
vii
i 16:08:05. i
i i
i i
i i
viii Contents
4.10 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.11 Speed and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5 Color 83
5.1 Function Overloading . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Defining Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 HSB Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 Graphics Primitives 101

6.1 Naming Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2 Basic Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3 Graphics State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.4 Irregular Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.5 Graphics Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7 Human Input 131

7.1 Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.2 Mouse Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.3 The Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.4 A Simple Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8 Loops and Transparency 159

8.1 Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
8.2 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9 Transformations 179
9.1 Understanding Transformations . . . . . . . . . . . . . . . . . . . . 183
9.2 Accumulating Transformations . . . . . . . . . . . . . . . . . . . . 186
9.3 Order Matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.4 Nested Transformations . . . . . . . . . . . . . . . . . . . . . . . . 192
10 Recursion 201
10.1 Recursive Teacups . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
10.2 Extending the Teacups . . . . . . . . . . . . . . . . . . . . . . . . 215
10.3 Drawing Boxes within Boxes . . . . . . . . . . . . . . . . . . . . . 216
11 Randomness and Arrays 223

11.1 Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
11.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
11.3 Manipulating Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 242
11.4 Deleting an Array Entry . . . . . . . . . . . . . . . . . . . . . . . . 248
11.5 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
i 16:08:05. i
i i
i i
i i
Contents ix
12 Catmull-Rom Curves 269

12.1 Knots and Control Points . . . . . . . . . . . . . . . . . . . . . . . 270
12.2 Catmull-Rom Curves . . . . . . . . . . . . . . . . . . . . . . . . . 274
12.3 Assembling Curves . . . . . . . . . . . . . . . . . . . . . . . . . . 281
12.4 Curves from Vertices . . . . . . . . . . . . . . . . . . . . . . . . . 288
12.5 Tightening Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
12.6 Working with Curves . . . . . . . . . . . . . . . . . . . . . . . . . 295
12.7 Tangents and Normals . . . . . . . . . . . . . . . . . . . . . . . . . 297
12.8 Finding a Point on a Curve . . . . . . . . . . . . . . . . . . . . . . 302
13 Bézier Curves 313

13.1 Bézier Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
13.2 Reading Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
13.3 Offset Bézier Curves . . . . . . . . . . . . . . . . . . . . . . . . . 337
13.4 Finding a Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
13.5 Moving Curves Around . . . . . . . . . . . . . . . . . . . . . . . . 340
14 Objects 341
14.1 Objects and Methods . . . . . . . . . . . . . . . . . . . . . . . . . 342
14.2 Multiple Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
14.3 Object Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
14.4 Moving Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
14.5 Using this . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
14.6 Controlling Access . . . . . . . . . . . . . . . . . . . . . . . . . . 373
14.7 Some Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
14.8 Managing Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 377
14.9 Objects and Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 392
15 Fall Leaves 395

15.1 Basic Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
15.2 PVector Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
15.3 Drawing a Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
15.4 More Fun with Leaves . . . . . . . . . . . . . . . . . . . . . . . . 444
15.5 Pointillism Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
16 Images 457
16.1 2D Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
16.2 Displaying Images . . . . . . . . . . . . . . . . . . . . . . . . . . 462
16.3 The Pixel Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
16.4 Image Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . 483
16.5 Applying Texture . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
16.6 SVG Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
i 16:08:05. i
i i
i i
i i
x Contents
17 Working with Files 503

17.1 Digitizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
17.2 Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
17.3 Final Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
17.4 More File Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
17.5 Extending the Project . . . . . . . . . . . . . . . . . . . . . . . . . 535
18 Creating Patterns 537

18.1 Plotting a Function . . . . . . . . . . . . . . . . . . . . . . . . . . 541
18.2 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
18.3 About Pattern-Making Functions . . . . . . . . . . . . . . . . . . . 555
18.4 Finding Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
18.5 Blending with Cosine . . . . . . . . . . . . . . . . . . . . . . . . . 559
18.6 Building Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
18.7 Pattern Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
18.8 Circle Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
19 An Action Lamp 605

19.1 Bell Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
19.2 A Blobbier Lamp . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
19.3 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
19.4 Building the Lamp . . . . . . . . . . . . . . . . . . . . . . . . . . 640
19.5 Subclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
19.6 Ascending Blobs . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
19.7 Personalizing Your Lamp . . . . . . . . . . . . . . . . . . . . . . . 677
20 Typography 679
20.1 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
20.2 Showing Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
21 3D 709
21.1 3D Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
21.2 Making Shapes in 3D . . . . . . . . . . . . . . . . . . . . . . . . . 734
21.3 Controlling 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
21.4 3D Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
21.5 3D Lights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
21.6 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
21.7 Other 3D Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
21.8 Greebles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
i 16:08:05. i
i i
i i
i i
Contents xi
22 Useful Odds and Ends 771

22.1 Push and Pop Styles . . . . . . . . . . . . . . . . . . . . . . . . . . 771
22.2 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
22.3 Time and Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
22.4 Saving Your Images . . . . . . . . . . . . . . . . . . . . . . . . . . 778
22.5 Window Wraparound . . . . . . . . . . . . . . . . . . . . . . . . . 778
22.6 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
22.7 Types and Type Conversion . . . . . . . . . . . . . . . . . . . . . . 789
22.8 Offscreen Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . 792
22.9 Reading and Writing Modes . . . . . . . . . . . . . . . . . . . . . 812
22.10 Blurring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
22.11 Web Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
22.12 User Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
22.13 Gotchas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
22.14 Going Beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
23 Projects 827
23.1 Stacked Contours . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
23.2 Crystal Towers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
23.3 Skyline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
23.4 Neon Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
23.5 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
23.6 Puppet Show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
23.7 Spooky Plants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
24 Big Projects 871

24.1 Tackling a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
24.2 Organizing a Project . . . . . . . . . . . . . . . . . . . . . . . . . 872
24.3 Project 1: Sandstorm . . . . . . . . . . . . . . . . . . . . . . . . . 874
24.4 Project 2: Postcards from Another Planet . . . . . . . . . . . . . . . 886
A Keywords 911
A.1 Alphabetical Listing . . . . . . . . . . . . . . . . . . . . . . . . . . 912
A.2 Listing by Function . . . . . . . . . . . . . . . . . . . . . . . . . . 921
A.3 Object Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Index 933
i 16:08:05. i
i i
16:08:05.
i i
i i
Preface
Hi!
I know we haven’t met, but we already know a few things about each other. I know
that you’re a creative, intelligent person. I bet that you’re visually inventive and you like
to make pictures. You may have even created some animations or interactive programs,
or you’d like to try your hand at making some.
And you know a few things about me: I like making pictures and animations with
Processing, I like to write, and I like to teach.
That’s a great start for both of us. This may be the beginning of a beautiful friend-
ship.
Using a computer to create visuals can be a lot of fun. Of course, the process and
results are nothing like what we get from painting, sculpting, playing the piano, or going
for a hike, and it doesn’t replace any of those activities. It’s a whole new thing. You can
create pictures with so much rich detail, they would have taken you days to create by
hand. You can create the simplest kinds of images, but give them mesmerizing, subtle
motion that you can’t stop watching. Your animations can run all by themselves, or they
can respond to your viewer’s mouse movement, keyboard taps, or other gestures through
custom input devices. You can create games, and you can create art. Your works can
be still or moving, simple or complex. Your color palette can be warm or cool, or it
can even change over time. You’re basically creating your own little interactive world
where the only rules are the ones that you invent.
Computer graphics really is a new creative medium. And computer hardware and
software has now reached the point where you can create your own computer graphics,
on your own system, using software you download for free. How great is that?
If any of that sounds interesting to you, then you’re the person I wrote this book for.
I’ve assumed in this book that you don’t have any programming background. And
although a big part of this book involves helping you learn to program, this really isn’t
a programming book. I’m not teaching programming here in the abstract. Instead, it’s
just a means to an end: making gorgeous, expressive visual imagery.
A great analogy to programming is riding a ten-speed bicycle. There’s so much
to think about just to get going: which hand brake controls which wheel, which lever
controls which set of gears, which gear you’re in right now and which one you want to be
in, and that doesn’t even include whether your helmet’s strapped on right or whether you
xiii
i 16:08:15. i
i i
i i
i i
xiv Preface
remembered to roll up your pants legs. Then there are the rules of the road, navigating
around cars, making sure you don’t hit a pedestrian or get blindsided by a car coming
out of a driveway or someone opening their car door without warning. There are bike
lanes to navigate, signs to read, traffic lights to obey, potholes to avoid, and so on.
When you first started riding a bike in city traffic, you might have been overwhelmed
by all the things you had to think about. From just working the bike to riding in a
safe and legal way, managing this encyclopedia of information probably required your
sustained, concentrated effort. Over time, I’m sure some of the little things (like which
brake lever is which) became second nature, and you were able to direct your attention
to larger issues, like safely making left-hand turns in traffic.
Then, even that became natural, and as time went on, things just got more and more
fluid. Before long, you probably became comfortable riding your bike, and it’s turned
into a perfectly natural thing to do. Whether you’re on a bike trail or in traffic, you feel
comfortable and at home on your bike. You can even look around and talk to friends
while you’re riding, since your body “knows” how to keep you balanced and pedaling.
So it is in programming a project in Processing. It might seem like an overwhelm-
ing flood of detail at first. You might feel like it’s all too much and that managing all
these logical details isn’t the way your brain works anyway. Don’t fall for it. If you can
ride a bike on city streets, you can write a terrific program. It can be weird and strange
and unusual and overwhelming at first, no question. But stick with it for a while and
you’ll find that what originally seemed hard and mysterious is really pretty straightfor-
ward. There’s no special “programmer’s mind,” any more than there’s a special “dinner-
cooking mind” or “bike-riding mind.” It’s all stuff you can do pretty naturally once you
get it under your belt.
Two wonderful things about Processing are that it’s free and is available for both
Macs and PCs. Did I mention that it’s free? If I haven’t, I probably should. Processing
is free. Perfectly legally. Just download and enjoy!
And frankly, working with Processing is a lot of fun. The whole thing has been
designed so that you can create interesting results very quickly. The streamlined nature
of the language just scoops you up and delivers you, like an express train, to the land of
image making.
So why this book? There are already a few excellent books on Processing, and tons
of books that cover programming in general. My experience is that the best learning
happens when both teacher and student are on the same wavelength. There’s no one
“right” or “best” way to learn Processing or read a book or write a book. The core
information on Processing that I present in this book is the same as what you’ll find
in other books—after all, the language is what it is. But this book is for people who
like an informal, project-oriented style. If you just want a reference manual, that’s also
available (in fact, it’s online at the Processing website, and it too is free).
When you first get started with Processing, you may find that programming requires
you to focus nearly exclusively on the logical, analytical part of your brain. That’s nat-
ural, and that’s part of getting up to speed. There’s no debating the point that computer
programs have to be nearly perfect in order for them to do what you want them to, and
i 16:08:15. i
i i
i i
i i
Preface xv
that requires a Mr. Spock kind of approach: logical, reasoned, and focused on working
step by step. That’s the most unusual aspect of programming compared to other arts,
but it’s not the most important thing.
Every art form has its idiosyncrasies. If you’re a photographer, odds are that you
work with math every day to figure out which lenses to use and how long to expose
each shot. If you’re creating makeup prosthetics for a movie, you know a lot about the
chemistry of molding compounds and the practical techniques for making molds. These
are the logical, rational sides of those fields. Almost every field has at least a few of
these kinds of elements. Computer graphics happens to have lots of them.
And like these other fields, once you’re comfortable with the mechanical technique
you can start to work intuitively. It may sound crazy if you’re not yet a programmer,
but once you have the tools under your belt, you really can work by the seat of your
pants when building up images and animations. Maybe something in an animation just
doesn’t feel right; a picture of a helium balloon isn’t floating the way you’d like, for
example. In the back of your head, you try out some possible recipes for how to get it
to move the right way. Maybe the balloon should move more slowly? Maybe it should
bob up and down a little, as though there was a breeze? If so, how would you create that
bobbing motion? Should it be rhythmic or random? You ask the questions that interest
you, and you answer them in a way that pleases you.
At this point, you’re able to express yourself using images and motion. You can say
to yourself, in effect, “Here is the way that I think this balloon should be moving,” and
then you can write the steps in Processing that bring that about. And almost always,
you’ll then tune it up by adjusting some of the numbers, making the balloon bob up and
down more quickly, for example, or maybe rise higher and drop lower. There are no
rules; the balloon will do anything you want it to. The hard part isn’t the programming
because you’ll get good at that more quickly than you might expect. The hard part is
figuring out how the balloon should move. That’s art. That’s self-expression. And that’s
what this book is all about: getting you to where you can be thinking about the art.
My favorite times with Processing are when I’m balancing analytic and creative
skills. My intuitive brain is thinking, “I don’t know, maybe a smidgen more of . . .
whatever, I don’t know what to call it, but something sort of like this,” and my analyti-
cal brain is simultaneously figuring out how to write code to capture that vague, fleeting
feeling and turn it into pictures and motion. When those two engines are purring to-
gether at the same time, it’s a great feeling. My goal in this book is to help you find that
feeling for yourself.
To that end, I have written this book in a style that’s informal and conversational.
The technical material isn’t presented as it often is in technical books, in a tightly struc-
tured sequence where each topic is explored in depth before moving on to the next.
Instead, I’ll mostly move through a series of projects, from little things to bigger ones,
and I’ll introduce the technical material that we need as we go. When we do hit a new
topic, I only go into it to the depth we need. Later on, we might need to delve deeper
and get into more detail, so we’ll do that. By the time we’re done, we’ll have explored
every nook and cranny offered by Processing.
i 16:08:15. i
i i
i i
i i
xvi Preface
The approach is one of shared discovery. As I work on projects, you’ll see each step
along the way: where I make both simple and big mistakes and fix them, where I change
my mind about things, and how the programs evolve. These aren’t contrived examples;
these are exactly the programs that I wrote, as I wrote them. I saved each version of
each program along the way, even if it had bugs and errors, so you can see not just the
final results (which we do reach!) but all the steps that got us there.
I did this that way because I think attitude and approach are absolutely key to suc-
cessful programming. I’ve written many thousands of programs in my life, and I’ve
worked with hundreds of other programmers, some of whom are enormously produc-
tive and skilled. And every great programmer I know, when exploring a new project for
the first time, expects to make lots of errors. From simple typos to major conceptual
stumbles, everyone does it. We often only come to understand a program as we work
on it. So I want you to feel as comfortable with your errors as I feel with mine: ho hum,
another error, I’ll just fix that and move on.
In this way, you’ll see how an experienced programmer works. I’m pretty productive
and good at what I do, so I’m willing to hold up my process as a good place for you to
start (and my process is a lot like that of many other programmers, so you’ll be in good
company). Of course, once you feel comfortable, I’m sure you’ll find your own style,
and that’s a wonderful thing. Until then, you can see how I do it, and I hope that will
give you a good start.
There are few things that are as rewarding as the chance to publicly thank my friends
and colleagues who helped me with this book. They read my drafts and offered many
comments that greatly improved the text, the figures, and the programs. For sharing
their significant time, expertise, and help, I thank Steven Drucker, Leanna Gingras, Eric
Haines, Evan Haines, and Jeff Hultquist. Thank you also to Richard Brauer, Ben Hem-
mendinger, Jack Kern, and Philippe Lhoste for reviewing the manuscript, catching bugs,
and suggesting many useful improvements. Thank you to Ben Fry, Adam Finkelstein,
and Julie Steele for encouragement during the early days. Big thanks go to everyone
at AK Peters, who have been (as always) a pleasure to work with: Camber Agrelius,
Sarah Cutler, Susannah Sieper, and of course Alice and Klaus Peters. And thank you to
Neale Simpkin and the staff at Tully’s Coffee in Seattle’s Wallingford neighborhood for
offering such a nice environment (and delicious coffee), where I wrote and edited much
of this book.
I hope you find that this book gives you the tools to create new visuals that float
your boat and make your friends smile. Have fun, and make great stuff!
i 16:08:15. i
i i
i i
i i
Chapter 1
Overview
Hi again!
You’re about to start an exciting journey. I’ve taken this ride before, so I’ll be your
guide, but what you respond to and get stimulated by is all up to you.
Our ride into making visuals with Processing will be more of a river kayak trip than
a theme-park ride. In other words, you’ll have to paddle. And I won’t kid you, paddling
is work. It can feel like hard work, particularly in the beginning when everything seems
new and unfamiliar. But you’ll be surprised how quickly the paddle comes to fit natu-
rally and comfortably in your hand. You’ll come to look forward to the fast sections of
water because they give you a chance to stretch out and use your skills, paddling around
the rocks and up and down the rapids. You might even show off a little to your friends.
It’s still work, but it’s work that feels great! So hang on past the initial unfamiliar stages
and you’ll get the swing of it.
In the next chapter, we’ll download Processing and enter our first program. But if
you haven’t done much programming before, jumping into the deep end can be a little
disorienting. Sure, you can click the right buttons and type in the right characters, but
what does it all mean? This chapter will give you a bird’s-eye view of the process. With
this overview in mind, the mechanics in the next chapter will make sense to you, and
you’ll already be on your way to creating your own original work.
In this book, I’ll focus on creating visuals using the Processing language. I talked
about this a little in the Preface, but basically, Processing is a modern system that has
been designed from the ground up specifically for making great visuals. It’s about as
straightforward as something like this can be. And it runs on both Macs and PCs. And
it’s free!
One of the great things about working with Processing is that once you’re com-
fortable with the language, it’s usually not hard to pick up any of the other popular
languages in common use. That’s because today’s popular languages, including Pro-
cessing, all pretty much share the same central concepts. The differences tend to be in
the nuts and bolts of how they do things. There are definitely meaningful, important dif-
ferences between computer languages, but relatively speaking, they’re more alike than
they are different.
i 16:08:24. i
i i
i i
i i
2 1. Overview
So if you join a group of people who are working in, say, Java, you’ll be able to get
up to speed and contribute far more quickly than if you were starting from scratch. Or if
you find some code posted to the web in a language like Ruby or C++ or Python, you’ll
usually be able to read it without too much trouble and understand what’s generally go-
ing on. Processing’s specialty is definitely graphics, but it’s a modern, general-purpose
language that you can use for just about anything, and it’s a great foundation for launch-
ing into other languages and systems that might appeal to you.
1.1 What Is Processing?

When I refer to Processing in this book, I’m actually referring to four different things,
all of which share that name.
First, there’s the Processing program itself. This is the thing you download from the
web and install on your computer (we’ll see how to do that in the next chapter). It’s just
a file that sits on your hard drive.
Second, there’s the Processing language. The language defines the rules for the
text that you type to create your program. Your program is like sheet music. Sheet
music doesn’t make any noise by itself (unless you crumple the page), but by following
the rules of music notation, you can create a specific sequence of musical notes to be
played on a musical instrument. When a performer interprets the marks on the page,
music results. Similarly, when the computer interprets your program’s text, a running
program results.
Third, there’s the Processing development
environment. That’s a multipart window that
pops up on your screen when you run the Pro-
cessing file you downloaded. A typical win-
dow is shown in Figure 1.1. You can see a
piece of a program in the text editor window
in the middle of the screen (I’ll go over this
window in detail in Chapter 2). This Process-
ing window is your home base for writing, fix-
ing, and running Processing programs. Every-
thing you need to develop your programs is
right there.
Finally, there’s the Processing run-time en-
vironment. That’s the whole complex collec-
tion of libraries and other software that have
Figure 1.1. The Processing environment. been written for you to call upon when you
write your own programs, and it provides all
the extra machinery that is necessary for your programs to run. This run-time environ-
ment is like the engine in your car; you rarely interact with it directly, but it’s always
there, providing the unseen power for everything you do.
i 16:08:24. i
i i
i i
i i
1.2. Experiment Freely! 3
In Processing, each program you write is called a sketch; this is just a friendlier
term for “program.” A sketch is saved on your hard drive as a file with the extension
.pde (an acronym for Processing development environment). Despite the odd exten-
sion, this is just a plain text file, so you can open it, read it, and even freely edit it
with any text editor (though Processing only pays attention to what appears in its own
windows).
When you save a sketch, Processing creates a folder for you with the name of the
sketch and then puts the sketch inside the folder. If your sketch gets large, you might
want to break it up into several smaller files for your own convenience. In that case,
they’re all saved in the same folder, and if you open any of the files, Processing opens
them all up, with one tab for each file. Figure 1.1 shows a sketch with four files, and
thus four tabs.
By long-standing convention, programs are also called code or source code by pro-
grammers, as in, “I finally got that code to run” or “Check out my awesomely fast source
code!” Sadly, the word code in this context has nothing to do with elegant spies seduc-
ing one another on warm balconies overlooking the Mediterranean. The terms program,
sketch, source, source code, and code all refer to the same thing: the text you type into
the text editor. I’ll use all of these terms interchangeably.
1.2 Experiment Freely!

Programs are imperfect beasts. There’s almost no program in the world that does any-
thing interesting that is flawless. The imperfection may only be that it’s slightly slower
or slightly bigger than it needs to be. Or there might be a very subtle error that only
shows up one time in a billion. Of course, programmers work hard to make their pro-
grams as correct as possible. But since every program is essentially a brand-new cre-
ation that nobody has ever seen before, it’s almost inevitable that something, somewhere
will be off a little bit. We call any imperfection in a program a bug, and it’s the rare
program that has no bugs. Every time your favorite software company releases an up-
date for your operating system or your programs, it’s either because they’re adding new
features or fixing old bugs (or both). The best programmers in the world write buggy
code, and more of the best programmers in the world find and fix those bugs. Nobody
wants bugs, but they’re a part of life.
Whether or not a given bug is a problem in your program is entirely dependent
on context. If you’ve written a program that is used by air-traffic controllers, and you
discover a bug that causes planes to unpredictably disappear from a controller’s screen,
I’d consider that a pretty serious bug, and one that I’d like fixed right now, this very
second, please. If you’ve written an art piece that displays text on the screen, but when
the text is longer than you expected, it shoots past the end of the screen and disappears,
you might consider that a serious bug that you need to fix. On the other hand, you might
view that behavior as a happy accident; maybe on viewing it, you decide that this quirk
actually adds to the meaning of your work. Or you might see it as a problem you want
i 16:08:24. i
i i
i i
i i
4 1. Overview
to fix, but since the doors of the gallery are going to open in two hours, you decide you
can live with it.
Bugs in programs used by surgeons, astronauts, and bank tellers had better be as free
of bugs as possible; programmers call this kind of code bulletproof, though in reality
no code is bulletproof. But they test it long and hard before they let it out the door. On
the other hand, programs that you write for yourself only have to work as quickly and
accurately as you want them to.
I’ve written plenty of programs that I know have bugs in them. But I also know that
nobody but me will use one of these little informal programs, and I know that I’ll never
use them in a way that will trigger the bug, so I don’t spend the time and energy to track
down and fix the problems (though I’ll usually write myself a comment in the program
so I don’t forget the problems are there). If I’m sharing the program, I might leave a bug
in but warn the people I’m sharing the program with, perhaps by including a statement
like “never set the volume to 11!” Lots of people share their mostly working code with
these kinds of warnings so that other people can build on their work without having to
start from zero. After all, if someone is just knocking around some ideas to see how
they look, they might not mind a problem here and there, as long as it doesn’t come as
a bad surprise. More commonly, people work hard to find and fix every bug before they
share their code with the world, even if it’s just an informal post on a public forum.
Of course, in this book I’ve tried to make my programs as free of bugs as possible.
You’ll see the programs as they grow, and you’ll see me squash as many bugs as I can
find. I hope I’ve caught them all.
There are a few different kinds of bugs. The first is the syntax error or compile-time
error. These bugs are easy to catch because Processing will explicitly tell you about
each one (in fact, they’re so common and easy to fix that some programmers don’t
even consider them “bugs,” saving that term for problems that are harder to diagnose
and repair). Usually syntax errors are nothing more than typos: you forgot a required
semicolon, for example. Computers are obsessive about this kind of precision. Spelling
matters: if you don’t spell your words perfectly, the computer won’t understand you.
Case matters: if you use a capital letter where a lower-case letter was expected, or vice
versa, the computer won’t understand you. You can’t have a single one of these syntax
errors in your program, or it won’t even get to the point where it can run.
This would make people crazy in the real world. Imagine that you wrote a 400-page
essay on some complicated subject that took you forever to write, say, the structure of
the eyes of some obscure species of shrimp found in tropical reefs. Suppose that when
you’re finally done and you submit it to your publishers, they send it back within two
seconds, telling you that on page 371 you spelled one instance of “the” as “teh,” and
therefore your entire book was rejected. That publisher wouldn’t last very long. But
that’s exactly how Processing (and all other programming languages) behave. Ninety-
nine percent right is not good enough. Not even 99.9 percent. But happily, the computer
will instantly spot every syntax error and it will usually even point you right to it along
with a helpful error message. Processing even highlights the problematic line in bright
yellow. By and large, syntax errors are quick and easy to fix.
i 16:08:24. i
i i
i i
i i
1.2. Experiment Freely! 5
When your program is actually running, it can have a different kind of problem.
Maybe your program tries to access more memory than you’ve installed in your com-
puter, or the program tries to talk to an external device that hasn’t been connected to that
computer. There are called run-time errors because they happen while your program is
running. Many of these will be handled for you by Processing. The others you’ll need
to catch for yourself. If you don’t, your program could behave in an unexpected way, or
it might even crash.
That’s a harsh word, but all it means is that your program stops running. It’s as
though you’d exited (or quit) the program in a normal way, except that a crash is usually
an unexpected (and undesired) surprise. Typically when a program crashes, you’ll get
an error message from Processing, or a dialog box will pop up on your screen alerting
you that your program has crashed.
This is a huge step forward. Not too many years ago, when a program crashed, it
took the whole computer down with it. Suddenly the thing wouldn’t respond; it was
just an inert box. You’d have to physically turn it off and turn it back on again. But
that wasn’t even the worst case. Sometimes, if the problem was particularly bad, the
computer wouldn’t just become unresponsive, but it would actually get its memory so
scrambled that the entire operating system and all the programs would’ve had to be
reloaded, just as if it was being turned on for the very first time at the factory before any
programs were put onto it at all.
When I was first learning to program on a Digital PDP-8/E computer, some of my
crashes resulted in exactly this kind of total meltdown. All the software was gone; the
hardware was intact but that was all.
I’d turn it off and then back on. The front of the computer had a long row of colored
plastic toggle switches. We kept a plastic laminated card near the machine that had
rows and rows of numbers on it. Reading from the card, I’d manually flip the switches
to form a particular pattern, then push another button to save those settings. Then I’d flip
the switches again, push the button, flip, push, flip, push, over and over. This process
was actually putting a tiny little program into the computer’s memory that enabled it to
communicate with the Teletype machine next to it, which we used as our terminal. The
program was very short, but entering it by hand still took five or ten minutes, and it had
to be done perfectly.
Once that little program was in place, it was time to put the operating system back
into the machine. Happily, I didn’t have to use the front-panel switches to enter the
many thousands of commands for that! The Teletype had a paper-tape reader on the
side. You’d feed it a long strip of yellow paper tape, about an inch wide. The tape
was punched with holes, and as the tape was automatically fed through the reader, the
Teletype sensed where the holes were and sent them to the computer. It was something
like a player-piano reader, only instead of making piano keys play, it put 1’s and 0’s into
the computer’s memory.
The operating system was kept in the supply cabinet (under lock and key). It was
a stack of fan-folded yellow paper tape about eight inches long by six inches tall. I’d
feed the first inch into the paper tape reader on the Teletype, make sure the little feed-
i 16:08:24. i
i i
i i
i i
6 1. Overview
ing mechanism was engaged, push a button, and go away for 45 minutes. If all went
perfectly, when I came back, there would be a huge mess of paper tape on the floor, but
the computer would be back up and ready for use. I would always try very hard to fix
the bug in my program before running it again, but there were days when I crashed the
computer over and over again. The computer was a shared resource, and though we all
crashed it, nobody was ever happy when their turn was delayed as the tape chug-chug-
chugged through the reader, agonizingly slowly.
Today, thanks to huge advances in operating-system software, a crash is a lot less
disastrous. Once in a great while a crash will take down the operating system, forcing
you to reboot, but with rare exceptions, the days of a buggy program destroying the
operating system are long gone. In fact, most of the time, a program crash won’t affect
the operating system at all. If your program crashes, it simply stops, you usually get an
error message, and life goes on as before.
But here’s the important thing: nothing you do can hurt the computer. I’m men-
tioning this because exploding computers are a staple of movie and television science
fiction, but this is one case where art is definitely not imitating life. Even in the old days
I described above, it just took some time and patience to put things right. Today it’s
much easier. But programming of the sort we’re doing here is essentially risk free.
You can’t damage the computer.
I have made every error, every mistake, every stupid bug and oversight and dumb
move it’s possible to make in programming. On hundreds of computers. And not once
has a bug resulted in a shower of sparks or caused smoke to billow from the box. I’ve
never made a disembodied voice repeat, “Does not compute, does not compute,” faster
and faster until the machine blew up. No matter how exciting that is in the movies, real
computers don’t fail like that, and modern computers just can’t get broken by the sort
of programs we’ll be writing with Processing. Don’t fear a crash. It’s annoying but
harmless. For our purposes, the computer is essentially indestructible.
Write your programs and run them freely. Experiment like mad. Play fearlessly!
Try wild stuff that might produce crazy and unpredictable results. There’s no risk. The
worst that can happen is that, very rarely, you’ll have to reboot the computer. So don’t
worry about the hardware: you can’t damage the computer.
If you’re working at home, it’s a drag to see your program crash, but as I said, it
happens to us all. So you debug your program, using the techniques we’ll see throughout
this book. You find the cause of the crash, you fix the program by typing in new lines of
text to replace the ones that were making trouble, and you run your program again. If it
crashes again, you fix it again. Once you get your programming sea legs, your programs
will crash a lot less frequently, and you’ll be able to find and fix the problems faster and
faster.
Of course, if your program is running at an art gallery, party, dance club, courtroom,
or some other public space, a crash would be embarrassing (at the least). So you’ll
want to test your program pretty thoroughly at home before taking it out into public.
Everyone loves a puppy even if it’s not yet housebroken, but nobody loves a buggy
program, no matter how cute it is.
i 16:08:24. i
i i
i i
i i
1.3. Planning 7
One way to get your code to work right is to try lots of little side experiments.
Suppose you’re a chef developing a new salad recipe, and you want to include spiced,
candied walnuts. But not just any spice will do; you need to find just the right taste.
You’d probably cook up a bunch of walnuts and taste them, adjust your recipe, and
try again, over and over. You probably wouldn’t create the whole salad every time,
particularly during this early stage. You’d focus just on the walnuts in isolation. When
they seemed close to right, then perhaps you’d mix them into the whole salad to see
how they’d taste in context. Then you could continue to adjust them until they fit in the
mix just right.
So too with programming. When you’re having trouble figuring out how to do a
particular thing, you’ll often write a new little program. I think of this as writing a
program “off to the side.” It lets you focus on just one issue, without all the other stuff
in your program complicating matters. When you solve the problem, you can then copy
and paste your solution into your big program and tweak it as needed to make it fit
smoothly with everything else your program does.
Although it’s rare, sometimes your program can cause Processing to lock up and be-
come unresponsive, or the Processing environment itself can crash and essentially stop
running. If you hadn’t saved your work before you ran your program, and Processing
freezes or crashes, then it will be too late to save it.
Some development environments save your changes each time you run your pro-
gram, but the most recent version of Processing as of now (Version 1.1) doesn’t do that.
Until Processing saves your changes for you automatically, I recommend you get in
the habit of saving your changes every time you run your program. Saving your work
frequently is a good idea no matter what program you’re running on your computer,
from a word processor to an image editor, and Processing is no different. Over time,
my fingers have become trained to press the shortcuts for Save and then Run every time
I make a change. If for any reason things do go horribly wrong and Processing crashes,
then I can restart Processing and pick right up where I left off.
1.3 Planning
So far I’ve been describing programming as a kind of seat-of-the-pants process, and
that’s the kind of work you’ll probably do most of the time when you’re developing
visual pieces using Processing. These projects tend to be small and self-contained, and
are the sort of thing you do all by yourself or with a small group of collaborators. These
kinds of projects develop and change as you work, as you discover new approaches,
throw out old ideas and create new ones, and adjust and changes things as you proceed.
If this sounds to you like the process of painting with acrylics, or writing a song, or
developing a character for a movie, that’s no coincidence. Change and discovery are
parts of all creative processes.
This is not, however, the way big commercial software gets made. There is an en-
tire professional discipline called software engineering that has produced a wealth of
i 16:08:24. i
i i
i i
i i
8 1. Overview
techniques and tools for building big programming projects. This is hard stuff, and for
some projects (like a new national air-traffic control system), it is almost unbelievably
complex. Everything has to be thought out and planned ahead of time, every possi-
ble bug has to be anticipated (as much as possible), every possible kind of user input
and user error and computer failure has to be considered, every tiny thing has to be
thought through and checked and double-checked. It’s like planning the world’s tallest
skyscraper.
Operating systems share this kind of huge complexity. So the next time your com-
puter’s operating system freezes up or misbehaves, rather than feel fury at the incom-
petent boobs who wrote that software (which I admit is a natural reaction), think of
the millions (literally, millions!) of lines of code that they had to write and the billions
(again, literally billions) of things it’s done correctly for you over the last day or two
(many of these things are happening behind the scenes, but every time your computer
talks to the web, or reads the disk, or moves the cursor when the mouse moves, it’s
happening because of some piece of code somewhere, written by a real human being).
There just isn’t any way to make something like that bug free. So people work incred-
ibly hard to try to design the system up front, before the first line of code is typed, so
that the bugs are minimized.
In some ways, it’s like working out the chord progression for a song before starting
on the melody, or making color studies and sketches before starting an oil painting.
You hope that by planning your project well beforehand, you’ll have a better chance of
pulling it off successfully.
And you can indeed plan out your sketches in Processing. If you start writing some
big projects, a little planning can help. When we get to Chapter 24, I’ll invite you to
develop a couple of projects that will reward a bit of planning and strategizing. But you
usually don’t have to go too far in the process, and you often don’t have to plan at all.
One of the pleasures of the Processing language is that because it’s been so streamlined
for graphics, you can really make it up as you go along and get a fine result. If when
you’re done you want to rewrite the whole thing so that it’s faster or better organized,
that’s fine, but you don’t have to do that.
1.4 Commenting
Although we all try to write programs that are easy to read and make sense of, some-
times it helps to have a little note to explain (or remind you) what’s going on and why.
So all computer languages, including Processing, make it easy to include text in your
program that you know the computer will ignore. It’s there just for the human beings
who read the code. This kind of free-form text is called a comment. Often a comment
will be just a single line, describing what its related code is meant to accomplish. You
can also write whole paragraphs or more, and people often do.
It’s a generally agreed truth in programming that comments are good, and generally
speaking, more comments are better. You can go overboard, of course, but that’s very
i 16:08:24. i
i i
i i
i i
1.5. Entering Programs 9
rare. The much more common case is code with no comments at all. If the names of the
objects in a program are short or cryptic, trying to figure out what a program is doing
can become a serious challenge. If you have to read someone else’s code and there are
no comments to guide you, you’ll probably wish they had provided some. If you’re
reading your own code months after you wrote it and there are no comments to guide
you, you’ll have some choice words for your past self.
The main reason why people don’t comment is, of course, laziness. The computer
doesn’t care if you have comments (because it ignores them), so there’s no material
advantage while programming to write a comment. And writing a comment will slow
you down. And if you later change your code, you’ll have to remember to go back
and change your comments. And comments can make your program look longer. And
besides, surely your code is so beautiful and crystal clear that it’s self-explanatory. All
true, and all rationalizations. Comments are good. More comments are better.
Yet you’ll find that in this book there are very few comments in the code. After
what I just said? Yes, I’m granting myself an exemption. The real reason is because the
entire book can be seen as comments on the code! Most of the prose here discusses the
strategies and techniques of the programs that we’ll be discussing, so in a real sense,
the book itself is a giant set of comments. Also, I build up each program slowly, often
just a few lines at a time, with discussion, so if you’re reading along, you’ll be familiar
with each line. Even so, I’d have included more comments except that they really do
make a listing longer, and in a book, that’s not good. Reading a program in a book is
hard; if the comments make the program span multiple pages, that makes it all the more
difficult. So my commenting will typically be sparse. Even so, I encourage you to do
as I say and not as I’ve done. In fact, I usually comment my code pretty well, and I
deliberately held back in these programs to keep them short and small on the page.
1.5 Entering Programs

Because most of the programs in this book are of a manageable size, and we’ll be
building them up in pieces, I strongly urge you to type them in yourself.
But you’ll see that every time I make a change (or a little batch of changes) to a
program, I’ve included a pointer to a saved version of the program on the website. So
you could just download every program and run it and never type a thing yourself. I
strongly encourage you not to do that!
The online listings are there to help you follow the changes we make as a program
grows. I tried a lot of different ways to help guide you to see just where new code
goes into existing programs, but everything from line numbers to graphic diagrams has
significant drawbacks that can be more confusing than helpful. So I decided that I’d
describe where the new code goes in words, and I’d give you the entire, complete new
listing after every change. If you don’t see where a new line or two is supposed to go,
you can compare the “before” and “after” listings to see where the changes occurred.
i 16:08:24. i
i i
i i
i i
10 1. Overview
Each of these listings is the complete text of the program up to that point. So you
can copy the contents of these text files, paste them into your sketch window, and run
them. If you get out of sync with the discussion, this will help you get caught right back
up again.
I’ve also included the complete source code that generated every Processing-made
figure in this book. Even the buggy ones. You should be able to regenerate every
Processing image in the book with these listings.
But as much as possible, type the code yourself. In terms of muscle memory, pro-
gramming has a lot in common with playing the piano. When I want to play a particular
chord in a way I often play it, my fingers are able to just plunk right down on the key-
board in the right place, seemingly all by themselves. That chord is a single “chunk”
in my mind. If I’m reading a song from sheet music and the chord symbol says “E-flat
major seventh,” my left hand goes thunk and there it is, positioned over the keys, fingers
poised and ready to play. One step, no thinking, freeing me up to think about how to
play the melody, or sing the lyrics, or otherwise perform the song. I’m not swamped by
the task of translating “E-flat major seventh” into a collection of notes, and then work-
ing out which fingers should press which keys. This only comes about one way: having
done it over and over and over again.
And so it is with programming. When your head calls for some structure, say “Let’s
count from 0 to 38 by 2,” your fingers can essentially go into action almost by them-
selves, typing the letters and symbols and semicolons and parentheses and everything
else that’s required. Bang. Practically all by themselves. This is a great thing because
it frees your mind up to stick with the larger concepts you’re juggling to make your
project.
And as with the piano, this facility comes about in one way only: doing it over and
over and over again. In the beginning it takes time and focus. You have to remember
each character. You have to think about each statement and where each semicolon goes.
Does this need to be a round parenthesis or a square bracket? Do I put a comma here,
or there? And so on. And after doing it a bunch of times, you’ll find that the answers
come more easily, and faster. And then one day when you need to write that kind of
code again, it’ll just pour right out of your fingers by itself, and you’ll be watching with
half an eye for little typos while your brain is thinking about the big ideas.
This facility with typing your programs is hard to over-emphasize. It’s what lets
you move from spectator to participant, and enables you to build rich and interesting
programs you can run and share.
So type everything in. The more you do it, the better you’ll be at programming.
When you can toss around the little ideas freely, the big ideas become easier to find
and hold.
1.6 Programming as Expression

This book is not organized like most books that discuss programming. I touched on this
in the Preface and a little bit above as well. There are lots of books on programming that
i 16:08:24. i
i i
i i
i i
1.6. Programming as Expression 11
are available to you right now. There are books on programming in general and books
specifically targeted at every language that’s out there. Some of the popular languages
have a dozen or more books. And many of those books are excellent. I’ve learned many
programming languages from that type of book.
But those books have always had one thing missing for me and that’s the process of
programming. The attitude. That’s often the hardest thing to learn. Each programming
language and each development environment rewards a particular attitude.
If you’ve worked in other art media, you’re probably familiar with this. In water-
colors or sumi ink, for example, you often plan your strokes carefully and then you
commit. Once you’ve made a stroke, it’s done, and that’s it. You can erase it, of course,
but part of the mental discipline of the form is to plan and commit. If you want to excel
at those media, you’re going to find the road is easiest to travel if you adopt that attitude.
When carving stone, this kind of working style is even more important.
In contrast, when finger painting, your best work might be done when you’re in a
completely impulsive mood, acting spontaneously and carefree, choosing your colors
and shapes and everything without a thought, just go go go on pure intuition. If you
haven’t finger painted recently, give it a try; it’s just as much fun as it was when you
were a kid! Great finger paintings come from this kind of unplanned play.
Every medium can be approached in an infinite number of ways, of course. But
many media reward attitudes that are in harmony with the tools and techniques of that
medium. By adopting one of those attitudes, you’ll find yourself in tune with the mate-
rials, and you’ll be working with them, not against them. If you’re building sandcastles
on the beach, don’t try to fight the tide. Don’t treat marble like clay and try to bend it.
Don’t push ropes. Address each medium the way it responds to best.
Programming is the same way. Each language, each system, has a slightly different
attitude. Some of the specialized programming languages, such as those written for
mathematicians or biologists, really shine when you come to them with a mathemati-
cian’s or biologist’s state of mind.
So where do you find that attitude? Where do you find the work style, the habits?
Where do you learn how to start a project, how to build it up, when to go forward,
when to go back? How do you know when you’re on the right track, or running down
a dead-end street? How do you take a big idea and turn it into manageable pieces
that you can build up one step at a time? These questions, and many others, are the
essence of programming. The mechanics of semicolons and syntax you’ll pick up in no
time; that’s just typing. Writing a program is mostly about thinking through the ideas,
inventing approaches, and making them work. How do you do that? What’s the right
attitude?
Every successful programmer will give you a different answer. But you have to start
somewhere.
You can, of course, start at zero and come up with a style all by yourself. Lots of
very successful people have done that.
But a perfectly valid alternative is the model of the apprentice: you work under a
master and learn attitude and technique by watching and emulating. Over time, you can
i 16:08:24. i
i i
i i
i i
12 1. Overview
experiment with those work habits, varying them and trying alternatives, developing
your own style. If you’ve chosen a good model to emulate, then you get a huge head
start on the process.
After decades of writing untold thousands of programs, I think I’ve found a good
style and a good attitude. I’m productive and I write code that I can read, debug, and
maintain. Other people have used my programs for their own work. I’ve come up with
a process that works very well for me.
So this book is my version of inviting you into an apprenticeship program. My
model is that we’re sitting side by side, and you’re watching over my shoulder as I
program. I’m going to share with you my programs each step of the way. When I
write code with bugs, you’ll see the code, you’ll see the bugs, and you’ll see the error
messages. When I have to find those bugs and fix them, you’ll see each step along the
way. When the results don’t look quite right to me, you’ll see me adjust them.
In short, you’ll see my process. And I hope that will help you adopt that process for
your own projects. And then, over time, I’m sure you’ll start to customize it, adding to
it, and removing from it, and changing it, until it fits you like a comfortable shirt.
In short, programming can initially look hard and challenging and weird. But it’s
not. It’s really about inventing and creating and dreaming. The rest is typing. If you
type in the programs as we go, your fingers will get used to the typing. If you stick with
the discussions, you’ll pick up a style and an attitude that will see you through many
projects. And before you know it, you’ll be a master programmer yourself, with your
own process and your own style, and you’ll be watching your fingers type the code all
by themselves while you’re dreaming of shapes and color and motion.
In other words, you’ll no longer be thinking about the brush, or the keyboard, or the
pen, or the code. You’ll be thinking about the ideas and how to communicate them.
You’ll be making art.
You’re going to love this.
Let’s dig in.
i 16:08:24. i
i i
i i
i i
Chapter 2
Setting Up
and Getting Started
The first step in getting started with Processing is to download and install it. That’s
easy, because Processing is free, and it runs beautifully on both Macs and PCs that use
Windows or Linux. You can download and install it without any worries about viruses
or other undesired surprises. Point your web browser to
http://www.processing.org/
Choose “Download” (if you’re on a Windows-based PC, I suggest you choose the
link labeled “Windows” and ignore the one labeled “Windows (Without Java)”).
You may be offered your choice of versions. Most of the examples in this book
were produced with Version 1.1. Generally, you should pick the most recent version
available. If your version is newer than the one I used, everything in this book should
still run perfectly well. You may even find that some of the bugs I encountered (and I
point out in the text) have been fixed.
Once you’ve downloaded the package, install it by following the usual routine for
installing programs on your system. The result is a program called Processing installed
on your hard drive. Start it up!
When you run Processing, it will pop up a window for you. This is where you do all
your communicating with Processing, so let’s go over the pieces briefly so you’ll know
your way around. This window will soon feel like a second home to you.
Processing’s window will look something like Figure 2.1.
At the top is the menu bar, which has the traditional sorts of menu items like File,
Edit, and so on. You may be used to seeing these at the top of the screen (on Macs, for
instance), but in Processing they’re all there in the Processing window. Below the menu
bar is the toolbar, which has just a half-dozen buttons. The round buttons let you run
your program and stop it. The square buttons are shortcuts for opening and saving your
files.
13
i 16:08:38. i
i i
Another random document with
no related content on Scribd:
Swiss
Hans Huber (1852–1921)
Russian
Anton Rubinstein (1830–1894)

Peter Iljitch Tchaikovsky (1840–1893)
Nikolai Rimsky-Korsakov (1844–1908)
Serge Liapounov (1859)
Anton Arensky (1861–1906)
Georg Lvovitch Catoire (1861–1926)
Alexander Glazounov (1873)
Alexander Scriabin (1872–1915)
Serge Rachmaninov (1873)
Josef Hofmann (1876)
Fedor Akimenko (1876)
Nicolai Miaskovsky (1881)
Igor Stravinsky (1882)
Serge Prokofiev (1891)
Alexander Tcherepnin (1902)
Polish
Frédéric Chopin (1809–1849)

Joseph Wieniawski (1837–1912)
Philipp Scharwenka (1847–1917)
Franz Xaver Scharwenka (1850–1924)
Ignace Jan Paderewski (1860)
Emil Mlynarski (1870)
Sigismund Stojowski (1870) (Living in America)
Karol Szymanowski (1883)
Finnish
Jan Sibelius (1865)

Selim Palmgren (1878)
Scandinavian
Eduard Lassen (Danish) (1830–1904)

August Winding (Danish) (1835–1899)
Emil Hartmann (Danish) (1836–1898)
Johan Svendsen (Norwegian) (1840–1911)
Edvard Grieg (Norwegian) (1843–1907)
Christian Sinding (Norwegian) (1856)
Johan Halvorsen (Norwegian) (1864)
Tor Aulin (Swedish) (1866–1914)
Wilhelm Stenhammar (Swedish) (1871)
Hugo Alfven (Swedish) (1872)
Halfdan Cleve (Norwegian) (1879)
Kurt Atterberg (Swedish) (1887)
Italian
Giuseppe Martucci (1856–1909)

Alberto Franchetti (1860)
Enrico Bossi (1861–1925)
Ferruccio Busoni (1866–1924)
Leone Sinigaglia (1868)
Ottorino Respighi (1879)
G. Francesco Malipiero (1882)
Alfredo Casella (1883)
Spanish
Isaac Albéniz (1860–1909)

Manuel de Falla (1876)
Joan de Manen (1883)
English
John Field (1782–1837)

William Sterndale Bennett (1816–1875)
Frederick Hymen Cowen (1852)
Tobias Matthay (1858)
Frederick Delius (1863)
Eugen d’Albert (Scotch) (1864)
Arthur Hinton (1869)
Samuel Coleridge-Taylor (1875–1912)
Wm. Y. Hurlstone (1876–1906)
Cyril Scott (1879)
York Bowen (1884)
Arthur Bliss (1891)
Dorothy Howell (20th Century)
American
Leopold Damrosch (German) (1832–1885)

Frederick Grant Gleason (1848–1903)
Max Vogrich (Transylvanian) (1852–1916)
Helen Hopekirk (Scotch) (1856)
Harry Rowe Shelley (1858)
Victor Herbert (1859–1924)
Edward MacDowell (1861–1908)
Edmund Severn (1862)
Henry Holden Huss (1862)
Mrs. H. H. A. Beach (1867)
Ernest Hutcheson (Australian) (1871)
Felix Borowsky (1872)
Arne Oldberg (1874)
Ernest Schelling (1876)
John Alden Carpenter (1876)
Blair Fairchild (1877)
John Powell (1882)
Louis Gruenberg (1884)
Cecil Burleigh (1885)
George F. Boyle (Australian) (1886)
Albert Spalding (1888)
A. Walter Kramer (1890)
Mana Zucca (1893)
Leo Ornstein (Russian) (1895)
Leo Sowerby (1895)
Aaron Copland (1898)
Symphonies
German and Austrian
Franz Xaver Richter (1709–1789)

Karl Philip Emanuel Bach (1714–1788)
Johann Stamitz (1717–1757)
Franz Joseph Haydn (1732–1809)
Michael Haydn (1737–1806)
Johann Christian Bach (1738–1782)
K. D. von Dittersdorf (1739–1799)
Karl Stamitz (1746–1801)
Wolfgang Amadeus Mozart (1756–1791)
Ludwig von Beethoven (1770–1827)
Ludwig Spohr (1784–1859)
Carl Maria von Weber (1786–1826)
Franz Schubert (1797–1828)
Franz Lachner (1803–1890)
Felix Mendelssohn-Bartholdy (1809–1847)
Otto Nicolai (1810–1849)
Robert Schumann (1810–1856)
Robert Volkmann (1815–1883)
Joseph Joachim Raff (Swiss) (1822–1882)
Anton Bruckner (1824–1896)
Johannes Brahms (1833–1897)
Max Bruch (1838–1920)
Herman Goetz (1840–1876)
August Klughardt (1847–1902)
Felix Weingartner (1863)
Richard Strauss (1864)
Georg Schumann (1866)
Siegmund von Hausegger (1872)
Alexander von Zemlinsky (1872)
Karl Bleyle (1880)
Heinz Tiessen (1887)
Ernst Toch (1887)
Eduard Erdmann (20th Century)
Dance Symphony
Egon Wellesz (1885)

Ernst Krenek (1900)
Czecho-Slovakian
Frederic Smetana (1824–1884)

J. J. Abert (1832–1915)
Antonin Dvorak (1841–1904)
Gustav Mahler (1860–1911)
Josef Suk (1874)
Otakar Ostrcil (1879)
Emil Axman (20th Century)
Erwin Schulhoff (1894)
Hungarian
Franz Liszt (1811–1886)

Karl Goldmark (1830–1915)
Julius Major (1859)
Emanuel Moor (1862)
Ernst von Dohnanyi (1877)
French
François Joseph Gossec (Belgian) (1734–1829)

Henri Méhul (1763–1817)
Hector Berlioz (1803–1869)
Napoleon Henri Reber (1807–1880)
Charles François Gounod (1818–1893)
César Franck (Belgian) (1822–1890)
Edouard Lalo (1823–1892)
Camille Saint-Saëns (1835–1921)
Charles Widor (1845)
Gabriel Fauré (1845–1924)
Agusta Holmes (English) (1847–1903)
Vincent d’Indy (1851)
Ernest Chausson (1855–1899)
André Gédalge (1857–1926)
Guy Ropartz (1864)
Paul Dukas (1865)
Alberic Magnard (1865–1914)
Albert Roussel (1869)
Henri Rabaud (1873)
Darius Milhaud (1892)
Belgian
Théophile Ysaye (1865–1918)
Dutch
Richard Hol (1825–1904)

Bernard Zweers (1854)
Julius Roentgen (1855)
Cornelius Dopper (1870)
Bernard Dieren (1884)
Willem Pijper (1894)
Swiss
Hans Huber (1852–1921)
Roumanian
Georges Enesco (1881)
Russian
Joseph Wihtol (1863)
Alexander Gretchaninov (1864)
Vassili Kilinnikov (1866–1900)
Paul Juon (1872)
Serge Vassilenko (1872)
Reinhold Glière (1875)
Nicholas Miaskovsky (1881)
Lazare Saminsky (1883)
Polish
Philipp Scharwenka (1847–1917)

Franz Xaver Scharwenka (1850–1924)
Emil Mlynarski (1870)
Sigismund Stojowski (1870) (Living in America)
Miecyslaw Karlowicz (1876–1909)
Felix Nowowiejski (German) (1877)
Finnish
Jan Sibelius (1865)

Leevi Madetoja (1887)
Scandinavian
Johan P. E. Hartmann (Danish) (1805–1900)

Niels Gade (Danish) (1817–1890)
Eduard Lassen (Danish) (1830–1904)
Emil Hartmann (Danish) (1836–1898)
Johan Svendsen (Norwegian) (1840–1911)
Peter Lange-Müller (Danish) (1850–1926)
Jacob Adolph Hagg (Swedish) (1850)
Victor Bendix (Danish) (1851)
Christian Sinding (Norwegian) (1856)
A. Carl Nielson (Danish) (1864)
Wilhelm Stenhammar (Swedish) (1871)
Sigurd Lie (Norwegian) (1871–1904)
Natanael Berg (Swedish) (1879)
Kurt Atterberg (Swedish) (1887)
Italian
Giovanni Battista Sammartini (1704–1774)

Carlo Toeschi (1724–1788)
Luigi Boccherini (1743–1805)
Giovanni Toeschi (1745–1800)
Antonio Salieri (1750–1825)
Muzio Clementi (1752–1832)
Giovanni Sgambati (1843–1914)
Giuseppe Martucci (1856–1909)
Franco Alfano (1877)
Ildebrando Pizzetti (1880)
Victor da Sabata (1896)
Spanish
English
Sir G. A. Macfarren (1813–1887)

Sir Arthur Sullivan (1842–1901)
Sir Charles Hubert H. Parry (1848–1918)
Sir Frederick H. Cowen (1852)
Sir Charles V. Stanford (1852–1924)
Sir Edward Elgar (1857)
Ethel M. Smyth (1858)
Algernon Ashton (1859)
Granville Bantock (1868)
Walford Davies (1869)
Percy Pitt (1870)
Ralph Vaughn Williams (1872)
Gustav Holst (1874)
Hamilton Harty (1879)
York Bowen (1884)
Benjamin Dale (1885)
Arthur Bliss (1891)
American
Leopold Damrosch (1832–1885)

John Knowles Paine (1839–1906)
Silas G. Pratt (1846–1916)
Max Vogrich (Transylvania) (1852–1916)
George Chadwick (1854)
George Templeton Strong (1856)
Arthur Bird (1856–1924)
Edgar Stillman Kelley (1857)
Henry Schoenefeld (1857)
Charles Martin Loeffler (1861)
Ernest Kroeger (1862)
Horatio Parker (1863–1919)
Gustav Strube (1867)
Mrs. H. H. A. Beach (1867)
Howard Brockway (1870)
Henry K. Hadley (1871)
Frederick Converse (1871)
Daniel Gregory Mason (1873)
Arne Oldberg (1874)
Mortimer Wilson (1876)
David Stanley Smith (1877)
Ernest Bloch (Swiss) (1880)
Eric Delamarter (1880)
Edwin Grasse (1884)
Frederick Jacobi (1891)
Orchestral Music
Symphonic Tone Poems, Overtures, Suites, etc.
German and Austrian
Ludwig van Beethoven (1770–1827)

Carl Maria von Weber (1786–1826)
Felix Mendelssohn-Bartholdy (1809–1847)
Robert Schumann (1810–1856)
Richard Wagner (1813–1883)
Johann Strauss (1825–1899)
Johannes Brahms (1833–1897)
Alexander Ritter (1833–1896)
Heinrich Hofmann (1842–1902)
Engelbert Humperdinck (1854–1921)
Felix Weingartner (1863)
Richard Strauss (1864)
Georg Schumann (1866)
Max von Schillings (1868)
Siegmund von Hausegger (1872)
Paul Juon (Russian) (1872)
Max Reger (1873–1916)
Arnold Schoenberg (1874)
Paul Amadeus Pisk (1893)
Paul Hindemith (1895)
Erich Korngold (1898)
Czecho-Slovakian
Frederick Smetana (1824–1884)

Antonin Dvorak (1843–1904)
Zdenko Fibich (1850–1900)
Vitezslav Novak (1870)
Josef Suk (1874)
Otakar Ostrcil (1879)
Rudolf Karel (1881)
Karl Horwitz (1884–1925)
Bohuslav Martinu (1890)
Fidelio Finke (1891)
Tone Poems
Hungarian
Franz Liszt (1811–1886)

Karl Goldmark (1830–1915)
Emanuel Moor (1862)
Ernst von Dohnanyi (1877)
Béla Bártok (1881)
Zoltan Kodaly (1882)
George Kosa (1897)
French
Hector Berlioz (1803–1869)

Félicien David (1810–1876)
César Franck (Belgian) (1822–1890)
Camille Saint-Saëns (1835–1921)
Theodore Dubois (1837–1924)
Georges Bizet (1838–1875)
Alexis Emanuel Chabrier (1841–1894)
Jules Massenet (1842–1912)
Vincent d’Indy (1851)
Ernest Chausson (1855–1899)
Georges Huë (1858)
Gustave Charpentier (1860)
Claude Achille Debussy (1862–1918)
Guy Ropartz (1864)
Erik Satie (1866–1925)
Charles Koechlin (1867)
Florent Schmitt (1870)
Deodat de Sévérac (1873–1921)
Henri Rabaud (1873)
Max d’Ollone (1875)
Roger Ducasse (1875)
Maurice Ravel (1875)
Louis Aubert (1877)
André Caplet (1878–1925)
Gabriel Grovlez (1879)
Maurice Delage (1879)
Jacques Ibert (1890)
Roland Manuel (1891)
Darius Milhaud (1892)
Arthur Honegger (1892)
Lili Boulanger (1893–1918)
Belgian
Théophile Ysaye (1865–1918)

Paul Gilson (1865)
Guillaume Lekeu (1870–1894)
Joseph Jongen (1873)
M. Brusselmans (20th Century)
Dutch
Richard Hol (1825–1904)

Julius Roentgen (1855)
Alfons Diepenbrock (1862–1921)
Johan Wagenaar (1862)
Bernard van Dieren (1884)
Roumanian
Georges Enesco (1881)
Russian
Anton Rubinstein (1829–1894)

Alexander Borodin (1834–1877)
Cesar Cui (1835–1918)
Mily Balakirev (1837–1910)
Piotr I. Tchaikovsky (1840–1892)
Anatole Liadov (1855–1914)
Ivanov Ippolitov (1859)
Antonin Arensky (1861–1906)
Vassili Kilinnikov (1866–1900)
Paul Juon (1872)
Reinhold Glière (1875)
Nicholai Miaskovsky (1881)
Igor Stravinsky (1882)
Michael Gniessen (1883)
Serge Prokofiev (1891)
Polish
Jean Louis Nicodé (1853)

Sigismund Stojowski (1870)
Miecyslaw Karlowicz (1876–1909)
Ludomir Rozycki (1883)
Alexandre Tansman (1892)
Finnish
Robert Kajanus (1856)

Jan Sibelius (1865)
Armas Järnefelt (1869)
Leevi Madetoja (1887)
Scandinavian
Edvard Hagerup Grieg (1843–1907)
Anders Hallen (1846)
Otto Malling (1848–1915)
Peter Lange-Müller (1850–1926)
Ludwig T. Schytte (1850–1909)
Gerhard Schjelderup (1859)
Hugo Alfven (1872)
Natanael Berg (1879)
Kurt Atterberg (1887)
Italian
Enrico Bossi (1861–1925)

Ferruccio Busoni (1866–1924)
Leone Sinigaglia (1868)
Ottorino Respighi (1879)
Ildebrando Pizzetti (1880)
Vincenzo Tommasini (1880)
Riccardo Pick-Mangiagalli (1882)
Guido Guerrini (1890)
Spanish
Felipe Pedrell (1841–1922)

Isaac Albeniz (1860–1909)
Enrique Granados (1867–1916)
Pablo Casals (1876)
Joaquin Turina (1882)
Brazilian
Villa-Lobos (1892)
English
Arthur Sullivan (1842–1900)

Alexander Campbell Mackenzie (1847)
Charles Hubert Hastings Parry (1848–1918)
Charles Villiers Stanford (1852–1924)
Edward Elgar (1857)
William Wallace (1860)
Edward German (1862)
Frederick Delius (1863)
Granville Bantock (1868)
Cecil Forsyth (1870)
Ralph Vaughn Williams (1872)
William H. Bell (1873)
Gustav Holst (1874)
Samuel Coleridge-Taylor (1875–1912)
Norman O’Neill (1875)
H. Balfour Gardiner (1877)
Josef Holbrooke (1878)
Cyril Scott (1879)
Frank Bridge (1879)
Arnold Bax (1883)
Lord Berners (1883)
York Bowen (1884)
Armstrong Gibbs (1889)
Arthur Bliss (1891)
Eugene Goossens (1893)
American
John Knowles Paine (1839–1906)

Silas G. Pratt (1846–1916)
Frederick Grant Gleason (1848–1903)
Arthur Foote (1853)
George Chadwick (1854)
George Templeton Strong (1856)
Frank Van der Stucken (1858–1929)
Victor Herbert (1859–1924)
Edward MacDowell (1861–1908)
Charles Martin Loeffler (1861)
Ernest Kroeger (1862)
Carl Busch (Danish) (1862)
Horatio W. Parker (1863–1919)
Henry K. F. Gilbert (1868–1928)
William H. Humiston (1869–1924)
Frederick Converse (1871)
Henry K. Hadley (1871)
Frederick Stock (German) (1871)
Frank E. Ward (1872)
Rubin Goldmark (1872)
Edward Burlingame Hill (1872)
Felix Borowsky (Polish-English) (1872)
Camille Zeckwer (1875–1924)
Mortimer Wilson (1876)
John Alden Carpenter (1876)
Rudolph Ganz (Swiss) (1877)
Blair Fairchild (1877)
David Stanley Smith (1877)
Franz C. Bornschein (1879)
Ernest Bloch (Swiss) (1880)
Arthur Shepherd (1880)
John Powell (1882)
Carl Ruggles ?
Edgar Varese (French) ?
Reginald Sweet ?
Percy Grainger (Australian) (1882)
Charles Griffes (1884–1920)
Emerson Whithorne (1884)
Albert Elkus (?)
Deems Taylor (1885)
Edward Ballantine (1886)
Wintter Watts (1886)
Victor Kolar (Hungarian) (1888)
Harold Morris (1889)
Frederick Jacobi (1891)
Timothy Spelman (1891)
Albert Stoessel (1894)
Sandor Harmati (1894)
Leo Sowerby (1895)
Howard Hanson (1896)
Chamber Music
(String Quartets, Trios, Quintets, etc., various
combinations of Instruments.)
(BEFORE HAYDN)
English
Thomas Morley (1557–1604)

John Jenkins (1592–1678)
Mathew Locke (1632–1677)
Henry Purcell (1658–1695)
Italian
Salomon Rossi (1598–1623)

Tarquinio Merula (Born before 1600)
Giovanni Battista Fontana (Born before 1600–1630)
Carlo Farino (17th century, dates unknown)
Giovanni Legrenzi (1625–1690)
Giovanni Battista Vitali (1644–1692)
Arcangelo Corelli (1653–1713)
Alessandro Scarlatti (1659–1725)
Antonio Vivaldi (1675–1743)
Francesco Geminiani (1680–1762)
Giuseppe Tartini (1692–1770)
Antonio Veracini (Late 17th Century, dates unknown)
Pietro Locatelli (1693–1764)
Giovanni Battista Pergolesi (1710–1736)
Felice de Giardini (1716–1796)
Pietro Nardini (1722–1793)
Giovanni Battista Sammartini (1730–1770)
Gaetano Pugnani (1731–1798)
Luigi Boccherini (1743–1805)

PDF Processing For Visual Artists How To Create Expressive Images and Interactive Art 1St Edition Andrew Glassner Ebook Full Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PDF Processing For Visual Artists How To Create Expressive Images and Interactive Art 1St Edition Andrew Glassner Ebook Full Chapter

Uploaded by

Copyright:

Available Formats

Processing for Visual Artists: How to

Create Expressive Images and

Light for Visual Artists Second Edition Understanding

How to Create Manga Drawing the Human Body The Ultimate

Understanding Kids, Play, and Interactive Design :How

Deep Learning Vol 2 From Basics to Practice Andrew

Deep Learning Vol 1 From Basics to Practice Andrew

Programming Kotlin Create Elegant Expressive and

The Art of Communication How to Be Authentic Lead

3D Game Programming for Kids Create Interactive Worlds

Boca Raton London New York

CRC Press is an imprint of the

Editorial, Sales, and Customer Service Office

© 2010 by Coyote Wind, LLC

No claim to original U.S. Government works

ISBN 13: 978-1-138-46085-0 (hbk)

Library of Congress Cataloging-in-Publication Data

T385.G5853 2010 006.6’96--dc22

–Burne Hogarth, Dynamic Figure Drawing, Watson-Guptill, 1970

Processing for Visual Artists

2 Setting Up and Getting Started 13

3 Basic Ideas: Variables 23

4 Functions and Tests 43

6 Graphics Primitives 101

7 Human Input 131

8 Loops and Transparency 159

11 Randomness and Arrays 223

12 Catmull-Rom Curves 269

13 Bézier Curves 313

15 Fall Leaves 395

17 Working with Files 503

18 Creating Patterns 537

19 An Action Lamp 605

22 Useful Odds and Ends 771

24 Big Projects 871

1.1 What Is Processing?

1.2. Experiment Freely! 3

1.2 Experiment Freely!

1.2. Experiment Freely! 5

1.5. Entering Programs 9

1.5 Entering Programs

1.6 Programming as Expression

1.6. Programming as Expression 11

Hans Huber (1852–1921)

Anton Rubinstein (1830–1894)

Frédéric Chopin (1809–1849)

Jan Sibelius (1865)

Eduard Lassen (Danish) (1830–1904)

Giuseppe Martucci (1856–1909)

Isaac Albéniz (1860–1909)

John Field (1782–1837)

Leopold Damrosch (German) (1832–1885)

German and Austrian

Franz Xaver Richter (1709–1789)

Egon Wellesz (1885)

Frederic Smetana (1824–1884)

Franz Liszt (1811–1886)

François Joseph Gossec (Belgian) (1734–1829)

Théophile Ysaye (1865–1918)

Richard Hol (1825–1904)

Hans Huber (1852–1921)

Georges Enesco (1881)

Philipp Scharwenka (1847–1917)