When I talk about Computer Club, I often introduce the club as having racks of servers squirreled away in Cyert B-level, happily grinding away at running a variety of services. But there hasn’t been a good way to communicate to people the scale and activity of our systems. I plan to construct a real-time visualization of the status of the Computer Club machine room, making it available directly from our webservers so that anyone can see what’s going on in real time.

I plan to collect data from as many of our servers as possible and aggregate it in a database to drive a web-based infographic. I was inspired by the Planetary project by Bloom, which visualizes the user’s music collection as solar systems in a galaxy, and saw that Computer Club’s infrastructure has a similar three-tiered structure which makes it ideal for such a visualization.

I anticipate the challenges in this project will be in incorporating the “smaller” data, such as active users and processes, into the visualization without either introducing clutter or making them invisible, and ensuring that the data maps in an intelligible way.

Embers (The Digital Artists)

Embers isn’t a particularly impressive demo to look at. What is impressive is this:

6370202430202f746d702f7a3b287365642031642024307c7a6361740a1f
8b0810293e245f3b245f0a290a003af7ebed3f7606086002621620be02e5
b3027100103302b1000341c00863bcc3a3c08280fe440e08871d49820f88
6580980788f54b8b8bf4733293f4532a7352a06206402c816698737e727e
a25e5a51626e6a797e51b63e98cfd0fc46a3f9c9871dcc4005bb415edaff
0d684f1410c4860631e72a74fbca3ce269a855f329fdc41c6aa21d6af388
a3f31a73a90e73a84ac34bced2bb13631312988d66f2af67326273b3122b
fd66ccae5a5f5fcf90d81bc453fa9439eb4fa776626f34cb7aff47d70ddf
32b127b4ff75075b9390f05fb8d345c52311240be5a82073421213418ab1
985cba37713d314ecbced5e1617c45ba034be765e8005d1811181416fe5f
203e2e2a32c30095bfff1c301d743eeb0d63c9304195e9b633fc96618126
66d5f93bc307552c2e8b71df3d06a0218f325cd064c2321cd06c33e86660
c88841159c1e91710de808c3931919686e0d41e577fecb8840d39a1180a6
25018d5f8066c4f30c15342fe9a86468a009d9a8743ecb9040b7bcf37d86
008642c36f86977646b1007d25832ad77c90039b9002314241617759546e
387eb92ba31217d56cc9507a0268b7089a7bde03ddc883e1bb1c5411a039
b76554e2c31bff4f034651b167162310fecffa0f0e9b1434ddf7336c5045
121280267aa08a251e7c279658dc78c00692130fa642b3a4543d90507064
3482d00c4a207a8103a32984669087f22d21f4a87a22d533406848890d01
009ec868c74d1888a2fb29798a3c309ed859e8b26bdc3e54ea17f4adaa2a
b476ac4818538752bad5fe7b8d49916024cebdbae36b2e7de8a643c4193d
0e9a243a2d09ad168446bbfec757bb7c0e219a6fe23b2d054935dbd7c743
d04388beebaf6f9625d397d8b9eca2e5cfdba91182f86a63d420d5c8e909
006f38aa6dd9c4728683bf9710995ff78dda614c3b556c6595669921d767
2afc7560be5bd8885c12e0face899ffe7313a6a48d8074ae37d9ebb9f0e5
96cae7620415edf42b0eecf6334ebb1fd6b89357ef73b89a83ef52dc7620
35b4cf743cba8f24845443a95d21e903da529390e0f4c46e3a1443c94c5b
d1a7dcd3f027427ea667ace9115e4cdbdc059ebe310fc3a52078c9b44ab0
4a66c31b0200b5df601fa24e8e8a49c2e411941e28d8187eef55a3bdf4f6
75bb42960db9f3fe3b36219db1cc8eb5c33d07b8c39d2794a53baf2d1735
00608015619d466941bd3ffc5b4ca2217f824ea576264752109f7e499dbd
aab38e2d936e8a1c4b85b24a60858011b33d9f36936b6e48616a7449be28
6b9e62b499704401ab932f43ae7872864c61206392432c67ae18174b6e51
818c6d8e3f8f8e4969b17ea68e505171997069a65f3e8354948d5ab15436

This is the entire compiled code for Embers. It is only 1020 bytes, and yet the demo manages a soundtrack and variety in the procedurally-generated environments which is rarely seen at this size. Tiny demos are all about unwinding intricate generative scenes from obscenely small amounts of code, and Embers represents an immense step forward in that regard.

Silk (Yuri Vishnevsky and Mat Jarvis)

Silk intrigues me because it has taken an extremely simple idea, that of building curves with the user’s mouse, and yet it has been executed in a way that creates a very rich sculptural experience for the user. The fade-off of the colors and basic applications of symmetry present an easily-learned interface and quickly produce undulating surfaces and voids, almost as alien hallways out of science fiction. One part of me yearns for more controls and capabilities in the interface: wider color selections, more complex symmetries, methods of rotation and translation. Yet at the same time, I feel that the project would become lost under those extensions, and that the present, limited interactions are already sufficient to produce intriguing sketches.

ANGELINA project (Michael Cook)

ANGELINA designs games. She is an ongoing project developed by Michael Cook to produce an artificial intelligence which can generate games without any human input. The project began with simplistic collision-based games, and has evolved towards side-scrolling adventures, reminiscent of the original evolution path of human-designed games. ANGELINA, originally dependent on the work of Cook and others to provide many of the underpinnings of her games, now engineers all of the mechanics of the games herself, and is growing to develop even the images and music for games unaided, all while responding to feedback from real-world users of the games. I find this project especially intriguing because computer-invented computer games seem unlikely to experience the cultural shunning that other forms of artificial art have encountered from the existing community of creators, simply because the idea of computers doing fantastic things all on their own is already part of the paradigm.

Sifteo Cube Gigaviewer

This one’s fairly straightforward.  I really liked what I did with the Sifteo cubes in Project 1, and I’d like to expand it so that the Sifteo cubes can actually be used to explore very high resolution images from a sort of ant-on-a-page perspective.  I’ve already got some code that I’ve made since project 1 that auto-chops images into nice Sifteo-sized bits and then rewrites the LUA file accordingly.  This project would involve packaging all of that up and ideally using the (up and coming) Sifteo USB connection to upload new high-resolution images daily.  This way, the cubes could be an auto-updating installation in a classroom or gallery.

Here are the parts of the project from the image to the cubes (and my classification of each)

1. Get the newest image from a dropbox or git repository (Probably trivial)

2. Write processing script to chop images and autogenerate a LUA script (Pretty much done)

3.  Regularly run the processing script, re-compile, and re-upload to the Sifteo base (Maybe not too hard)

4.  Figure out how to rotate images (Should be easy… need to talk to Sifteo people)

5.  Devise a scheme for managing asset groups better on the limited cube resources (tough but interesting)

6.  Devise a scheme to predict which asset group will be needed next and load in a timely manner to keep the interaction smooth (Hard but very interesting and possibly publishable)

I think there’s some really cool potential here for having to piece together the “big picture” through little windows to understand what you’re looking at.  For example what’s this?

Scroll down!

It’s my arm!

I stumbled upon the “My Milk Toof” blog by Inhae Lee a while back. As the name suggested, it is about a story of two little tooth characters, Ickle and Lardee, who keep this blog alive. The characters are made out of polymer coat and painted with acrylic, and there are about five models of each in different expressions. Making each character by hand not only takes a lot of time, but it also sets boundaries and limitations to what the shapes of the characters can look like.

With the two characters in mind, I want to create a tool that can generate characters in various forms, but at the same time still maintain the same fundamental shapes (i.e. tooth). I am hoping to make use of toxiclibs library to create 3d models. I want to also do some digital fabrication to actually see the characters in a tangible form.