For this I have combined both Pure Data and Processing to respond to audio intake. This post is extremely late because I had to restart this project due to the fact that it was erased from all documents everywhere. Well it still works about the same as I had presented it in class. I have a attached a link for a zip file that contains its necessary parts.

http://users.wpi.edu/~ahclemens/TooDamnHigh.zip

What the program does is read audio input from a microphone. Then translates the volume into a readable number. That number determines which image of a meme will be shown. The Pure Data meme is the Too Damn High image. The Processing meme uses Dwight from the office. Each program uses a slightly different image change function. For example, Pure Data meshes the images as the volume is in between picture stages. But Processing switches clean and quickly between its choices.

If you want to run the program then you need to have Processing and Pure Data installed along with the OSC in the Processing library. Then its a pretty simple open and run if Pure Data has audio allowed.

Final Project

Hectic life is pretty well devised in my final project. I have recorded a sample of the configuration and setup of my work in the link below.

The outcomes were very successful in its initial runs. Unfortunately, certain bugs and wire configuration have caused some of the file to stop working correctly. But the main cycling of activities and the response in the situations work relatively well for tape and wire hook ups.

I found the large circuit board I made as a great organizer that has allowed the limit of wire issues and kept the area flat. The Makey Makey made the hookup to the computer simple input for the rest of the program. Therefore, more time could be spent on coding design and configuration in Pure Data.

The overall assignment was enjoyable to make and play while also visual interesting. The simple images used and the central coding design makes both parts enjoyable to see. Although the program only has a six activities, the program is easy to expand for later possibilities. I only wish the composition of the project was more suitable for travel and storage so that its life span wouldn’t be so short.

I got everything I originally planned on making into my game, and made a bunch of audio, but could not get the into my program. The makey makey worked relatively well and I am still happy with the finished project. I tried several ways to put audio into my videos but ProTools stopped working in the lab. I checked on three different computers. I then borrowed somone’s window machine and attempted to use Window’s Movie Maker. It could not read my .wav files. I have a video of the gameplay and the physical input and another of just the gameplay. Even without sound the project was a lot of work, and took about 1000 lines of code, and a lot of tweaking.

Here is the finished game, though it will be less intuitive without the makeymakey. The dice and wires on the makeymakey were color coated to match the stats they increase. as of now arms/attack = left arrow, tails/defense = right arrow, head/magic resistance = down arrow, eyes (makes the enimy more likely to be something you are good againsts) = up, wings/evade = w, legs/speed = space bar. These were chosen to go along with what is accessible on the makey makey. If I used WASDF the wires would be too close and would press each other.

Here is some audio I made that I intended to use

The final version of the Synthesizer Glove, though now I am probably more correct to call it the Effect Glove, has five sensors: a simple button, a light sensor, a temperature sensor, a rotation sensor, and a makeshift toggle.
The synthesizer is controlled by the light, rotation and temperature sensors, and plays when the button is pressed.
The synthesizer itself is a simple sinewave with frequency and amplitude modulation.
When the toggle is off, the rotation and light sensor select a sound effect to be played on a button press.

The sound effects were originally random effects from video games, but for the metaphor, I chose several sword sounds and two dragon sounds, to represent the project helping me vanquish finals week.

Documentation video

So it’s finally done. My project is a little whimsical, I will admit, but it was fun and it turned out great. I came up with my project because of the discussions that we had in class last Thursday and the fact that my friend uses many tokens in his Magic the Gathering deck. His tokens are goblins, so I wanted to make something that could keep track of the goblins, since we lose track a lot, and could make the goblins seem funnier. In all honestly, this project is kind of a jab at his play style since it annoys me and I just generally don’t like it. Still, this project has been very very fun and worked out great.

My program is a random generation program that makes randomly positioned goblins depending on the count of goblins. You would use the left and right keys to subtract and add goblins, while the up key would make them run across the screen and attack. Each time you click one of the keys the goblins are all repositioned allowing for the creation of some very random and interesting configurations that can be some really cool images. There was even one time where I could have sworn that the string of variations spelled out goblin.

The code wasn’t too complex, but there were a few problems in getting things to work. The first problem was getting the string at the top to display a number since all references online where just consistent and never changing. This was solved by making the string a variable so that it would change with the value. The second, and by far the most annoying problem that I ran into was getting the run function to activate on a key press. This problem was solved thanks to Dennis by changing the key press functions to run and change a button value instead of actually pressing the key to run the function. This way the running function could be in the draw section allowing it to actually work and run multiple times instead of just once like it was in the key pressed section. So thank you Dennis.

The video of it being used is at http://www.youtube.com/watch?v=8mjAWM6mmAE&feature=youtu.be

Thanks. It was a great class and term.

So for my final project I made a Guitar Hero-esque controller. The Pure Data patch is relatively simple and doesn’t look terribly exciting so its not shown in the below video. The basic idea behind this project is that you can plug in a basic chord progression from a folder full of audio clips of chords, with one chord set to every one of the five “buttons” on the neck of the guitar. With the ground being placed where you would strum a normal guitar you can easily play along with a song that has a relatively simple chord progression for the rhythm. All in all the controller works well and is quite fun to play with, the only real “problem” being the lack of very high quality audio files for the chords.

This will show the progress of our project, from start to finish. See my previous entry for the original concept of our project.

Here are the materials we began building our project with.

You can see we have our Arduino Uno, a motor, resistors, batteries and a battery pack, wires, a USB cable to connect the Arduino to a laptop, and of course, a laptop.

Once we gathered all our materials, we set out to begin coding in Processing and Pure Data to get the motor to respond correctly to sound input from a song.

More coding and testing.

The motor finally works! Below is the motor seated inside the drawing attachment built from Bionicle pieces.

Then we have to glue the motor to the apparatus that moves the drawing utensil.

The project is all set up!

Below is a video of the project in action when we shared it in class. It doesn’t quite perform as strongly as intended, but it would do much better if some parts were tweaked and strengthened.

Drawing Robot

This is the final demo of my digital Etch-a-Sketch. The screen recording was at a lower frame rate than the actual processing script making the drawing look choppy.

Overall I am pretty happy with the results. I think there could be some work done on the velocity portion of the demo, either by applying a filter to the velocity to smooth it out or by using a timer to regularly sample the difference in distance.

Enjoy!

My final project started out with a brainstorming session. I wanted to integrate sound and visuals and looked though the list of arduino addons. My original idea was to have a virtual keyboard in PureData and integrate it with spraypaint, so that as the user was playing music, each note would cause paint to spray onto a spinning sheet creating a visual counterpart to the piece. The plan was to have servos attached to arms that would trigger cans of spraypaint. However the Achilles heel of the project was that I underestimated the force that would be required to spray the can. More Tommorow.

Here is the finished product:

I had to scrap the spray can idea because the servos couldnt handle it, however I did adapt the project slightly to include qtips that were dabbed in paint in place of the spray. The pure data portion worked out pretty well because I found some nice keyboard samples online to use.  One thing I was especially pleased with was how the arduino was able to provide both input and output.  Overall despite a few bumps the final project turned out better than I expected.

-Isaac

The concept for my project was to make a pond full of Lily Pads that drifted about in the water, and would be affected by wind generated by the person interacting with the product. I worked on this using Processing, and referenced past programs such as the animated rabbits and the noise based gnats to help me write the code as I produced it. The program itself runs smoothly with no existing errors.

The program generates 20 lily pads at random coordinates on random angles using one of three lily pad graphics I have designed at random. The lily pads move around with noise based movement patterns to give it a natural feel of lily pads in a pond, which works well with the pond background that I painted for the program. The program can be interacted with by using either the four directional keys to generate “Wind” that causes the lily pads to spin at variable speeds (Each input increases/decreases the total force by a set amount to input). The wind effects can reach a point where the speeds are nonsensical, so the program isn’t totally realistic, but it makes for fun and humorous effects.

The project itself was not overly challenging to create, though there was one technical issue that popped up during the creation process that drove me to a halt for a while. This problem came from the fact that lily pads won’t just slid on top of each other in a pond. I needed collision detection in programming terms. Processing, did not agree with my desires, especially thanks to transparent space in the image files which made it even harder for me to make this work. The program works, but I wish I could really get collision detection to work for it.

Enjoy the presentation!