This week in Little Computers, I was asked to put together a presentation on some "interesting flags" to gcc. You can check out the pdf of the presentation below!
pdf: "Some Interesting Flags For gcc"
Saturday, January 30, 2010
Thursday, January 28, 2010
Sound And The City: Deep Listening
This week for Sound And The City we were asked to do a bit of "deep listening". This essentially consists of spending twenty minutes in a given environment, focusing entirely on the environmental sound in that area. This includes having your eyes closed, doing nothing else, and generally paying as much attention as possible. After the twenty minutes are up, one takes notes (of any kind they desire) on the experience, and the result is a "deep listening" log.
Daniel (course instructor) asked us in class to name a place we loved in New York - I chose the west side highway park, where I run daily. The trick here was that this then became the site of our deep listening experience. My log from the experience is pictured above, while an mp3 of the same time period is below. Enjoy!
mp3: Deep Listening, West Side Highway, New York
Daniel (course instructor) asked us in class to name a place we loved in New York - I chose the west side highway park, where I run daily. The trick here was that this then became the site of our deep listening experience. My log from the experience is pictured above, while an mp3 of the same time period is below. Enjoy!
mp3: Deep Listening, West Side Highway, New York
Wednesday, January 27, 2010
Pixel By Pixel: Analog Animation
For Pixel By Pixel we were asked to "make pixels" using an analog source for our pixel generation. I decided to use my shower tiles and dry erase markers to create a big-pixel scene. The scene (above) depicts a short span in the geological evolution of a land mass, including rain, erosion, volcanic activity, and growth.
In hindsight, I would have zoomed out more in order to have a higher resolution grid. I also discovered that while dry erase markers come right off of tile, the same is not true of grout. You live, you learn.
Tuesday, January 26, 2010
Nature Of Code: Flowers and Wind
For our first week in Nature Of Code, we were asked to do the following:
Find an example of real-world "natural" motion and develop a set of rules for moving the Walker. Can you do it without using any random whatsoever? Without changing how the square looks at all (changing size or rotation is ok), can you give it a personality or make it appear to have an emotional quality? Create a second version with the same behavior, but with your own non-square design. Feel free to design an environment for the Walker to live in as well. We'll compare the versions in class next week. Can we create something natural through algorithmic behaviors alone? How much does visual design play a part?
Inspiration.
I took my inspiration from the PlayStation 3 game Flower (see video above), and attempted to model flowers (namely, dandelions) being detached and floating in the wind. As per the request, I created two versions, one that used pure geometrics, and one with more visualization.
Implementation.
The first visualization uses squares and lines (along with modeled wind) to gradually harvest the dandelion buds from their stems. While the representation is geometric, I actually think the visualization has enough clarity, or familiar layout, that it's pretty clear what's happening.
The second animation uses the same code, but with color and small dandelion gifs to create a better sense of what's going on. While the original visualization creates a semi-clear representation, the second implementation unquestionably does a slightly better job. The colors and gifs create and animated, cartoony feel that successfully portrays the objects in question.
Challenges.
Both implementations use the same modeling for the wind, which uses vectors and random numbers to specify when buds disconnect, and how they move once disconnected. Coding the disconnect was simply a matter of randomly disconnecting at a pace that was seldom enough to feel natural.
The wind was far more of a challenge, and required figuring a pace of wind change that didn't seem too fast, or too slow. I eventually managed to stumble upon a combination of changing acceleration, changing direction, and avoidance of downward wind, that seemed to grasp the idea well.
My main challenge (which I still have yet to solve) is that the iteration over the flower array to update each vector results in an occasional pause in the motion which is highly unnatural, and definitely not desirable. I need to investigate this further, and determine if there's a more efficient way to update the objects, or if I need to reduce something algorithmically within the update.
Takeaway.
Short version: making things move naturally is hard.
Long version: I had difficulty implementing any kind of movement that felt natural without using randoms. Even once I started using randoms, the implementation was largely one of trial and error, seeing what looked and "felt" natural, and elaborating on that.
Source Code: Zip File with Source Code and gif (Please note that the sketch is done in eclipse, and will not work in a regular Processing environment.)
I took my inspiration from the PlayStation 3 game Flower (see video above), and attempted to model flowers (namely, dandelions) being detached and floating in the wind. As per the request, I created two versions, one that used pure geometrics, and one with more visualization.
Implementation.
The first visualization uses squares and lines (along with modeled wind) to gradually harvest the dandelion buds from their stems. While the representation is geometric, I actually think the visualization has enough clarity, or familiar layout, that it's pretty clear what's happening.
The second animation uses the same code, but with color and small dandelion gifs to create a better sense of what's going on. While the original visualization creates a semi-clear representation, the second implementation unquestionably does a slightly better job. The colors and gifs create and animated, cartoony feel that successfully portrays the objects in question.
Challenges.
Both implementations use the same modeling for the wind, which uses vectors and random numbers to specify when buds disconnect, and how they move once disconnected. Coding the disconnect was simply a matter of randomly disconnecting at a pace that was seldom enough to feel natural.
The wind was far more of a challenge, and required figuring a pace of wind change that didn't seem too fast, or too slow. I eventually managed to stumble upon a combination of changing acceleration, changing direction, and avoidance of downward wind, that seemed to grasp the idea well.
My main challenge (which I still have yet to solve) is that the iteration over the flower array to update each vector results in an occasional pause in the motion which is highly unnatural, and definitely not desirable. I need to investigate this further, and determine if there's a more efficient way to update the objects, or if I need to reduce something algorithmically within the update.
Takeaway.
Short version: making things move naturally is hard.
Long version: I had difficulty implementing any kind of movement that felt natural without using randoms. Even once I started using randoms, the implementation was largely one of trial and error, seeing what looked and "felt" natural, and elaborating on that.
Source Code: Zip File with Source Code and gif (Please note that the sketch is done in eclipse, and will not work in a regular Processing environment.)
Thursday, December 10, 2009
Visualizing Data: On Paul Graham
Being that I've seen Paul Graham speak, have read his book, and am partial to his essays, the talks delivered for Visualizing Data (see below) didn't present a ton of new information. That being said, it's worth taking a moment to discuss why it is that I enjoy Graham so much, and his most famous analogy between "hackers" and "painters".
Graham's style of speaking and writing is unquestionably authoritarian, and that's the beginning of what I like about him: he's not afraid to have strong opinions, and to put them out there. So many commentators today waste their time either pandering to the masses, or being incredibly extreme. With Graham, you get the feeling that not only does he believe in what he's saying, but that he's given it some real thought. Even his most caustic opinions (for example, his constant mocking of the Java programming language) are rooted in well thought out and valid positions.
Most of those positions end up being about one of three things: smart people, hackers, or programming. Which brings me to the second thing I like about Graham: he's not afraid to admit that there are smart people out there in the world, and that they behave differently than others. He's willing to cite the good (high productivity, more inspiration) and the bad (stubbornness, near autistic behavior), but most importantly he's willing to admit that they're smart. These days we're far too bogged down in a culture where everyone's getting a pat on the head, and Graham is far more inclined to give the truth than to put a rosy tint on everything.
When discussing these super-intelligent "hackers", Graham then takes a stance that (as least when he originally took it) is unique: he treats them as people and creators. Computer programming has long been the subject of being compared to engineering and math, as a sort of technical discipline. Graham takes his unique role as both an artist and a programmer and proposes the opposite: that programmers (or "hackers") are actually creative people who simply use an engineering device and medium as their means of expression.
This treatment culminates in Graham's famous analogy between hackers and painters. The two groups are unique to each other, Graham supposes, in that they both have two roles: they have to decide what to do, and how to do it. While many other creative/engineering jobs have two roles for this action (he cites architects and engineers as the "what" and "how", respectively), Graham points out that both painters and hackers are responsible for creating their idea, and then engineering it as well.
Paul Graham: Great Hackers
Paul Graham: Hackers And Painters
Graham's style of speaking and writing is unquestionably authoritarian, and that's the beginning of what I like about him: he's not afraid to have strong opinions, and to put them out there. So many commentators today waste their time either pandering to the masses, or being incredibly extreme. With Graham, you get the feeling that not only does he believe in what he's saying, but that he's given it some real thought. Even his most caustic opinions (for example, his constant mocking of the Java programming language) are rooted in well thought out and valid positions.
Most of those positions end up being about one of three things: smart people, hackers, or programming. Which brings me to the second thing I like about Graham: he's not afraid to admit that there are smart people out there in the world, and that they behave differently than others. He's willing to cite the good (high productivity, more inspiration) and the bad (stubbornness, near autistic behavior), but most importantly he's willing to admit that they're smart. These days we're far too bogged down in a culture where everyone's getting a pat on the head, and Graham is far more inclined to give the truth than to put a rosy tint on everything.
When discussing these super-intelligent "hackers", Graham then takes a stance that (as least when he originally took it) is unique: he treats them as people and creators. Computer programming has long been the subject of being compared to engineering and math, as a sort of technical discipline. Graham takes his unique role as both an artist and a programmer and proposes the opposite: that programmers (or "hackers") are actually creative people who simply use an engineering device and medium as their means of expression.
This treatment culminates in Graham's famous analogy between hackers and painters. The two groups are unique to each other, Graham supposes, in that they both have two roles: they have to decide what to do, and how to do it. While many other creative/engineering jobs have two roles for this action (he cites architects and engineers as the "what" and "how", respectively), Graham points out that both painters and hackers are responsible for creating their idea, and then engineering it as well.
Paul Graham: Great Hackers
Paul Graham: Hackers And Painters
Wednesday, December 9, 2009
Awesomeness From Applications Class
A while back in applications class, a group had us do this awesome stop motion pong game. Truly killer - just found the vid. Enjoy!
Tuesday, December 1, 2009
Physical Computing Midterm: Media Controller; "Pancake"
The "Pancake"
For our Physical Computing midterm, we were split into groups and asked to create a media controller of our own devising. No limits or requirements were put in place, except that the controller would be a physical interface to the arduino, and would controller some external media device. I was teamed with the wonderful Amy Chien and Chris Alden, and the three of us came to the conclusion that we'd like to build something of an electronic musical instrument.
To start things off, we brainstormed about possible ideas for the media controller's interface. However, we came up with so many cool ideas that we almost immediately decided that we'd like to do multiple interfaces. This worked its way into a concept for a modular music table, that would be split into various pieces, and allow three individuals to collaborate using three different interfaces.
Hauling wood.
All three interfaces.
Once we had completed and tested the three interfaces, we brought them together to the table, and unified them into a single instrument. Each interface had its own arduino, which were then collectively wired into a labtop via a USB hub. Once all three arduinos were recognized on the computer, we then hooked them up to Max/MSP and created a patch that would listen for the serial values from each interface, and use them to control tonal output.
The pressure pad controlled pitch bending, the wind interfaces controlled the speed of the tone playback, and the sequencer controlled the notes being played over the loop. Once the patch was loaded, all three interfaces could be used simultaneously to control the computer's sonic output. You can see a demo of one of our classmates joining us in trying out the interface above.
Finally, we presented our project in class. Here you can see a brief clip of our presentation, which managed to go off without a hitch. Midterm, complete. Go Pancake!
Subscribe to:
Posts (Atom)







