work with mark: shadowplay
yet another system mark d'inverno and i worked on but never finished had the working title 'shadowplay'. we had this idea about an audiovisual installation where people's limbs (or outlines of bodies) would represent grid worlds. agents would live in these worlds and evolve differently depending on things like limb size, limb movement over time, limb shape and limb position. the agents would make different music/sounds depending on the world they live in. a limb world could be thought of as a musical part in a score. the worlds would sound simultaneously but panned to different speakers to help interaction.
the visitors would see the outline of their bodies projected on a big screen together with the agents represented visually in this picture as tiny dots. hopefully people could then hear the agents that got caught or breed inside their own limbs. we hoped to active a very direct feeling of caressing and breeding your own sounding agents.
there were plans for multi user interaction: if different limbs/outlines touched (e.g. users shaking hands), agents could migrate from one world to another. there they would inject new genes in the population, inflicting the sound, maybe die or take over totally. though to keep agents within the worlds they were made to bounce off outlines. but one could shake off agents by moving quickly or just leave the area. these 'lost' agents would then starve to death if not adopted by other users.
the whole thing was written in processing and supercollider. processing did the video and graphics: getting the dv input stream, doing blobtracking (using the 3rd party library blobdetection) and drawing the agents and lines for the limbs. supercollider handled rest: the sound synthesis, the genetics, agent state and behaviours, keeping track of the worlds etc etc. we used a slightly modified version of our A4 agent framework i wrote about here.
the two programs communicated via network (osc) and would ideally run on different machines.
i had major problems with programming. the math was hairy and all the features were very taxing on the cpu. we never got further than a rough implementation.