Category Archives: ICM

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.

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!