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.

I had wanted to make an AfterEffects animation for my CommLab final project, but then I didn’t get around to playing with the program until the eleventh hour. The result is definitely not what I had in mind. (What I wanted to do was more like de Vicq de Cumptich’s Bembo’s Zoo animations.)

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.

Get it now! Detailed, full-color documentation of the famed MC Squared midterm project!

MC_Squared(fin).pdf (14.68 MB; sorry, it contains a couple of embedded videos)

We gave our presentation today, the thing mostly worked, and it wasn’t too embarrassing. And, unlike some people in the class, my group actually got two or three hours of precious, golden sleep the night—well, morning—before. (We closed down the floor at about 3:30 a.m., but a few of our classmates relocated to the library or some such place to keep working. Everybody seemed pretty crispy by 9:30 this morning.)

First I thought I’d use one of these nifty sensors I got from SparkFun,

but then I realized I have no idea how you’re supposed to hook them up. Stick the pins straight into the breadboard? Solder wires on? How long should the wires be? So instead I used the stupid knob again, plus one of the IRs I bought for our midterm project.

The thrill of the knob has totally worn off. Then I saw Jorge soldering wires to an ultrasonic range finder just like the one I have, and I thought maybe it was a good time to try out my own. Ha! Thus began one of my more frustrating soldering bouts so far.

It must have taken me forty-five minutes to solder three freaking wires onto this cookie . . . and then it took me another hour to realize that the reason it wasn’t working was that I’d soldered the yellow wire to the wrong hole. And then I couldn’t get it unsoldered to save my life, so I just attached a fourth wire.

Finally I got them all hooked up:

And then, there was serial output:

• “Now you get a range of garbage characters.”
• “List all the available serial ports.”
• // print out the values you got:
for (int sensorNum = 0; sensorNum < sensors.length; sensorNum++) {
print("Sensor " + sensorNum + ": " + sensors[sensorNum] + "\t");
}
// add a linefeed after all the sensor values are printed:
println();

Et cetera.

After all that hair-pulling, the ultrasonic sensor was giving me really erratic readings (then again, so was the push-button switch: its value didn't change when I pushed the button, but it did when I touched the button). So I switched to two IR sensors, since I had so many lying around.

Then I got to the part about the handshake. Handshaking? Was not happening for me. I think it may have had something to do with this:

The Processing application was looking for the word "hello," but the Arduino didn't seem to be able to say the word without stuttering horribly. I tried for more than an hour, I think, to get them to talk to each other, but finally I had to just give up.

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.

I was trying to figure out the math to make part of the graph show up as brown—i.e., earth—and then scatter flowers on top, but something wasn’t working out and I was running late, so I gave up.

Anyway, here are the progress shots:

Setup:

Pot hooked up:

Blinking LED:

I also shot a fascinating movie of the program loading on the Arduino and starting up—you know, flickering yellow light, then blinking LED; hot stuff:

Final code on Arduino:

int potPin = 0;
int potValue = 0;
int ledPin = 2;

void setup()
{
// flash LED three times to announce start of program
pinMode( 2, OUTPUT );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );

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

void loop()
{
// read analog input, divide by 4 to fit it in the range 0-255:
potValue = analogRead( potPin );
potValue = potValue / 4;
Serial.print( potValue, BYTE );
// pause for 10 milliseconds:
delay( 10 );
}


Final Processing applet