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.

I've been trying to step up my coding game by moving from vim and Processing's straightforward interface to the Eclipse IDE. Having followed the comprehensive Processing in Eclipse howto, the advantages have immediately been manifold: brilliant code refactoring tools, nice javadoc-generation functions, an inbuilt debugger, and svn version control integration with Subclipse.

Best of all, however, was stumbling across this guide to Java code profiling with Shark. The agent component of Eclipse's Test and Performance Tools is sadly unsupported on OS X, but this solution - using part of Apple's free Developer Tools - fits the bill perfectly. Just got an instant breakdown of the execution bottlenecks of my current Processing app, and am well on the way to a turbocharged speed boost...

Cmd-Shift-B.
Amazing.

It's rare for me to envy Windows users, but I have a long-harboured jealousy of the unofficial Python API for Ableton Live that's been available for the past year or so -- as I'm sure the reader would agree, there's little in life that could rival programmatical access to arguably the world's greatest DAW. So, it was to my joy that I discovered that an OS X version of this API was quietly announced just a few days ago, coinciding with me delving back into Python for an ongoing project.

Expect some monstrous hacks as soon as I have a free moment...