Category Archives: Processing

PhysComp, week 6: Bride of Serial Out

This week’s lab was mostly uneventful, although it took me something like six hours to do—I started after our CommLab make-up class ended, around 4 pm, and stayed until nine or ten.

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

PComp lab, week 5: Serial Out

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.

Helping hands

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:

1 digital + 2 analog

And then, there was serial output:

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:

PhysComp homework, week 6: serial out 2: 15 PhysComp homework, week 6: serial out 2: 16

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.

PhysComp midterm project, week 2: Rough prototype

A semi-working prototype!

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.

PhysComp, week 5: Serial Out

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:
P1000190.JPG

Pot hooked up:
P1000199.JPG

Blinking LED:
P1000204.JPG

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

Oh, the Rapture!

For week 5’s ICM homework, I was so excited to be able to scrape data off Web pages that the page I chose to work with was the Rapture Index.

It’s always bugged me that the Rapture Index doesn’t have an RSS feed—it’s like the weather; we need to know it every day. Now, however, I can finally just roll my own feed.

The problem is that I can’t get my Rapture Scraper to show the correct description of the prophetic activity level (see under “why is this null?!?”). Just because the index has been stuck at “fasten your seatbelts” for as long as I’ve been watching it doesn’t mean that I don’t want to know for sure. Like, what if the index suddenly climbs above the record high of 182? They’d have to make a new prophetic activity category, don’t you think?

So anyway, that’s the main thing I’d like to fix. I’m also unclear on why the text is so jagged. Smoothing is turned on in two places, and I’m using the font (Lucida Sans 20) only at the size at which it was bitmapped.

Another modification I’d like to make, oh, I dunno, when I have some of that “free time” I’m always hearing about, would be to maybe have the rapture balls bounce around at a speed that’s proportional to the index. The colors should probably also heat up. So when the world goes crazy, so will the application.

Drawing program

a doodle made by our Processing app

Part two of this week’s ICM homework: “Make a painting program or a kaleidoscope that uses mouse interaction.”

Neither Ruthie nor I could envision out how even an analog kaleidoscope might work, so we took the drawing program option. Again, we relied heavily on examples from the book (Drawing a Continuous Line and mousePressed and keyPressed), but instead of making a program that just draws a single, continuous black line, we added a mousePressed thing so that it draws a black box and changes the line color every time you click.

Bouncing Ball

bouncing ball, rainbowified

Ruthie and I worked together on two assignments. The first was “Make a ball bounce around the screen.”

I thought I knew how to do this, but after beating my head against it for maybe forty-five minutes, I finally looked at the example online: Example 5-6: Bouncing Ball.

Ohhhhhhh. I would never have thought of that speed = speed * -1; in a million years.

So then we ended up copying the example, which is not much fun. To make it more interesting, we made the ball move diagonally. But with both speedY and speedY incrementing at a steady rate, the ball just does a box step. Still not very interesting. I wanted to introduce a little rotation, but using speed = speed * -1.1;, though interesting at first, eventually speedY goes too far from +/- 1, which causes the ball to go crazy and disappear.

So I added an if statement to reset the variable to 1 if it got outside the range -/+ 5, but that, too, caused the ball to start behaving weirdly after a couple of turns. I figured out that it had to do with not keeping the ball going in the right—-making the reset value always +1, never -1—but I didn’t know how to preserve a negative value. Jeremy came over and talked me through making it work. Yay, Jeremy!