Above is the PowerPoint slideshow that Diego made for our in-class presentation. There is also copious supporting material at the following locations:

• Photos, with lots of chatty comments
  
• Videos, interspersed with kittenage
• Arduino code
• Processing code
  • colors_highlight_new_swatch – this is the color palette module. It reads a text file containing all the colors in the appropriate Krylon spraypaint line and outputs them as a grid of colored squares. The active swatch and rolled-over ones are highlighted with colored borders. It’s glitchy, as you can see if you look in the upper left corner, but basically it works.
  • spraycans – I would like to make my own set of brushes, based on Diego’s, that are all the same style but in different sizes. These would then be mapped to the number of fingers being held up, with more fingers triggering a bigger spray cone. This would make it easier for users to get predictable, slightly repeatable results. Toward that end, I made a spraycan object whose spray cone, label number (for the size), and can color (for the paint) are variable. Epileptics should probably not view this sketch.
  • Main application – The “final” in “final_application_4″ refers to the this being our final project for the semester, not to the code itself actually being final. For, verily, it is not. This is the wrapper into which all the other modules will eventually be rolled. It’s a whole lot of nested if statements and functions. This program doesn’t run unless the glove is plugged in; I should fix that, to make it easier to check code while programming.

This is the second smidgen of the code for our final project. It pulls RGB values and color names from a tab-delimited text file (which is, itself, based on the actual Krylon color options) and outputs this grid of swatches. The swatches don’t do anything yet—just drawing them took me, like, two days, thank you very much, and that was with some very helpful help from Shawn. Partly this is because I apparently can’t keep in my head for more than thirty seconds how arrays and objects work, and partly it’s because I just. can’t. focus. And partly it’s because I apparently have no idea what the fuck I’m doing.

I’m beginning to really like Diego’s Plan B, as proposed over the weekend:

Fake our own deaths.

I keep telling myself I have to not panic and just write the code one piece at a time. Then, later, I can get somebody to help me put it all together, which is something I know I have no clue how to do. But just accomplishing what seem like they should be simple things is stumping me. Most recently, I was trying to get the swatch name to be displayed when a square is rolled over. This is not by any means an important feature—in fact, it doesn’t really serve any purpose. But I should be able to do it, and I can’t figure out why it doesn’t work. I keep getting errors like “The function showName() does not exist” or “Cannot find anything named ’swatches.’” Both of these things do, of course, exist, and I can’t see any reason why they wouldn’t be found.

I know it’s pretty rare for computers to just fuck up and much more common for me to do so, so I’m sure the answer is that I’ve done something really dumb and sloppy somewhere. But it could easily take me two hours to find that error, and every new goddamn line of code seems to cause some new mysterious issue. I can feel myself growing older just thinking about it. And there are a lot more lines of code to go. Here’s the stuff I was hoping to get done, oh, by, say, last Thursday:

And that’s not including the task of sewing us a new glove, for which I bought fabric on Monday, as well as a book about how to use my virgin four-year-old Juki serger. I know that’ll be fun once I get started, but I just can’t get started.

Maybe I need a drink.

So then . . . The other day I was talking about the glove project with my friend Rose, and I rhetorically asked what the hell this kind of low-fi, large-format drawing setup would be good for. Rose’s answer was immediate: graffiti.

Duh.

So then, what we need is just a limited palette of Krylon spray paints, and a couple of brush types—say, a fat marker and three sizes of spray patterns. And then, when I asked my perpetual question of “What are the other fingers doing?,” Diego had this brilliant idea: the number of fingers you’re using determines the brush size. Index finger for the marker; index and middle for a small spray nozzle; index, middle, and ring for a medium spray; and all four fingers for the biggest spray—what you’d use to fill. That’s a pretty intuitive mapping. We wouldn’t need to track motion on all the fingers, just whether they’re flexed or not. And we could use an accelerometer to register wrist tilts, somewhat like the Rock ‘n’ Scroll, to cycle through the color palette.

The thumb would remain an on/off switch.

We could have different backgrounds to paint on, like brick walls, subway cars, trucks.

Bitchen.

This idea is, in fact, so cool that it has already been done.

Developing . . .

Photo: ASBO by rubberdreamfeet / David Hayward. Some rights reserved.

Ever since we started putting the actual glove together, I’ve been thinking about how the software side of this project should take into account what I expect to be a pretty low-resolution input system. When I was making a drawing interface for what was purely an ICM project, I was assuming an average level of mouse dexterity. The stroke-width picker that I made last Wednesday, for instance, is obviously too small to be operated with our crude pointer.

So what kind of interface would work?

I did some Googling around, to get ideas of what kind of controls can be operated with little dexterity. In particular, I looked for things you can do while wearing mittens, since I figure that that’s approximately the level of control our hypothetical user will have. Some findings:

Some military radios are touted as being usable even while wearing Arctic mittens: “The desired frequency is set by four knobs on the side of the radio which can be operated even while the operator is wearing Arctic mittens, or in the dark by counting clicks from the end-stops” (”Clansman PRC-349 / RT-349 VHF Transceiver,” Armyradio.com). Its that idea of click feedback that I find interesting. If you’re choosing from a limited set of options—say, brush sizes— on a very small display, it’s not too annoying to cycle through them one at a time to get to what you want. This is the way my cell phone, toaster, and camera menus work. And they all provide beeps or clicks for feedback. What kind of feedback will we give to let our user know what’s going on?

Other physical controls that can be operated while wearing mittens include a camera’s zoom ring and aperture and shutter speed dials (Matthew G. Monroe, “How to Shoot in Freezing Temperatures and Keep Your Hands Toasty Warm,” digital-photography-school.com); Velcro closure tabs on outerwear; and KEYnetic’s rock ‘n’ scroll cell phone interface (via LyteByte).

On the screen side of things, some relevant input methods include Morse code and onscreen keyboards. Again, I like the simplicity of tapping, though I can also see uses for a matrix of a few very large buttons.

Obviously, with two weeks to go, I don’t have time to really get into learning interface design for this project, but I think where I’m going is toward a system that has a drawing mode and a tool selection mode. When you’re drawing, there’s nothing else onscreen except maybe one or two tools or hints—how to turn the drawing line off, how to activate the control menu. You can’t select these controls onscreen, because how would you do so without drawing a line all the way to the button? And whatever gesture you use to activate the menu must be able to be done without moving the drawing pointer.

The Rock ‘n’ Scroll model is pretty good for us within one mode or another, but you have to be able to switch between the two without moving your drawing pointer. So that would involve . . . the thumb? It’s possible, though not necessarily easy, to move your thumb without moving the rest of your hand. So maybe as long as your thumb is tucked in, the pen is on, and if you stick it out, the pen is off.

Once we’ve got a way to separate the two modes, I was thinking the control screen would be super-simple, with only one control editable at a time. So, something like this:

Photo: Elephant Painting by Venson Kuchipudi. Some rights reserved.

I decided to start my final ICM project with the drawing interface, because it’s a discrete program in itself, and because I could actually sort of picture what it might look like. So I made a list of components—stroke palette, color picker, eraser, eyedropper, transparency picker, etc.—and decided to build them one at a time. At the same time, I joined forces on the Physcomp final with Diego, for his glove project that turned out to be a drawing tool, so I knew the interface might need to change, in order to work with that hardware.

It seemed like it had been weeks since I’d written sketch in Processing, so I started by rereading the chapters on objects and arrays from the book. Then I made the supersimple mouse-tracking line-drawer that we did at the beginning of the semester. And then I added a stroke-width selection palette to work with that. The first version is above. How it works:

The line turns on and off with a mouse click, so when the sketch opens, if you wave your mouse around, you get no line. Then you click once to turn the drawing tool—let’s call it a pencil—on, and you draw, draw, draw. You can click to turn off the pencil at any time, select a different stroke width, and click to start drawing again, from a new mouse position. The stroke that’s currently selected in the palette appears highlighted in green, with the line in black; all the inactive stroke sizes are gray.

What’s wrong with this interface:

1. At program launch, it’s supposed to default to the thinnest line, in black. I forgot to set that up, so instead, if you turn on the pencil without selecting a stroke width first, you get the last line style that was drawn to make the palette, which is the 16-point version in gray. Oops.
2. There’s no indicator showing whether the pencil is on or off. So a couple of times when I thought it was off, I moved my mouse and found that it was on.
3. There’s no undo. If I could undo the previous stroke, problem 2 would be surmountable.
4. There’s no eraser. This would also help with problem 2.
5. The thicker lines are not smooth. I guess this is because I’ve got the stroke ends set to square, because it made the palette look neater; either round ends need to be turned back on for drawing, or I need to interpolate the pixels between the line segments.
6. The focus highlighting on the fattest stroke in the palette isn’t wide enough.
7. You shouldn’t be able to draw behind or over the palette.

Questions:

• Clicking to turn the pencil on and off is a bit confusing, perhaps. Maybe it should be click-and-drag, instead?
• This stroke selector is probably too difficult to operate when you’re using a glove-mounted LED that’s being tracked by a camera, instead of drawing directly with a mouse. Maybe it should be a single slider, instead, for the PComp version. You basically need to be able to use this interface with mittens on.

So, obviously, I need to solve the various problems, of which #3 is probably the tricksiest. To make an undo command, I think I’ll probably save the drawing state every time the pencil is turned off. And “undo” should use the standard keyboard shortcut, of course, as well as having a button.

Once those issues are addressed, I think color is the next thing to deal with. The color picker may be so large as to have to be retractable, in which case saving the drawing state becomes even more essential.

If you have trouble imagining how one might make expressive images using tools like Processing, take a look at the beautiful pixel-style art of Craig @ Superbrothers.

Of course, some of the loveliness of these illustrations comes from the fact that they’re not made of flat, pure-hued pixels—the colored rectangles are grainy, organic, and warm. But the greater part of their success comes, I think, from the concision of the shapes. So much information is conveyed by so few squares.

If you can channel that kind of economy, you can probably draw with anything.

Via illoz.

For the last three Novembers, I’ve coordinated a project called DrawMo!, whereby persons around the world, both known and unknown to each other, draw every day for a month. Some people post their work to Flickr, some blog it either on their own sites or on the group blog, some work only offline; but everybody draws, separately, in his or her own special way.

So what I’d like to do for my final ICM project is add a more collaborative component to this than the group blog, which is, frankly, pretty dull lately. (The Flickr feed is where it’s at.) The idea is to create online Exquisite Corpse–type drawings, in which multiple people draw different parts of a single composition, without being able to see most of each other’s work, or the whole drawing, until it is done. It would have a Web front-end, using PHP to collect and organize the drawings and information about the participants, and there would be an optional Processing-based online drawing tool.

What Happens

• A person, let’s call her “Elisabeth,” visits the site and fills in her name and e-mail address.
• If Elisabeth is the first person to arrive, or if a new drawing is being started, she is asked to choose a square to work on and whether she wants to upload a drawing or use the online drawing interface.
• Elisabeth can’t see the the composite drawing-in-progress, but she can see a schematic with gray boxes for squares that are done, labeled with the artist’s name. If someone else already has a square that is adjacent to hers “checked out,” she will be told that she is on the waiting list and will receive an e-mail when the square is free. (She needs to be able to see the edges of any adjacent squares, so that her drawing can link to them visually.)
• Elisabeth has one hour to work on her square. After that, she will receive a nag message, which will ask if she wants to continue. If she doesn’t click “yes,” the drawing is posted and it’s the next person’s turn. She can only postpone three times, for a total of four hours.
• If Elisabeth chooses to use the drawing tool, she’s presented with a Processing window with a toolbar along the side—rather like Jonathan’s project from a few weeks back, but with more options. She can draw lines and simple shapes and can control the line width, color, and transparency. There is an eraser, an eyedropper for matching colors, and a “start over” button. Maybe a straight line tool. Elisabeth gets a fixed-size canvas, and if other people have already participated in the drawing, she will see the edges of the squares that are adjacent to hers, so that she can line things up
• The drawing consists of a 4 × 4–square grid, with each block being 600 pixels square. So the finished piece is 2,400 pixels square, or 8 inches, if printed out at 300 dpi—suitable for framing.
• If Elisabeth has chosen to upload an image, she can then draw on top of it.
• When Elisabeth is done, she saves her drawing and it is added to the composite drawing. Once she’s saved her drawing, she is allowed to rejoin the queue, if she wishes to draw another square.
• The next person on the waiting list gets an e-mail announcing that it is his or her turn to draw. Everyone except the last person can choose which square to draw on.
• Finished drawings are archived on the website and can be viewed at any time.
• When the drawing is complete, everybody who participated receives an e-mail with a link. The final piece is posted to Flickr and can be downloaded as a JPEG or PDF.

Questions

• How to let multiple people draw at one time?
• Should people be able to revise their squares after they’ve check them in?
• Should comments be allowed on the squares? On the whole drawing?

Some Other Collaborative Drawing Programs

Drawball
krazycanvas
NetSketch

Photo: butcher shop cow diagram in window in bernal heights, san francisco, california by veganstraightedge / shaners becker.

I completely spaced the ICM homework last week, which is sad, because it involved a language I actually have some experience with: PHP. I know just enough about it to fiddle with WordPress templates—and once, in 2002 or so, I spent a few days trying to rebuild the ColdFusion-backed poets.org in PHP, just for kicks.

Yeah, I didn’t get very far with that, but it’s the thought that counts.

Last week’s assignment was to

Using HTML and PHP, create a page which contains a form for some kind of (census, survey?) data collection and a second page which tallies up and displays the results (perhaps use Processing for visualizing the results

Easy peasy. I mean, not that this is stuff I can do off the top of my head—HTML forms are one of the many things I rarely have occasion to create from scratch, so I’ve never gotten enough practice at it to not have to look up the syntax for every single type of control—but it’s certainly stuff I’ve done dozens of times. So on Friday, while I was waiting for it to be time to go to a party, I started putting together a little cast-off calculator.

Casting off, for those who do not work in publishing, is the process of figuring out how long a typeset book will be, based on its typed or word-processed manuscript. It can be surprisingly accurate, when one has reliable character-per-pica (CPP) charts with which to estimate the volume of the typeset page. This problem is, of course, that there are a zillion factors that can affect the CPP. Which font are you using—that is, which typeface, and in which size? You have to be very specific about this. Just saying “Garamond 9″ won’t do; you need to know which Garamond—Adobe? Postscript or OpenType (or metal, or photoset)? The old Adobe Garamond, or the new Adobe Garamond Premier Pro? What typesetting program are you using—InDesign CS3, Quark XPress 4.11, PageMaker 6 Win, Pages? LaTeX? What H&Js are you using? Does the text use a lot of italics? Blah, blah, blah.

So, this calculator is actually pretty useless, because the CPP figures for my various font options are pulled from a couple of sources, none of them good. Somewhere I have a real list of CPPs from Westchester, a major U.S. typesetter, which I know are reliable . . . for the conditions under which Westchester was setting books for me at the time: Quark XPress 4 or 5, PostScript fonts, fixed H&Js, etc. Somewhere I also have a more detailed, and therefore accurate, cast-off formula that takes into account the number of chapters and parts a book has, and how much front or back matter there is. Maybe later I’ll update this code to reflect those real-life samples. For now, though, it gives you the basic gist: you plug in some numbers, you get some numbers back.

The input form—adapted from an example in the Chicago Manual of Style (Fig. A.4)—is okay, but the output page is quite nasty so far. Not sure what’s the best way to present all that information, so for now I’ve just left it where the PHP flang it.

Try it out: Cast-off Calculator

The PHP portion is as follows:

<?php
$chars_per_line = $_GET['chars_per_line'];
$lines_per_page = $_GET['lines_per_page'];
$ms_page_count = $_GET['ms_page_count'];
$total_ms_chars = $chars_per_line * $lines_per_page * $ms_page_count;

?>
Photo: Auto Setter by Marion Doss; some rights reserved.

It was a comfort to note, though, that I was not completely crazy for being under the impression that there was no PhysComp lab due last week. There’s not so much as a peep about it on the syllabus.

Update: Oh, that lab. The lab that we were supposedly supposed to do while we were killing ourselves over the midterm project. Right. How could I possibly have overlooked it.

Photo: Empty Can by spike55151 / Chris; some rights reserved.

Part 2 in the saga that began last week.

After spending about an hour playing with the Minim library in Processing, I went into the lab to see if I could get it to work with actual input from our IR sensors. This was basically a repeat of this week’s homework, which I’d done, for once, before the morning it was due, so the wiring part was uncharacteristically easy. I need to get some header pins, though; the stranded wire on the IR sensors is a pain to plug into a breadboard.

So our project—which I realize I didn’t explain last week—is going to be a cubeoid musical (or, at least, noisy) instrument with an infrared sensor set into each side, mounted corner-up (as demonstrated by Diego) on a camera tripod. One or more players can then use their hands or other body parts or utensils or pets to trigger different sounds from each side. We were thinking that for Phase One, i.e., this week, we’d have the sounds be synthesized tones, and that for Phase Two, the final version, we’d make it play various different loops.

It turned out, however, that it’s far easier—for me, at least—to get Minim to play loops than to synthesize sounds. And there are a lot of free sound clips out there in the world. I got mine from CanadianMusicArtists.com. This pre-prototype, therefore, has only two sensors, both of which trigger audio loops. It also has the beginnings of a lame-ass bouncing ball animation, but it doesn’t do what I want it to do, mostly because the signal’s changing too rapidly. Graphics were a tentative feature for Phase Two, so I’m not going to fuss with that part any more this week.

Here’s some crappy video of Filippo (left) and Diego (right) making the sensors generate noise. You can barely hear it, unfortunately—listen for the annoying rapid clicking sound, which I think is the hi-hat sound.

The beauty part? This doubles as my ICM homework.

Here’s the Arduino code:

/* Reads data from two analog sensors (IR sensors, in this specific example)
and outputs the values in a format that can be easily parsed in Processing.
*/

int ledPin = 7;
int irSensor0 = 0;
int irSensor1 = 1;
int sensorValue = 0;

void setup()
{
// Flash the LED three times to announce the start of program.
pinMode( 7, OUTPUT );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );

// Start serial port at 9600 bps:
Serial.begin( 9600 );
}

void loop()
{
if (Serial.available() > 0)
{
// Read the first (0) sensor:
sensorValue = analogRead( irSensor1 );

// print the results:
Serial.print( sensorValue, DEC );
Serial.print( "\t" );

// read the second (1) sensor:
sensorValue = analogRead( irSensor0 );
// print the results:
Serial.println( sensorValue, DEC );

// Follow the last sensor value with a println() so that
// each set of four readings prints on a line by itself:
Serial.println( sensorValue, DEC );
// delay ( 100 );
}
}

And here’s the Processing code, where most of the excitement takes place.