temporary.cc is a marvellously concise piece of netart by prolific openFrameworks contributor Zach Gage. Each unique visitor causes a single fragment of the page's HTML to be deleted, resulting in an irreversibly degenerative piece of online space. Each visit is inevitably further decayed than the last, and any attempts to archive or document are futile.

Reminds me of Feliz Gonzales-Torres' beautiful candy-pile pieces, though with very different conceptual intent.

edit: Alex kindly pointed me at Dust, a projected created by Geoff Cox way back in 2000 which applied the same idea to a digital image. Particularly striking right after a conversation we'd been having about art and the fallacies of originality.

As a digital artist working with motion graphics, it's vital to have some method of recording high-quality videos of work for posterity - as a primary form of documentation, and an engaging way to disseminate work for feedback on Vimeo feeds and the like. Processing has recently incorporated the MovieMaker frame-by-frame video recording library into its core, and OS X Snow Leopard has introduced full-screen movie recording via QuickTime X. The shareware Snapz Pro has also provided OS X users with flexible movie recordings since the dawn of time.

So, a solved problem? Not quite. For artists and filmmakers working with CPU-heavy real-time interactive A/V work, each of these approaches has a critical flaw. Screencast tools such as Snapz Pro and QuickTime X have CPU and GPU requirements such that they can drop frames under heavy strain; moreover, QuickTime X's capture seems to be limited at around 10 frames per second, insufficient to demonstrate the whizziness of graphical fireworks. MovieMaker and other internal frame-by-frame grabbers, conversely, won't ever miss a frame, but their encoding process can slow down the framerate of the sketch itself beyond acceptable levels, which is lethal when dealing with real-time interactivity and synchronized audio/video streams.

Up until recently, I've been combating this by connecting a video camera via a Firewire/DV connection, taping the video, then capturing it back to computer (in real-time) before overdubbing the audio and compressing. Functional, but too much hassle to do regularly.

However, there is a better approach. The bad news? it's OS X only, and requires a second Mac for the recording...

A Solution: Virtual DV over Firewire

So, here it is: DV screencasting through Firewire. By rigging up some freely-available software on two Macs, connected by Firewire, it's possible to simulate the DV camera method and record the video output straight into QuickTime X (or Final Cut Pro, etc). Minimal overheads, no framerate or quality loss, straight into a digital video file ready for upload.

I gave it a shot with my personal laptop wired up to an office Mac Mini (running Snow Leopard and Leopard respectively), shooting out 1024x768px video from a Processing sketch that completely saturated the host's CPU and GPU - and lo, out came a 30FPS .mov.

Notes and caveats:

• the Firewire data transmission is video-only, so you'll either want to use a 3.5mm jack lead to send your audio output to the recording computer's input, or overdub your audio afterwards (using Soundflower or suchlike to record the host computer's output).
• Note that the QuartzComposerLiveDV process should be running on the host computer (ie, not the one doing the recording). I didn't, and encountered much confusion. Also be aware that the VirtualDV instances should be left in their paused state, and not switched to "play".
• This technique works under Leopard and Snow Leopard, but reportedly not on Tiger.

Here's the video in its re-recording form; compare to the original, created using Snapz Pro and suffering from a low framerate. Sadly, Vimeo's encoding has not been favourable towards it (compare with original .mov); next time, I will see how an .mp4 works out.

My iPhone Developer License materialized this morning. After a final resentful mutter about the inherent unpleasantness of being asked to pay to develop for a third-party platform, I starting hacking up the #hackpact day 1 OpenFrameworks code to communicate over OSC with SuperCollider - creating a bouncing, throwable and tippable particle system which remotely generates sound effects as particles collide. Latency is low, render rate is high, and it kind of feels like the ADC price tag is already justified. Principles, shminciples.

tech notes: as mentioned in the openframeworks forums, it's necessary to download the oscpack source and replace the headers+library in the openFrameworks distribution with a fresh code tree, which is then compiled afresh for the iPhone ARM architecture. A couple of lines relating to the 'Nil' constant also need commenting out.