My 2002 (my goodness, that’s 5 years ago!) piece Swarm is part of Right click – Open source new art media exhibition at the Kapok gallery in Hong Kong. Swarm uses an implementation of Craig Reynolds’ flocking algorithm and the Processing source is available in my nature of code tutorials. The show also includes Josh Minor’s wonderfully addictive Video Pong.
I’m working on an interactive kiosk for the Toronto Airport, part of Terminal Zero One. Two early sketches:
Some stills from the multi-screen particles project:
Flight404′s recent exquisite work with additive blending and particles led me to return to an old project of mine. Of course, these days, revisiting a project translates to “add more LCD screens.”
We’ve successfully added support for passing larger amount of data across clients in the multi-screen framework and this has led to some nice experiments, including having one client capture video for the entire system. The demo below involves 3 client computers, 6 LCD screens, and 2 video cameras. Did I mention this is all works with Processing???
Multi-Screen Video Particles on Vimeo
Now, I have to admit. I have a problem. When I had one screen, I wished for two. When two came, I wished for 3. Then 6. Now, I wish for 12. (Well, I would really quite prefer in the vincinity of 96 screens, but I have to be realistic.)
Thanks to Michael DelGaudio for appearing in the video.
Working on a demo for the MPE system consisting a grid of cells, each playing the film Run Lola Run at 60×32 pixels. Each cell is one frame behind (or ahead) of its left (or right) neighbor. The idea here is to ultimately have enough pixel space to display the entire movie all at once (much like Brendan Dawes’ Cinema Redux), only in motion. Too bad this is quite a blatant copyright violation.
(Special thanks goes to Chris Kairalla for suggesting “Run Lola Run” as the source content.)
This week, in The Nature of Code, we’re talking about genetic algorithms. A genetic algorithm is a search technique that involves a simulated population of candidate “solutions” (represented by virtual chromosomes) that evolve towards an optimal state. The process is a computational model of principles from biological evolution, such as selection, inheritance, crossover, and mutation.
One of the more challenging aspects to developing a genetic algorithm is coming up with a good “fitness function” for your candidate solutions, i.e. how well does this candidate solve the problem? Without a good fitness function, you won’t get anywhere since the function determines the likelihood of reproducing for the next generation. This is Survival of the Fittest in code.
Nevertheless, as per Flake, a better natural selection catch-phrase might be “Survival of the Survivors.” In the biological world, there is no fitness “function.” The longer you survive, the more likely you are to reproduce.
With that in mind, the above example is a simple evolution simulation, where the simple ability to live longer affords creatures (called “bloops”) a greater chance of having a child (the example uses asexual reproduction for simplicity, but could be modified to incorporate two parents). A bloop’s DNA determines its size and speed (the larger it is, the slower it moves.) The bloops wither away and die unless they find food, in which case their strength increases, causing them to they survive longer and hopefully reproduce.
There’s nothing inherently interesting about this example (other than as a demonstration of the technique itself) and it yields a fairly obvious result:
Bloops that are too big can’t move, don’t find food, die, and aren’t very likely to have children. Bloops that are tiny can move around very quickly, but aren’t terribly likely to find food either because of their small size. After about 10 minutes or so of running, the bloops evolve towards a “midpoint” where a reasonably sized, reasonably fast family of bloops take over (see above screenshots for “before” and “after.)
Since color is encoded into the genes, you can follow bloops from generation to generation (though it should be noted that color plays no role whatsoever in a bloop’s ability to survive.)
I’ve posted a brief tutorial on using JWNL, a Java library for accessing WordNet.
“WordNet is a large lexical database of English, developed under the direction of George A. Miller. Nouns, verbs, adjectives and adverbs are grouped into sets of cognitive synonyms (synsets), each expressing a distinct concept. Synsets are interlinked by means of conceptual-semantic and lexical relations.”
I wonder how useful it would be to create a Processing library with some basic WordNet functionality (or that simply exists as an interface to JWNL for all things WordNet.) There are many lovely examples of text-based Processing work out there. Two that jump to mind are State of the Union by Brad Borevitz as well as anything ever made by Ariel Malka.
The power of WordNet is not that it provides access to word meanings (which it does), but that it provides information about the relationships between words (and when I say “word,” I really mean set of synonyms, or synset). It’s the myspace for semantic concepts. You’re probably familiar with synonyms and antonyms. In addition, WordNet provides links for less well-known semantic relationships, such as hypernymy, hyponymy, meronymy, troponymy, and entailment. Do I see some sort of tree / network visualization in Processing’s future?
March 4th 2007. New York City
3 Minutes
Wherein we pick a name we like (Tech Trek: Inside ITP) and catch ITP researcher and teacher Dan Shiffman working on 6, 32-inch TVs. His project is was just up and running when we talked to him. It’s an open source Java framework for spanning real-time graphics applets/applications across multiple screens.
Coming soon to a Processing library folder near you, I’m pleased to announce a new project I’m developing at ITP with Chris Kairalla, tentatively titled “Most Pixels Ever.”
“Most Pixels Ever” (not to be confused with “Best Pixels Ever”) is an open source Java framework for spanning real-time graphics applets/applications across multiple screens. The above video is a quick demonstration of the first prototype. Three client applications on three Mac Pros connect to six 32 inch LCD displays (each Mac has a dual video card, but this could just have easily work with 6 client machines). One of the Macs is also running a server application. The server tells each client about the master pixel dimensions of all the screens combined (here 8160×768). The client keeps track of its own location dimensions (say 2720×768) as well as its location with in master dimensions (say 5040,0). The server keeps everyone in line, making sure that frames are rendered in sync.
In theory, the system is scalable to whatever your network will allow. If you want to run 100 LCD displays off of 100 mac minis, you can (and I really hope you do.)
We’ve got quite a bit of testing and tweaking to do before we release the library to the public along with documentation and instructions. So stay tuned!
Thanks to Caleb Clark for the video.
I was just settling into a quiet evening of reviewing material for my A to Z class tomorrow when I stumbled across something quite shocking.
Mind you, I was in a fragile state, having finally released myself from a rather unhealthy personal obsession with the StringTokenizer, silently weeping (inside) while adjusting the examples to use split with regular expressions.
Back in the old days, when using some form of Java Collection, one was required to cast elements retrieved from that collection into the type of element stored in the collection. According to Sun’s site: “Besides being inconvenient, this is unsafe. The compiler does not check that your cast is the same as the collection’s type, so the cast can fail at run time.”
Generics allow you to specify the type of a objects to be stored in a collection to the compiler. This means that the compiler can confirm that you are using the collection consistently and cast the values itself as they are taken out of the collection.
What was:
ArrayList strings = new ArrayList(); strings.add("Hello World!"); String s = (String) strings.get(0);
is now:
ArrayList<String> strings = new ArrayList<String>(); strings.add("Hello World!"); String s = strings.get(0);
Frankly, the syntax is a little ugly and awkward (esp. when you start getting into collections with keys and values), but I’ll play along for now. . .
