I Am Jack's Graduate Education

Spatial Media: draw/erase/space

2011-03-29T13:19:00.000-07:00

draw/erase/space is a site-specific art piece designed to increase public interaction, while at the same time questioning how art is created and destroyed, and how individuals regard others' creations. Designed to be installed in a public subway, the installation gives multiple users the option to "draw" or erase" within a given space on the subway platform. Their creation or destruction of art is then displayed on the opposite platform on a projected screen.

The project draws much of its artistic interpretation from two pieces: Robert Rauschenberg's "Erased deKooning", and Brian Eno & Robert Fripp's "No Pussyfooting". Both of these pieces wrestle with the complexities of creation and collaboration, and whether destruction is actually a form of creation as well. draw/erase/space attempts to embrace this spirit by providing individuals with an environment where they can confront these issues head on, simultaneously other hopeful "artists".

Using a ceiling mounted kinect and projector, the piece projects an guideline for where the users are able to stand in order either "erase" or "draw". The floor projection provides boundaries for where users can stand to interact with the piece itself.

The interaction occurs via the overhead mounted Kinect, in combination with a front facing projector. The user raises their hand above their head, and the hand is detected via blob tracking. The front facing projection then takes these blobs as input to either erase or draw with a texture on a permanent background.

The interaction succeeds by using the Kinect's depth map and feeding it to OpenCV. By setting a height threshold, it doesn't detect movement below a certain height. As the user raises their hand, it detects which side they are on (draw/erase) and draws a cursor (green/red) to indicate where their "brush" is located. These cursors are mapped to a larger space, as they only take up half of the kinect window, but need to be able to traverse the whole of the projected image.

As users interact in the space, the image becomes a combination of their drawing and erasing "work", and reflects their behavior over time. The space supports multiple users in each area, and can also support a variety of backgrounds and brushes.

code: Drawerasespace.java

Nature Of Code Final: Game Of Lifetris

2010-04-26T16:52:00.000-07:00

As I originally outlined in my proposal, for my Nature Of Code final I decided to create an implementation of Conway's game of life, and combine it with the classic computer game Tetris. The result was one that, while not terribly fun to play, actually does go a long way in demonstrating that the game of life is more complex than it appears, and despite its simple rules, offers of a large degree of randomness.

I started by trying to discern the basics of the game, and came to the conclusion that I would need to start with some pieces/organisms already on the board. The game of life tends towards decimating populations, so having no starting population lends itself to a quickly emptied (and boring) board. Moreover, given the game's natural tendencies, I decided that I would make the aim of the game to allow pieces to live, rather than to destroy them (as was true in the original tetris).

I took this implementation and coded a simple version that was in black and white and played out a generation of the game of life after each tetris piece was dropped. Once this was complete, I noticed a major problem: Despite my hopes for the contrary, there's little way to discern what will happen in the next round of the game.

To work my way around this, I next tried implementing a "future" system, where the game would calculate the results of your current piece placement ahead of time, and attempt to show them to you in a translucent clear projection on top of the current board. The problem with this is that, while interesting, it's still extremely difficult to tell whether you're creating or destroying pieces.

Continuing on my quest for at least some level of usability, I reached for one final implementation. This time I maintained the "future" board concept, but also colored the tiles more strategically. This time I made tiles that stayed alive black, tiles that died red, and tiles that were born green. In this way, it's easy to try and maximize green and minimize red as you place your piece.

Once the interface was intuitive, I added a scoring system based on how many organisms were alive after each turn, and played the game a bit. The unfortunate result is that it's not very fun. While tetris allows you to create strategies and begin to intuit moves, the game of life is simply too random to be able to do anything but try and pick correct placement on a turn by turn basis.

Despite this fact, I think there could still be room for using the game of life mechanism to make for a fun game implementation. Some cases that still seem to hold water did come to mind: a game where there was a desire to finish with a very specific number of organisms, a game where all the organisms needed to be eliminated in a certain number of turns, or basically any game where the strategy was less about time and movement, and more about specific placement.

In short, the game of life is too random of an algorithm to function desirably in a time and movement based game. I believe it would hold up far better under slower, ore strategic circumstances, and that tetris is certainly not.

Sound And The City: Grid Music And Notation

2010-04-01T07:45:00.000-07:00

Over the past few weeks, I've taken the idea put forth with orchestraSeating, and modified it significantly. The modifications have been an effort to reduce the deployment overhead, increase the quality of musical delivery, and make for a musical system that was less spatially specific. The result is a new version of the installation that I call, for reasons that will become obvious, Grid Music.

orchestraSeating was built around the premise of physical sensors, in a specific site, playing back multi-tracked versions of classical orchestra music. While this premise is interesting, it is lacking on a number of fronts. For one, it begs for a site-specific, resource-heavy installation (for example, the cafe at Alice Tully hall, above). For another, it constrains the piece to the domain of classical music, and therefore requires that the installation and the piece has some level of synchronicity.

A grid overlaid on the Alice Tully seating plan

By contrast, gridMusic uses a grid overlaid on a public space to fuel a generative music engine. The engine uses an overhead camera in concert with the grid to monitor activity, and then follow a set of rules related to that activity. The rules are "activated" by movement within the space, and once activated, they cause playback of recorded clips, which yields the generative composition.

Much like Terry Riley's "In C", there are a set of clips (in this case, 20) that the algorithm has to choose from. Also similar to Riley, the parts must be played in order. However, the manner in which they are selected is based not on the personal preferences of the players, but by movement within the grid. When movement is detected in a square of the grid, that square begins playback of Part 1 will continue looping until movement ceases in that square of the grid, and then begins again. When movement restarts in a given square of the grid, that square is advanced to the next part.

This set of rules allows for easy visualization and state of the piece. In other words: notation. The squares that are active are colored, and indicate which clips are currently playing. Every time any square on the grid changes, a new file representing the grid is saved, complete with a timestamp. With the traversal of the various grids and their associated time stamps, one can easily discern the composition that was played back at the site for a given performance.

Because of the visually pleasing nature of the grid, it would not be unheard of to involve the grid in some way at the site. This could be done as a projection or display on a monitor, and would perhaps help to invite the participation of individuals as they acted in the space.

As activity increased, the grid would become progressively more active, with colors varying and changing as per the algorithm's specification. This would create a lively, interactive visual that would compliment the audio portion of the installation. Moreover, if the composition were broadcast live to the web, it could be similarly accompanied by the progression of the grids.

As each square reached it's final "switch" from the black "part", it would return to it's original white, inactive state. It would remain this way until all the squares came to rest, at which point after a duration of 5 minutes down time, the piece would begin again.

Pixel By Pixel: Multiple Perspectives In 2D

2010-03-30T22:41:00.000-07:00

This week in Pixel By Pixel, we were asked to take various painting styles discussed in class to inspire an interactive piece. As such, I decided to leverage last week's work in image banding, and attempt to emulate Picasso's attempts at forcing multiple perspectives into a single 2D plane.

Picasso's "Portrait Of Dora Maar"

In order to accomplish this, I modified my program to accept two camera inputs, one for each perspective. I then added a keyboard interaction to allow the user to modify the banding resolution. The result is a program that can look at two perspectives, and divide them amongst image bands accordingly.

In order to achieve an effect similar to Picasso's, it's necessary that the user carefully align their camera angles so that the perspective in question is mutually centered in each camera. This will ensure the unity necessary in the merging of the 2D planes into one. In the image above, I've centered myself in the frame of both camera perspectives.

As the user interacts with the banding resolution, a variety of effects occur. Here, we can see that at low banding resolutions, there are very obvious differentiations between the two images, resulting in recognizable pieces of each image, and a feeling of displacement for those pieces.

As the banding resolution is increased, the feeling of displacement is reduced. Instead the image yields more of a feeling of simultaneous existence, with both images occupying the same space. This is due to the increased resolution revealing a more evenly distributed rendering of each perspective, despite using exactly the same number of pixels. At these higher resolutions, there is less necessity for the object or scene to be centered, as the increased clarity allows for both perspectives to be seen regardless of positioning. (This effect can be seen at the top of this entry)

Because the image banding controls are distinct, they can also be used to combine the two effects. This can result in a striped pattern that allows for some of the best of both worlds. The increased resolution in one dimension increases clarity, while the lower resolution in the other dimension allows for the feeling of displacement, and the clear existence of two perspectives.

This two camera application of image banding and perspective is clearly in the early stages. Most notably, a fixed and aligned camera configuration might yield more consistent images and interaction. Additionally, a much larger number of cameras could be used, resulting in further displacement and perspective collisions. For example, four cameras aligned on an x-y axis could result in a 2D image that showed perspective on an object or scene from all sides. Alternatively, motorized camera mounts could allow the user to control perspective, and thus control the displacement in the 2D image they were creating.

Nature Of Code: Final Project Proposal, Tetris and Conway's Game Of Life

2010-03-30T07:49:00.000-07:00

Our Nature of Code final project is about as abstract as you can get, with the option to leverage just about any and all sides of the various phenomena. What's more, the visualization (or lack thereof) is also completely open ended. In short, we were asked to look at the huge amount of material covered this semester, and get inspired.

For me, that meant childhood video games - Specifically, Tetris. While reading this article on Conway's Game Of Life, I was struck by how similar the cellular shapes were to Tetris pieces. This got me thinking as to whether there might be a way to combine the two into a video game that yielded novel game play, driven by cellular automata.

While I'm still fleshing out the idea, you can check out my thoughts so far in the proposal below.

ppt: Nature of Code Final Project Proposal - Tetris and Conway's Game Of Life

Pixel By Pixel: Pixel Transformation

2010-03-23T21:52:00.000-07:00

This week in Pixel By Pixel, we were asked to delve into the world of pixel transformation. Put simply, taking the individual pixels in an image, and processing them to change location in the grid. The goal was a result that was "dynamic and interactive".

Part 1: Reflected Pixels
I began the exercise by subdividing both horizontal and vertical pixels by two, and reflecting the pixels to the remaining three quadrants. The result was a program that is both entertaining and visually dynamic. As can be seen from the images below, it allows for (particularly with facial anatomy) imagery that instinctually feels deformed or distorted. However, it can feel pretty simplistic, along the lines of a house of mirrors.

Part 2: Banding
While experimenting with modifying the reflection algorithm, I modified the factor by which the horizontal reflector was divided. This resulted in the banding pattern seen above. Observing the pattern caused me think that intentional banding could create compelling imagery, based around the concepts of repetition, patterns, and blending.

Part 3: Banding Grids
I decided to pursue the banding algorithm, and to do so in both the vertical and horizontal dimensions. I achieved the desired result by grabbing a section of pixels, and then reapplying it using modulo math. Since the modulo resets every time its argument is reached, the algorithm would then start anew and redraw the desired band. The result is a "banding" grid of the desired area, as can be seen above.

Part 4: Abstract Banding Grids And Resolution
While a low resolution banding grid can be more compelling in terms of subject recognition, a higher resolution grid can actually yield more unusual and abstract patterns, particularly when it comes to subject blending, and perceived appearance of the subject.

Part 5: Subject Recognition In High Resolution Banding Grids
Perhaps the most counter intuitive part about the high resolution grids is that despite their complexity and abstraction (see above), they are actually simply a grid of a repeated image. What this means is that if great care is taken, the subject can actually still be recognized, as can be seen from the recognizable lettering in the image below.

The idea of banding grids manages to take a variable chunk of an existing screen, and repurpose it as a tool to build patterns that can be simultaneously abstracted and recognizable. What's more, it takes a group of pixels and repurposes them on a macro level such that the group itself becomes the implementation of the pixel. Further developments in this area might include using the mouse to move the selected band, implementing a constant-movement band that iterated across the image, or intelligently selecting bands of the implemented resolution to recreate the image itself, but in recursive bands that had in fact been sourced by the image.

Sound And The City: Orchestra Seating Mk. 2

2010-03-04T09:06:00.000-08:00

This week in Sound And The City finds us re-presenting our final project proposals, this time with the addition of an exterior critique. As such, I've modified my initial proposal to include a specific site, and a more specific implementation plan. I've also implemented a rudimentary demo in Logic Pro to simulate the effect of the installation.

ppt: orchestraSeating mk. 2

Pixel By Pixel: Experiments In Thermal Imaging

2010-03-03T07:15:00.000-08:00

This week in Pixel By Pixel we were asked to embark on a project inspired by light phenomena observed on our recent trip to the New York Hall of Science. As such, I decided to take the museum's thermal camera a step further, and actually create a thermal pixel grid, seen above. The grid (in theory) would use peltier junctions behind an insulated grid of copper tiles, which one could then heat individually using a microcontroller.

The paper "canvas" frame

Unfortunately, the project had challenges from the outset. The first was in the initial concept itself: Once I started testing the copper tiles with the peltier junctions, I discovered that something about the copper tiles, probably reflectivity, caused them to be invisible to the thermal camera. I tried aluminum as an alternative, and had the same effect. However, when I used paper, all seemed well, so that was my new solution.

The four transistors of the circuit

I created a frame for the paper canvas, and then endeavored to complete the full circuit required to power the four peltier junctions. This was achieved by creating a circuit consisting of four transistors and an external power source. The power source was required to adequately heat the junctions, and the transistors were used to control the power source's path to each junction.

The fully wired canvas/box

Once the circuit was complete, I mounted it (and the four peltier junctions) to the back of the canvas/box, thus enabling the entire unit to stand largely on its own, with the only outgoing connections being to a power source and the microcontroller.

Once this was complete, I began to test the unit using test patterns, and then the true problem arose: the peltier junctions function smoothly for 20-30 seconds, but as they begin to retain heat, they begin to lose their ability to turn "off" as pixels, and they simply become a grid of pixels stuck in the "on" position. What's more, the thermal camera itself creates recurring (and irritating) scan lines. These effects can be seen (along with ITP in-lab antics) in the video grab from the thermal camera above.

While the end result was ultimately a disappointment, the endeavor was not. The idea still seems feasible, even if peltier junctions are maybe not the appropriate solution. What's more, before the pixels fail, one gets a general conception of the idea trying to be achieved, and it's actually quite visually pleasing. What's more, I feel that the addition of a color camera could further the project to an even greater extent. Put simply: there are still many aspects to explore.

Little Computers: Fun With Drawing

2010-02-25T17:36:00.000-08:00

This week for Little Computers, we were asked to use iPhone drawing techniques to create an app that utilized them in an interesting or animated way. Given the weather, I decided to use precipitation for inspiration, and made an app based around rain.

The app starts out (as above) with some clouds and a low lying body of water. As you shake your iPhone, the accelerometer detects the movement, and the app generates water drops in response. As the drops reach the body of water, it rises accordingly.

Once the body of water has risen to the edge of the clouds, it detects this, and holds off creating rain so it can have a moment to recede. After that, you can start all over again!

The shapes in the application were rendered in Quartz, the 2D rendering engine native to Mac OS.

github: FunWithDrawing

Sound And The City: New Japanese Underground

2010-02-25T08:58:00.000-08:00

This week for Sound and the City, Mark Triant, Igal Nassima, and I were asked to present on some aspect of sonic history. We collectively decided upon Japanese noise music, sometimes known as the "New Japanese Underground". Below is our presentation (complete with graphics and sound) to the class. Enjoy!

pdf: New Japanese Underground Presentation

Nature Of Code: Midterm Proposal

2010-02-22T14:36:00.000-08:00

For the Nature of Code midterm, we were asked to do the following:

Develop a proposal and a prototype for a "midterm" project. The scope of the project can be quite large (trial idea for a final, for example), however, you will not be expected to implement the entire project. For the proposal, include a description, relevant links, and a quick Processing sketch of the first step towards the idea. Link your proposal from the wiki. Next week, we will look at a selection of proposals and then on Mar 2/3, the results for all midterm projects will be presented.

As such, I've decided to continue my work on modeling popcorn using the Box2D library. While the original attempt was moderately successful, there are a number of aspects that I'd like to modify and enhance so that the simulation will be more realistic. Specifically, they are to:

Enhance the geometry of the popcorn so that the kernels and popped corns are not uniform in shape and size.
Work with density variables to create more realistic behavior as the corn pops and expands out of the kettle.
Work with kernel placement and velocity so that the kernels don't breach the kettle walls upon popping.
Allow for user interaction and variability with the simulation, including: amount of popcorn, turning the kettle on an off,
Create more realistic visualizations to associate with the simulation as a whole.

These changes will also serve to further familiarize me with the Box2d library, and its ramifications for geometry and particle systems in a modeling context. The project will not be the prototype for a final project, but rather the final iteration of an earlier project before I embark on a final.

Nature Of Code: Popcorn Modeling

2010-02-16T07:59:00.000-08:00

This week in Nature Of Code, we were asked to use the Box2D library to implement a model of some real world phenomena. Box2D is a physics system that manages the physics of a given system, which you can add various physical "bodies" to. This allows you to create a realistic physics model for a given 2D system with very little coding overhead. For whatever reason, when I heard this, my mind immediately went to popcorn.

For a smaller number (100) of kernels, my model (with a small amount of tweaking) actually works quite well. The kernels pop somewhat naturally, and the system generally handles the physics of the situation how you would expect it might: just like a real popcorn popper! You can see the effect of 100 kernels in the first two illustrations of this post.

However, from there I started adding more kernels, and got into some trouble. At 150 kernels (above) the physics started behaving a bit erratically, and areas with a lot of popping density would cause kernels to move through solid objects.

When I increased the number of kernels even further, to 300, this behavior became almost ubiquitous in the system. Kernels were popping out of the kettle left and right, and the walls of the kettle seemed almost meaningless.

I have yet to discover what the cause of this behavior is, but my guess is that it's an inability of Box2D to handle the sudden transition from kernel to popped kernel. A few ideas I've had include increasing the time of the "pop" from one step of the physics engine to say, 3 or 4. This might allow the engine to handle the change more intuitively.

One of the challenges of Box 2D is that it has no graphical output, so everything you draw is based upon a Box2D object, but isn't actually a Box2D object. What this means is that errors in one's graphics code can appear to be Box2D errors, when in fact they are coding errors on the users end. This is unquestionably one of the downsides of using a "black box" engine, but hardly enough of a problem to avoid using such a versatile tool.

source: Popcorn Model

Sound And The City: Final Project Proposal - orchestraSeating

2010-02-11T09:51:00.000-08:00

This week for Sound and The City, we presented our proposals for final projects. My project, orchestraSeating, is an installation piece that interactively deconstructs classical music scores. The Power Point presentation for my proposal is can be found below.

ppt: orchestraSeating Proposal

Nature Of Code: Flower Modeling Mk. 3

2010-02-09T07:59:00.000-08:00

The image above is a screen grab of the third revision of my flower-based physics model, last mentioned here. Since then, the model has gone through a number of iterations. The first modified the graphics to be slightly more refined, and more successfully integrated a wind force, as well as a flower "wobble". The initial issues I had with the wind being too uniform were resolved by putting a limit on the force vector, as opposed to the resulting velocity vector. The velocity limit had been causing all of the flowers to share velocity and direction. I intriduced the "wobble" in an effort to give each flower its own movement, in spite of the shared wind vectors.

This revision, the third, takes the second revision and adds the concept of thermals. The thermals can be seen in the regions defined by white lines above. These thermals provide a third, largely upward, force that is defined by the developer. When blooms cross them, the addition of the thermals can result in spontaneous upward movement, ostensibly due to air current resulting in difference from temperature. From here, I think the next logical step is transferring the wind force from a single shared force screen-wide into an array of wind vectors, varying based on screen location.

Code: Flower Modeling Mk. 3

Sound And The City: Soundwalk - "Imaginary Commute"

2010-02-04T07:01:00.000-08:00

This week for Sound and The City, we were asked to create a "soundwalk", whereby we would make a field recording of a walk through a given area, and narrate along. Since I live about 10 blocks from Penn Station, I decided to do an "imaginary commute" as though my home were an office, and I needed to catch a train at Penn to get home. I left my front door around five in the evening, and the result is below.

audio: Soundwalk - Imaginary Commute

Little Computers: Some Interesting Flags For gcc

2010-01-30T09:05:00.000-08:00

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"

Sound And The City: Deep Listening

2010-01-28T08:38:00.000-08:00

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

Pixel By Pixel: Analog Animation

2010-01-27T06:42:00.000-08:00

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.

Nature Of Code: Flowers and Wind

2010-01-26T07:05:00.000-08:00

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.)

Visualizing Data: On Paul Graham

2009-12-10T08:23:00.000-08:00

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

Awesomeness From Applications Class

2009-12-09T20:29:00.000-08:00

A while back in applications class, a group had us do this awesome stop motion pong game. Truly killer - just found the vid. Enjoy!

Physical Computing Midterm: Media Controller; "Pancake"

2009-12-01T11:43:00.000-08:00

The "Pancake"

Again, a bit late on the delivery of this one. Apologies to those waiting with bated breath....

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.

The first step we took was to construct the table surface. We procured two large pieces of ply wood, and cut them into identical circles. One circle was the table itself, while the other circle was cut into pieces for us to build the interface modules. Each of us took on one of the modules, and each module used a different physical interface. The three interfaces were wind based, pressure based, and a conductive sequencer.

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!

Physical Computing Week Eight Lab: Transistors and H-Bridge

2009-11-23T20:38:00.000-08:00

Again, a bit late with this one, but better late than never. In week eight of Physical Computing, we investigated the use of two slightly more complex devices: the transistor and the h-bridge.

The transistor lab consisted of attaching a transistor to a small motor, and controlling the voltage output to the motor via the transistor. This differs from a typical input/output in that the transistor can accept a far higher voltage than the arduino microcontroller's 5 volt power supply. As such, the arduino can still be used to control a device that requires a much higher voltage. The circuit with the motor can be seen above, while a video of the on/off control can be seen below.

The h-bridge lab consisted of using an integrated circuit known as an h-bridge to control the direction of current. Put differently: the motor from the first lab will run in different directions, depending on which way it is wired in the circuit. The h-bridge allows us to select which direction of current we prefer, thus allowing for a single wiring scheme for the motor, but allowing us to decide (via a switch) which way we'd like the motor to rotate. You can see a photo of the circuit above (the h-bridge is in the center), with a video of the bi-directional motor control below.

Visualizing Data: On Jonathan Harris

2009-11-23T20:04:00.000-08:00

While I'm a week or two late in posting, here are some thoughts on Jonathan Harris, complete with prompts from the Visualizing Data blog...

Do you find his pieces effective?
Harris seems to desire an emotive, human aspect to his work, and in that sense I would say that his pieces are extremely effective. He manages to create both visuals and text streams that manage to convey a good sense of emotion and the human element. Part of this is rooted in his use of live data sets, that add an immediacy and reality to his work. The randomness of the imagery also serves to deliver a feeling of humanity, as it creates a constant and undefinable imperfection to the work.

What might you change if it were your project?
I feel as though I might use slightly less saccharine visuals. While I feel that Harris' visuals are extremely effective, they have a certain pastel, Hallmark quality to them that doesn't quite appeal to me.

What tools (color, motion, etc.) does Jonathan employ to express emotive qualities in his work?
Harris uses motion almost constantly in his work to relay a feeling of "nowness". The constant movement creates an unavoidable sense that the dialogue is occurring as you sit there watching it. He also uses pastel colors (presumably for their "emotive" feel), but as mentioned above, this really doesn't appeal to me. Even in a site that riffs on the terrorism threat level, Harris still resorts to almost-pastels.

What makes his body of work feel different than Karsten’s or Aaron’s?
Most significantly for me, it's the use of live data. Karsten and Aaron both obtain data sets, and then create a deliberate and planned visual for them. Harris' creation of a more data "engine" allows him to use live data off the web, and create an immediacy and reality to his work that the others lack.

Visualizing Data: On Edward Tufte

2009-11-05T08:21:00.000-08:00

This week in Visualizing Data, we were asked to explore an delve into the work of Edward Tufte, specifically with regard to these two videos: 1, 2. We were then asked to explore a set of questions, as follows:

With Tufte’s close examination of the iPhone, did you find yourself alerted to interface elements you were aware of but hadn’t paid attention to?
Maybe it's because I've had an iPhone for going on two years, or maybe because I've developed for it, but I didn't particularly find myself taken by surprise by any of the elements illustrated.

Does Tufte make assertions that you disagree with? (Choose a specific example and explain.)
While I agree with Tufte's quest for more granularity on the weather page, I disagree with his similar assessment of the stock market page. While granular weather data (and a map) is something that carries weight for everyone, I think that most people, when checking their stocks, are looking for an extremely high level "what's the Dow" type of insight. Tufte's stock graphic contained far too much information, and wasn't in the spirit of what the iPhone provides: on the go data. If I needed to go dissect 12 months of stock data, I wouldn't be picking up my iPhone; I'd be sitting down at a desk.

Where does Tufte think the best visualizations of today are published?
Tufte expresses that the best visualizations come from those with extensive quantitative skills. Specifically, he cites the "rock stars" of scientific journals, namely Science and Nature.

What’s his logic for this conclusion?
His logic is based in the fact that the individuals producing these articles are extremely bright, have large data sets, and are offered limited space for their publications. The result is a necessity to design high efficiency, extremely dense data presentations.

In general who does he see as the creators of great data visualizations? Scientists? Graphic Artists? Programmers?
While he doesn't express a completely final opinion, it seems that Tufte has high regard for the actual producers of the data, who have a deep level of understanding for it. In his description, he seems to focus most on scientists, while at the same time noting that certain people may need to assistance or hand holding of a graphic designer or artists.

What’s your own opinion, and what do you consider your label or role to be?
I think it's extremely difficult to make conclusions that are quite as decisive as Tufte's. He seems to have relatively black and white opinions about the topic, and I actually feel that as time progresses that those who embrace multiple disciplines are those that will garner the most success. As such, this is what I'm trying to do personally, and much of the reason I'm at ITP. I already have an extensive technical skill set, but I want to augment that with other skills and insights, to ultimately yield a wider breadth of understanding.

How might an “anti-social network” function?
I think about this quite a bit, because socialization can be so life-dominating, that it almost seems like anti-socialization is going to become a useful and necessary tool. Most obviously, an anti-social network might simply limit your media access to things that you needed to focus on, and keep the rest of the world at bay. However, it could also do things to stratify people based on what they didn't like, and essentially do the reverse of all the attempted "matching" of similar interests that goes on today.

ITP Had A Haunted House

2009-10-30T12:39:00.000-07:00

ITP had a Haunted House last night, and I did my best to add to the awesomeness. Specifically, I borrowed an idea from David Bowie's 1997 stage installation, and decided to project some faces onto amorphous "head" type shapes. My fellow ITP'ers were kind enough to indulge me with some awesome footage, and the result was some disembodied, creepy looking weirdness! Thanks to Meredith for the pics...

Physical Computing: Reaction To Visual Intelligence

2009-10-28T14:28:00.000-07:00

Donald Hoffman's "Visual Intelligence" manages to take a relatively conventional concept (that our brain "tricks" us into perceiving much of what we deem "real"), and illustrates it through the novel venue of amputees. By using the amputees' sensation of phantom limbs, Hoffman creates a tangible and realistic illustration of the disconnect between the physical and the mental world.

While Hoffman's examples do a great job at illustrating the concepts, the concepts themselves aren't exactly novel. It's a well known fact of many simple schoolyard tricks that the brain can be easily tricked into misperceiving "reality". Watching movies, smelling one thing while eating another, combining hot and cold sensations - all of these things can allow us to trick our nervous system into perceiving things that aren't "really" there.

In the end, this fact is obvious, but perhaps overlooked because it is so common: the best thing we can do moving forward is to try and consider how we are really perceiving the world around us, and enlist this as we make choices in design.

Visualizing Data: Reaction To Karsten Schmidt

2009-10-28T14:10:00.000-07:00

Karsten Schmidt describes himself as a "Computational Designer", and the description is apt: most of his design projects are driven by code and generative algorithms. In stark contrast to Aaron Koblin, who uses small amounts of data from a wide range of individuals, Schmidt uses programatic iterations that generate similarly unique data sets.

The generative nature of Schmidt's work definitely separates it from Koblin's more "techy" work: While Koblin's pieces simply use data sets with modern visualizations, Schmidt's generate their own data. In the end, this results in the pieces (which could potentially be seen as more robotic or inhuman) actually having more in common with Koblin's human created data sets.

This conclusion about Schmidt's work brings to mind a number of interesting questions in the area of data, technology, and intelligence. Specifically: what is interesting about data, and where are its most interesting sources? Moreover, if data is real or generated, does that make a difference, and what is it about the presentation that gives it a more human feel?

To my mind, Schmidt's work unquestioningly draws attention to the fact that artificial, generated data can be every bit as human as real data sets, perhaps moreso. Considering it further, this may be a result of the fact that generative data is "growing" in much the same way a group of humans "grow" a widely dispersed data set. In the end, perhaps it is the life of the data, rather than its end points, that truly define how it is perceived.

Visualizing Data: Reaction To Aaron Koblin

2009-10-28T13:39:00.000-07:00

In looking at Aaron Koblin's work, the pieces seem to be divided into two categories: those that use amazon's mechanical turk to generate data, and those that simply create visualizations of large data sets. While the visualizations certainly have their appeal, I have to say that I prefer the amazon mechanical turk projects.

The mechanical turk generated data sets not only provide novel visualizations, but also novel ways of generating the data that led to them. Seeing how data sets that are created at a micro level are still inexact is an interesting analogy for how larger projects can have an inexact nature to them. What's more, Koblin's visuals are compelling and unexpected.

By contrast, the visualizations that depend on external data seem to suffer from a forced feel of trying to hard to be futuristic or "different", but in fact ending up being cliche. The idea of mapping flight patterns or telephone lines has been done a million times, while the "House Of Cards" video is utterly reminiscent of needle pads that fit-form to represent shapes.

Out of all of the pieces, my favorite is probably the sheep market: the representations are novel and humorous, the data collection interesting, and the representation enjoyable to navigate. In short, it presents some serious concepts about data generation in the modern world while at the same time giving them a humanistic feel.

If anything, that is the shortcoming in Koblin's less enticing work: the absence of humanity and a feeling of overly-conscious attempts to be futuristic and technologically advanced. Part of this reaction to Koblin's work is probably driven by over exposure to faux-futurist imagery, but it's also a result of the fact that Koblin's more human works are simply more novel and easier to relate to.

Physical Computing Week Seven Lab: Multiple Serial Output

2009-10-27T12:38:00.000-07:00

Building on last week's serial lab, this week took the same principles and applied them to multiple, rather than a single, serial data source. In this case we took a circuit containing two analog and one digital sensor, and sent the output to a Processing script.

Here's a picture of the circuit - as you can see, there are two analog inputs (the potentiometers) and one digital input (the push button). As was noted in the lab, this set of inputs represents the same inputs as a typical one button mouse.

As such, the inputs were used to control a circle on screen, with the push button turning the circle on and off. You can see this control at work in the video above.

After getting the script working with a streaming serial input, we then rewrote the arduino side to wait for a handshake before it started sending data. Once it received the handshake, it would send only one set of data, until it received a request for another set. This serial behavior can be seen in the video above.

As mentioned at the top of the lab, the principles put to work here are very similar to the ones from last week's lab, but simply expanded to allow for multiple inputs. This, in turn, allows us to use the Arduino's serial output in a far more versatile and productive manner.

Physical Computing: Real World Technical Observations

2009-10-20T21:27:00.000-07:00

This week we were asked to go into the "real world" and observe people interacting with devices, and see how it met with our expectations. I did just that, but unfortunately had very little to report in terms of results: Everywhere that I went, people seemed to use devices or interfaces exactly as expected.

I spent some time near an ATM, by the entrances to some buildings, and near some subway metrocard machines. In all cases, it seemed that the users knew how to use the devices on hand, and simply went through the motions, often almost intuitively. There are two explanations that I can attribute this two in relation to last week's readings.

First, it may simply be that people are smarter than the "bad design" critics give them credit for. Put differently: just because something is poorly designed doesn't mean it's unusable. It's just that it's sort of a hassle, but that people are adept enough to figure it out. Take the case of a PC: I used Windows perfectly well for years. Now that I use OS X, I'm far happier, but my ability to function hasn't particularly changed.

The second explanation is that it's simply a case of learned behavior: in a city like New York, people tend to have routines and typical day to day actions. It may simply be that the people I observed have overcome poor design because they've become so accustomed to it - now they simply function as normal, and envelop the poor design in their routine.

I think the reality is that it's probably some of both: Very few poor designs are unfathomable, but they could be somewhat challenging at first. However, after the 100th time using a door or an ATM, very few functional humans are going to keep making the same mistake. That being said, the reality is that if there were more, better design, it might simply make people's lives easier. This might in turn lead to happier people, and then - who knows!

Physical Computing Week Six Lab: Serial Output

2009-10-20T20:58:00.000-07:00

Through no fault of ITP's, this week's lab was perhaps the most redundant task I've undertaken since starting the program. This is largely due to the fact that when I started working at Dolby Laboratories, my first sizable task was to write almost the entire software stack for serial communciation on the Dolby Digital Cinema system. As such, doing so in a basic manner on the arduino/processing platform ended up being pretty trivial. That being said, it was fun to see it working, and to discover that processing and Dolby use the same serial back end libraries - RXTX!

Because of my strong familiarity with the material, I designed a relatively simple circuit employing a potentiometer to send analog data over the serial port.

Doing a read on this data was also relatively straightforward, allowing it to be piped into a graph in processing, which can be seen above.

Yay! Serial communication!

Physical Computing: Stupid Pet Trick

2009-10-20T20:47:00.000-07:00

With the knowledge acquired thus far, we were enlisted to create a "Stupid Pet Trick" for Physical Computing. In short, this meant creating a novel, simple device that enlisted out knowledge of analog and digital inputs and outputs in a hopefully entertaining. In my case, I decided to take the assignment quite literally, and design an interactive cat toy.

The toy consists of two pieces: a tennis ball on a spring, and a laser pointer mounted on a servo. Once the program is initialized, the servo is driven by data coming from a flex sensor embedded in the tennis ball. In this way, the play of one cat (with the tennis ball), will drive the entertainment of another (with the laser pointer). In short, it's a low maintenance way to have the animals keep each other busy.

I embedded the tennis ball and spring in a wooden platform for stability, and fed a flex sensor up into the spring. That way, when the spring bent, so did the flex sensor. I routed a wire conduit out of the wood so that the wires would be hidden, and then sealed them in with a glue gun.

The laser mounted on the servo was a bit more of a "hack job", employing twist ties and a free Flaming Lips laser pointer. However, in the end it worked out quite well, with the on/off button controlled by another twist tie.

The circuit itself was actually quite simple, needing only one input and one output for the flex sensor and servo, respectively. What's more, it worked quite nicely with the spring easily driving the servo.

Perhaps the only drawback was that as a sketch of a device, I kept the two pieces quite close together. This resulted in the two components being far too close together to allow for "real world" testing without the two pieces distracting the animals from "their" side of the toy.

Visualizing Data: Jan Tschichold, Graphis, And Josef Müller-Brockmann

2009-10-13T20:57:00.000-07:00

This week in Visualizing Data, we were asked to look into the work of three designers: Jan Tschichold, Graphis, and Josef Müller-Brockmann. All three are Swiss, and based mainly in the mid-20th century. Moreover, the three also seem to have a unified aesthetic sense that is based firmly in a simple, rigid, and linear form.

While the three certainly create some interesting images, I'm not totally sure what it is that might distinguish Swiss Modernism from Modernism in general. Moreover, I found these three in particular somewhat difficult to research, and their presence on the web is not quite as prevalent as that of their more famous colleagues.

That being said, it's clear that there is a unity amongst their work: all three seem to lean towards geometric designs that employ simple fonts, geometric shapes, and stark colors. What's more, all three are hailed as innovators in this area. As such, it may be that their innovations and style seem more mundane in today's climate where many of their stylistic choices have become part of the mainstream.

Reactions To "Attractive Things Work Better" and "The Design Of Everyday Things"

2009-10-13T17:51:00.000-07:00

This week in Physical Computing we were asked to read two pieces, both by Don Norman. The two pieces provided contrast to each other, in that the first, "The Design Of Everyday Things" is a chapter from Norman's original book focusing on usability, while the second is an essay attempting to amend some of his original conclusions and take aesthetics and emotion under consideration.

While both readings are interesting, by in large their conclusions both seem to exist extremely squarely in the realm of common sense. Perhaps this is because the writings are close to two decades old, and it is certainly true that capable and aesthetically pleasing designs have become much more mainstream in the past ten years.

In the first piece, Norman makes a strong case for utilitarian designs, and the need to consider usability in deployment. In the second piece, he responds to his own writing, by conceding that aesthetics can have an equal importance to usability when designing the optimal device.

That being said, many of Norman's examples seem trite, or perhaps from another age. The tasks or devices that he cites as being challenges are simply things that most adults today know how to deal with. The "blinking clock on the VCR" is a joke rooted in the 80's, and with good reason; it's simply no longer an issue.

Norman's writings may have had poignancy and relevance ten years ago, but today they serve to do something different. They are illustrative of the advances that have been made in design in the mainstream, and just how prevalent they are. Here's hoping the trend continues.

"Mystery Data CSV" Parsing

2009-10-07T21:24:00.000-07:00

This week for Visualizing Data we were given a "mystery" data set, along with some hints that the set (wink, wink) might contain x-y coordinates. This was an exercise in not only parsing CSV's, but also in taking in data and deriving meaning from it.

A quick parse of the code revealed the x-y coordinates, and quickly demonstrated them to represent a map of the world. The third (data) value was indeterminate, but appeared to represent some sort of variable (population, energy consumption?) associated with more populous areas. When used as a pixel's alpha value, the picture came to quickly represent the well known maps of earth from space at night.

While this was all well and good, it didn't seem to reveal anything about the data, other than that it was exactly what it appeared to be, and that there was world wide trending. However, in an effort to possibly determine slightly more about it, I decided to project the data values into the y axis, and the y axis into z space. This meant that the map was being rendered horizontally, with the height of the map representing data at a given point.

Once this was done, it revealed a few more interesting facts about the data:

1) Despite the "hot spots", there's not a particular are of the world that doesn't have high data points. The points are universally high and low across the breadth of the map.

2) The data appears to be highly stratified across the map, resulting in data "rows" on the y-axis. While I can't be sure why this might be, it seems likely that these "rows" are the result of estimates or rounding employed in the data collection.

Overall, this exercise allowed me to parse CSV's, which is relatively trivial. However, it also forced me to look at the data a little more closely, and in doing so revealed some facts that might have been otherwise overlooked in the 2D model.

Download code by clicking here

Some Thoughts On The Gotham Typeface

2009-10-05T20:01:00.000-07:00

This week in Visualizing Data, we were asked to consider the Gotham typeface and answer a few questions. Here are my thoughts.

What is the “Gotham” typeface and what is its design inspired by?
The Gotham typeface is a typeface commissioned by GQ magazine in an attempt to find something new, geometric, and masculine. The typeface was inspired by the type on the buildings of "old New York", specifically the Port Authority terminal.

What type foundry drew and released Gotham?
Gotham was drawn and released by the foundry Hoefler & Frere-Jones.

How much does this type foundry charge for the “Gotham Bundle” for a single computer?
The "Gotham Bundle" sells for $69.00 on the H&F-J site.

How does that make you feel about fonts you’ve pilfered (if you have done so)?
Frankly, I think that typefaces should be free when used outside of a business context. The concept of "owning" a typeface even seems silly in a general sense, but is a necessity for foundries to exist. That being said, as a student and/or creative artist the likelihood that I would ever personally pay for a font is precisely zero.

And briefly, who is Matthew Carter and what did he contribute to digital typography?
Carter is a typographer who began working in the 1960's as an apprentice. He later (in 1981) went on to start one of the digital-specific foundries, Bitstream. The significance of his contribution can be most easily summed up as being one of the pioneers of developing fonts that are tuned specifically to have a high degree of readability on a computer screen.

Theme And Variation

2009-10-05T19:09:00.000-07:00

In the Theme And Variation assignment, we were required to use only two input values: a string of text, and a single integer. We then would use these two input variables, along with only black and white, to render a visualization of the input data.

My idea was to create a grid of 27 circles representing the alphabet, with the last circle being for special characters. I would then blackout the circles to relay the string to the viewer. This worked well, but created a somewhat standard uniformity across the grid. To remedy this, I offset the letters being displayed going from top to bottom. This allows for patterns that create more of an animation. Changing the input string changes the look of the animation, while changing the input int changes the frame rate of the rendering.

The version above is actually the second version of the assignment, with some refinements and changes. Specifically: I fixed the opening "grid setup" to use an independent frame rate, so that you don't have to wait around when you use a small int. I also added the "growth" of the rendered circles, so that they no longer appear to flash on and off, which results in a smoother animation. Finally, I revised the code to be more character-agnostic, since this aided me in animating the circle "growth".

Download Code: Theme and Variation

A Reaction To "Design Meets Disability"

2009-10-05T15:19:00.000-07:00

This week's reading for Physical Computing explored the gap between the worlds of design and engineering, focusing specifically on the realm of devices made to assist the disabled. The article contained a wide range of insights about this largely engineering based industry and its seeming disconnect from the world of design and aesthetics. However, the portion that resonated with me most strikingly was the greater problem of separation of industries.

In today's world, it seems that there are often very striking lines drawn between industries, resulting in the undesirable result of poor implementation, reduction and usability. This is clearly exemplified in the article in relation to devices such as wheel chairs, prostheses, and hearing aids. However, this is just one example of a gap that needs to be bridged. Throughout day to day life, we see and use devices and interfaces that are hindered by the fact that they were engineered, and never designed.

Thankfully, this is a problem that is slowly being addressed by many companies, and hopefully is the reason that many of us are at ITP: To gain insight, learn from others' experiences, and create devices that encompass a wider array of perspectives and insights.

Physical Computing: Week Four Lab

2009-10-05T15:06:00.000-07:00

In week four, Physical Computing turned to using our analog output to work creating productive output products. This included two labs, creating output in two forms. The first was a servo lab, which took an analog input and mapped it to the physical movement of a servo. The second was a tone lab, which took analog input and mapped it to the output of a small speaker. Both demonstrated that an analog sensor can easily be used to create tangible output effects.

In the first lab, we wired a circuit to include an analog sensor and a servo. In this photo we can see this circuiy implemented, with a flex sensor in place to control the servo.

Once the circuit was completed, a simple upload of the lab's arduino program yielded the behavior seen in the video above. Either a manual pulsing or the arduino servo library could be used, and the same behavior resulted. In short, the flex sensor's analog output controls the position of the servo.

The second lab followed a similar concept, but instead used the sensor to control tone on a speaker. I chose to use a potentiometer for my control, so that dialing it would control pitch. This circuit can be see above.

Once wired, this circuit also required a small arduino program that would map the analog inputs to an analog output value for the speaker. In the video above, the potentiometer is being moved, and the resulting speaker tone changes in turn.

A Reaction To "The Bandwidth Of Consciousness"

2009-10-01T09:54:00.000-07:00

In taking on this week's reading, "The Bandwidth Of Consciousness", I have to say that I'm a bit flummoxed on a number of counts. Most notably, the fact that the author believes that the correlation between bit rates and human thought and bandwidth is even a reasonable one. If I look at an extremely high resolution image (say, 100 MB), am I suddenly consuming data at that "bit rate"? More imporantly, say the color depth of that image increases so that it's now 200 MB in size. Am I now consuming even more data? The prospect is silly, because the fact of the matter is that humans don't consume data as "bits", and an attempt to illustrate otherwise is a lost cause. For another example, think of audio: recorded audio has a bit rate that could potentially indicate "bandwidth", but then live audio has an infinite "bit rate". If I listen to a live violin, is my bandwidth consumption infinite? However, even more ridiculous is the concept as a whole: the idea that you can take the input to the human nervous system and in any way quantify it is simply a principle that I don't see as viable. While it's certainly interesting to see scientists attempting to pursue explanation in this manner, at the end of the day I can't really see that it yields very much value or insight to the reality of the situation.

Physical Computing: Week Three Lab

2009-09-29T18:20:00.000-07:00

This week's Physical Computing Lab consisted of learning some basics about electricity. A lot of it felt like review from PSSC Physics, but maybe that's just me. That being said, I also dug in and did some soldering for the first time in about a year, so that was cool. I also learned a thing or two about my multimeter's sensitivity, which is apparently one decimal place shorter than the one owned by Tom Igoe. Read on for all the glorious excitement.

The first bit of the lab involved getting a DC power source connected to the bread board. While it technically could have been achieved without soldering, I decided that messing with a power supply was silly-slash-stupid. So, I put my soldering chops to work and soldered the power jack, as seen above.

Once the power supply was attached via the power jack, we setup a small circuit involving an LED and a voltage regulator. In this photo you can see the voltage meter keeping the voltage steady at 5 DC volts. This setup would be the testbed for our various voltage and amperage experiments.

In the above two photos you can see some voltage tests on both the resistor and the LED. You can see that the two have different voltage consumptions, but more importantly that the summation of the two is equal to the five volts being put out by the voltage regulator.

Our next step was to set up two LED's in series. As you can see from this photo, the LED's lit, but to a lesser extent. From the voltage readings in these photos we can see that since the LED's were forced to share voltage, each consumed less power than the single LED setup. This is a result of the series circuit. When I attempted to use three LED's, they simply did not light due to lack of voltage.

The next step involved a similar setup, but in parallel. In this case the LED's have a uniform voltage of 1.95. This reading can be seen here on only one LED, but was the same for all three.

Next I made an attempt to measure amperage, and was met with no reading. In fact, I later determined that the setup was working (as evidenced by the lit LED), but that my multimeter was simply not on a sensitive enough setting.

The final step was to use a potentiometer to limit voltage to the LED. In the above photos we can see the potentiometer in three positions (on, half, and off) and the resulting voltages. This is a clear illustration of the potentiometer acting as a voltage divider. You can also check out the video below for a "live action" take on this electrical phenomena.

Potentiometer Controlling Variable Voltage On An LED from Hippies Are Dead on Vimeo.

Physical Computing: Fantasy Device - "Anywhere Box"

2009-09-22T19:13:00.000-07:00

The internet has largely transformed data usage and consumption into a location-free activity. Videos can be streamed, documents can be shared, music downloaded, and conversations had across oceans. What the "Anywhere Box" attempts to do is take this principle and apply it to physical objects. By providing the user with a physical interface to a remote box, the anywhere box turns the location of an object into an irrelevant issue, much like email servers or web space do with digital data today.

This, of course, first begs the question of what one might keep in the Anywhere Box. Perhaps the most obvious answer is those things that people always want to have access to, but are continuously misplacing: keys, wallets, cell phones, and the like. However, even more interesting is the possibility of having access to more valuable possessions at a moments notice: family jewelry, birth certificates, large amounts of cash, etc.

The box consists of two pieces: the end user "frame", and the box's "home" location. Much like a safety deposit box, the home location is highly secured to allow for complete ease of mind. However, it is even far more important to note that the location of the home box is irrelevant, since it can be accessed by the user at any time via their frame. This means that the box storage facilities could be underground, in space, or any other location that might prove convenient.

The user's frame takes on a guise similar to that of the tablet PC: it a flat computer-based interface consisting of a screen and a small number of buttons for security and power purposes. Once the user powers on the frame and completes security scanning (see below), the frame "activates" and provides access to the user's Anywhere Box.

The box itself would be rather modest in size, to allow for easy access from the frame. It would share the two dimensional sizing of the frame, and a depth of no more than one foot. This would allow all the contents to be easily accessible, and all visible at one time through the frame. The box would be equipped with a sister frame (not visible to the user) that would allow the frame to make the connection and provide access to the box.

Security is the primary concern of such a device, and as such would provide a wide range of contingencies to verify the user's identity as follows:

The frame would feature a voice, retinal and fingerprint scanner, all of which would be required in unison to access the box. This would allow for complete biometric identification, and moreover almost infallible security.
Once these three tests had been passed, the frame would optionally require a numeric code, for users that wanted an extra layer of security.
The frame would be irreversibly paired with the home box. If the frame is destroyed, there would be no other way to connect to the box, aside from physically being in its presence. In this case the user would have to contact the manufacturer to get access to a new box and frame. This would ensure against any sort of outside hacking or network based breaches, as the hardware would be linked outside of network protocols.

The Anywhere Box provides a number of challenges, not the least of which are physics and reality. It would require something in the nature of a teleporter or a worm hole. Not only that, but once the connection was established, there's still the issue of the physical relationship between the inside of the box and the outside world. If one turns box upside down, do its contents spill out? If it's filled with water, can it spill? These questions illustrate the unreality of the Anywhere Box.

However, the Anywhere Box also investigates the nature of data in the 21st century through a different lens. Can we shift our data paradigm to apply to all objects? If an object is accessible everywhere does it become more or less valuable? If you had access to your most important objects at all times, how would your life change? Would an always-secure personal safety deposit box obviate the need for banks? The Anywhere Box brings about all these questions, and illustrates the remaining necessity of physical objects in a digital age.

Physical Computing: Week Two Lab

2009-09-22T12:02:00.000-07:00

Week two of physical computing sees us engaging with analog input devices, and using that input to drive an output. Specifically, we were asked to use a range of analog input devices to drive an LED. I chose to keep it simple and use a potentiometer and a photo sensor to drive a simple one LED setup. Not exactly intricate, but definitely to the point and capturing the essence of the idea.

The first task was to wire a potentiometer to the breadboard. In this picture you can see the potentiometer wired and connected to analog I/O zero, in this case as an input. After adding the potentiometer, I then added the LED to digital I/O nine, and set this port to output mode. You can see the LED in this photo as well, ready to act as a reflection of the potentiometer's position.

Using the provided lab code, the setup was validated, and the potentiometer used to control the LED. This can be seen in the video above.

Following the use of the potentiometer, we were encouraged to use another analog sensor to deliver a signal to the LED. In this case I chose a photosensor that comes with the ITP materials kit. At first (as can be seen in the above video), the sensor gave me passable, but suboptimal, results.

I discovered this was due to the fact that I was using an inappropriate resistor, and not massaging my input data in any way. By switching the resistor to more appropriately match the rating on the photosensor, and furthermore mapping top and bottom data input, I managed to coax the LED into reacting more smoothly to the input.

While this week's lab was certainly interesting, it seems like it could be easily combined with week one's lab. The principles are largely the same, and making the jump from digital to analog input isn't a large one. That being said, there is far more potential for experimentation with analog sensors that I failed to take advantage of: I'm planning on kicking that into gear with next week's Stupid Pet Trick.

Solving A Rubik's Cube, or, Exercises In Extreme Boredom

2009-09-17T08:10:00.000-07:00

After a number of vested attempts (both in the intellectual and physical world) to inspire myself in the art of solving a Rubik's cube, I found myself completely uninspired and apathetic about the task. Solving the Rubik's is an exercise in algorithm repetition and color matching, neither of which particularly appeal to me.

While it may not appeal to me, it was nonetheless a requirement of my class to demonstrate how the cube could be solved, and I needed a solution to that problem. As such, for those who are truly interested in solving the Rubik's, I offer up these fine options:

Watch the video above. It's step 1 in an extremely (almost an hour!) lengthy tutorial. I started nodding off on step 4, but if this really interests you, the tutorial is exhaustive and complete.
Go to this link. It's a Rubik's solver where you input your cube configuration, and it provides you with a solution.
If you're more code-minded, go here. It's the source code for the above mentioned solver, and should lend coders an algorithmic insight into solving the cube.

While I realize these solutions might not be in the "spirit" of true Rubik's solvers, I think they do illustrate a greater point, which is that computers and technology enable us to do things faster and more quickly through the sharing of data. What's more, the solver is a clear illustration of the ability of technology to eliminate repetitive, physical tasks. This applies directly to visualization of data, which allows for an encapsulated and high level view of data that might otherwise be stupefying, or downright impossible to understand.

Physical Computing: Week One Lab

2009-09-15T18:42:00.000-07:00

Week one of Physical Computing brought on two labs that were both largely associated with familiarizing ourselves with the environment we'll be working in all semester. Specifically bread boards, the Arduino microprocessor, and basic circuits. As such, the labs involved more hammering out the basics than they did pushing the boundaries. That being said, with the addition of my Applications presentation this week, I wasn't exactly heartbroken to have PComp go easy on my creative side.

The first section of the lab consisted of familiarizing ourselves with the breadboards from our tool kit. While it's a pretty basic concept, it's still worth going over and comprehending. Basic points are as follows:

The bread board consists of two parts: powered columns and isolated rows
Each powered column is connected along the length of the board on the left and right sides. If these are connected to a power source and board, they then provide power to use in circuits.
The isolated rows go from top to bottom in the middle of the board, and are further isolated by a divider down the middle. This means for each row you have two sides that are isolated for use in a circuit. The photo above illustrates a multimeter validating the continuity of a single row.

The next step was to actually power the board. This requires a 5 volt power supply and a ground. Above, you can see breadboard prepared and powered via the Arduino. Note that I've also wired two rows to use the power source: one row is a ground row, the other is a powered row.

Once the board was powered, the next step was to add a switch. I decided to use a standard retail switch, and wire it to the left side of the board. The switch was connected (via the white cable, above) to a digital input of the Arduino, which would allow us to programatically track the switch's state. This required using two rows, and the addition of a resistor. The addition of the resistor ensures that the switches state will be reflected over the digital input wire, rather than just disappearing over the ground.

With the switch implemented, it was time to add LEDs to the board. The Arduino program would track the state of the switch, and modulate the LEDs accordingly. Above you can see a picture of the LEDs wired to the Arduino's digital outputs. The resistors in place assure a minimal load on the LEDs in order to increase their life.

Finally, the setup was put to work: I compiled and uploaded the program from the lab to the Arduino, and proceded to enable it. Depending on the state of the switch, a different LED would be lit. You can see the two states above, and a video of the working mechanism below.

Once the basic switch setup was complete, we were entreated to contemplate other possible applications of basic digital I/O, particularly with regard to a combination lock. Upon considering this, most of my ideas drifted into the range of abstract or shape based locks. While most combination locks in the real world tend to be based around numeric key pads, it seems that one could be constructed based more soundly around interacting with a grid of switches that were either uniform, or based on a wide array of shapes and sizes. This would have the advantage of being more secure due to its abstract and spatial nature, and also being easier to remember for individuals who are already inundated with a large number of numeric codes in their lives. One example of this implementation that already exists in the digital world is the gesture based security in the Android mobile OS. However, there's no reason this same concept couldn't be applied to physical locks as well.

Sensor, Walk With Me

2009-09-15T18:07:00.000-07:00

Today, as per our first Physical Computing assignment, I took the walk from ITP uptown to pick up my laundry in Chelsea. Here's a log of some of the more notable sensors I saw in my environment.

The walk started as I left ITP and walked past the "wooden mirror" - that dot in the middle is a camera! Photo sensor to the max!

I walked on towards the elevator and interacted with a sensor on the elevator button. Once I got inside, the button for downstairs had already been pushed, so I didn't get two sensors in one interaction...

From there I walked into Washington Square Park, where I saw this woman tapping away on the sensors in her computer's keyboard.

Across the way, this guy was talking on his phone - the microphone is a sensor measuring the output of his voice.

Soon after I walked past some folks loading a truck with a lift. They didn't want to be in the photo, so I just snagged a picture of this sensor, which caused the lift to move up and down.

This woman was a tad more accommodating, and cracked up as I took a picture of her texting away - and more importantly, pressing the sensors of the buttons on her phone!

This guy was taking a picture of his friends on the street - talk about sensors: photo sensor, distance sensor, sensor on the camera's button - techno overload!

This postal worker had a fancy-schmancy device with a touch screen sensor, and he was kind enough to let me snap a shot of him using it.

Debateable as to whether it's "really" a sensor, but it seemed like maybe these bells could qualify as a sensor to the door's motion.

At St. Vincent's Hospital, the ER doors were equipped with motion sensors to open at a moment's notice.

Meanwhile, New York's new parking meter slash computers provided this guy with a satisfying button press.

This restaurant employee uses a touch screen sensor all day, and is damned excited about it!

Finally, I arrived to pick up my laundry and noticed this load in progress: it's using a sensor to measure water levels before it starts to spin.

This scale is a sensor for laundry weight, and how much I'm going to be fleeced for keeping clean!

The credit card machine has two sensors: one to read the magnetic stripe on the card...

...and the other to enter data via the key pad.

So I concluded my sensor walk: fresh laundry in hand, and a new and unique perspective on my daily route home.

I Am Jack's Applications Presentation

2009-09-15T17:22:00.000-07:00

Our Group (Group 2!) had the distinct privilege of being one of the first two to present in Red's Applications class. We had to come up with a reaction to the Vito Acconci's presentation last week, and the video above is where it's at. Themes we tackled included the difficulty of connection, connection as a universal challenge, and connection over technology. Check it out above - thanks to all our super accommodating subjects!

Sol Lewitt At Columbus Circle

2009-09-14T10:32:00.000-07:00

The Architect's Newspaper Blog has a nice mention of a Sol Lewitt installation that was unveiled yesterday at the Columbus Circle subway station. Seems like a prime candidate for an ITP field trip!

Medical Data, Trending, And Visualization

2009-09-13T10:09:00.001-07:00

Wired has a pretty nice piece about aggregate medical data trending, and some pretty solid visualizations to go along with it. Definitely worth a look.

Reactions To "As We May Think"

2009-09-13T08:09:00.000-07:00

Finished up reading Vannevar Bush's "As We May Think" from the 1945 Atlantic, and have to say it was pretty entertaining. Everything about the article is quaint, from the tone, to the ridiculously involved solutions to problems that have since ceased to even exist. That being said, Bush's insight is remarkable, and he truly offers an amazing amount of foresight in regard to the problems that would be facing the world of information technology in the coming decades.

One interesting component of the article is how evident it is that it was written pre-transistor. Almost all of Bush's solutions center around vacuum tubes and microfilm as the innovations of the day. This leads them to be surprisingly involved, and often overly complex. By contrast, the transistor enabled many of his innovations to be implemented in simple and beautiful ways. It's yet another clear reminder of just how much the transistor transformed the climate of technology.

Hello World.

2009-09-12T14:33:00.000-07:00

Welcome to the first in a horribly large number of posts in, around, and about, the life of a student at Tisch's Interactive Telecommunications Program. The student in question is me, Patrick Proctor. Here I'll be outlining my progress in the program, projects and coursework, and giving general perspective on anything that happens to suit my fancy.

If you'd like to see what I'm up to outside of school you can check out my (painfully out of date) personal website, or the blog I run called Hippies Are Dead. See you out there!