Processing: Creative Coding and Computational Art

By using functions to organize a program, you get the benefit of modularity, but also the
burden of added abstraction. It doesn’t help that so many of the parameters are index
positions in arrays. However, with a sketch this complex, you need ways of cutting down
on the variable clutter. Another, and better, way to code this sketch would be using an
object-oriented approach. This would allow for even greater modularity and potential
code reuse. For example, I could create a class for each of the main elements in the
sketch: Particle, Emitter, Dynamics, Wave, World, and so forth. This would allow me to
really encapsulate the functionality of each of these constructs. I would also design the
relationships between these different classes. Of course, this approach also brings lots of
added abstraction to the process, so it’s not the best approach for new coders. Later in the
book, when you’re an old, salty hackster, I’ll approach some problems using objectoriented
programming (OOP). Before moving on, though, I want go over a few elements in
the last particle wave example.
I avoided global variables and declared local variables within the functions. This encourages
code reuse, as each function is a self-contained processing unit. To use the function,
you just need to know the parameter list, or the interface to the function. The parameter
list shows the input that the function requires to do its thing. The return type of the function
shows what value, if any, the function returns when it is called. For example, the float
makeWaves() function returns a float value every time it’s called. Returning a value should
not be confused with outputting something to the display window. The plot() function,
for example, outputs points to the screen, but the function doesn’t return any value when
it is called. Another benefit of using all local variables defined within functions is that there
is no danger of name collisions. I can use the same named variables in each function without
any ambiguity because each variable has local scope. If I need the value of a variable
outside the function, I need to pass it as an argument, as I do throughout the program.
I used a bunch of convenience arrays in the setup() function. I use the term “convenience”
because I could have just passed the variables individually as arguments to the
setParticles() function. However, the parameter list, defined in the head of the
setParticles() function, would have needed to account for all these variables, including
their type. This list would have included 17 parameters. Instead, by packaging the variables
into logical arrays, I only needed to pass five arguments to the setParticles() function
(which of course needed five parameters of the same type declared in the head of
the function). The burden of this organizational abstraction is that once in the
setParticles() function, I needed to, as the function designer, carefully decode what
value each array index contained. However, since all the values required by the function
are passed in as arguments, once completed, I theoretically never have to mess with the
insides of this function again. If I want to change the output of the function, I simply
change the values I pass to it—it’s a black box construction.
One issue in this example that may be confusing to new coders is my use of function calls
within other functions, especially with regard to using a returned value in an assignment.
For example, from within the setParticles() function, I call the makeWaves() function:
// called from within the setParticles() function
x[i]=makeWaves(x[i], angle+=frequency[i], amplitude[i]);
Try not to get confused by all the array notation (all the [i]s) in the function. Everything
is efficiently getting processed in a for loop, and each of the variables is a primitive array;
CURVES
261
7