What's better than graph paper? Of course, it's a tool to grow your own printable graph paper, sufficiently configurable to cater for the wildly divergent graph-paper needs of our times.

This Processing sketch (PDE) will generate single-weight, multi-weight and cross-grid graph paper in PDF format, with configurable weights and colours, support for metric and imperial measures, and control over margins and paper sizing. Unsupported, but should be simple to modify.

A short sound study in the structure of the number sequence. Each positive integer is broken down into its prime factors, with each factor corresponding to a harmonic partial. We then proceed to count upwards, for each integer only playing those harmonics which correspond to its factors.

More info and full source code (Processing, SuperCollider) available on the Prime Composition project page (coming very shortly).

As regular visitors will be aware, I am strongly in favour of a nonlinear approach to musical composition: organising sounds in space via models of nondeterministic systems and processes, such as AtomSwarm's flocking ecosystem, The Fragmented Orchestra's soundscape neural-net, and some more recent experiments in self-organized sound (more to be published very soon).

I'm co-ordinating a workshop on such topics next Thursday (15th October) at London's Space Studios, part of OpenLab Workshops's Fall 2009 series. It presupposes basic working knowledge of Processing or Java; some experience of SuperCollider would also be useful but inessential.

Here's the blurb:

Simulating and Sonifying Natural Systems

An increasingly popular practice in digital arts is creating sonic representations of dynamical systems -- simulating natural phenomena such as insect swarms, tree growth, wind turbulence and neural networks, and translating such phenomena into sound, to create organic, dynamic audio-visual works.

Working from a basic knowledge of the Java-based Processing environment, Daniel Jones explains how to create such a simulation and subsequently connect it to the open-source SuperCollider synthesis engine, providing a valuable addition to a digital artist's toolkit.

6pm, £10 entry (or £15 also including the following Arduino Basics workshop), at:

Space Studios, 129 – 131 Mare St, Hackney E8 3RH.

Nearest transport: Bethnal Green (tube), London Fields (Overground), Buses – see http://www.spacestudios.org.uk/contact/SPACE/

..and here's the rest of the season's programme.

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.

So, it's the last day of the month-long hackpact that has motivated the almost-daily posts here for the past 30 days. Many have been missed, many have been lame, but it was an enjoyable process and triggered a lot of mini-works that wouldn't have come about otherwise.

The final hack is a relatively grand one, though still a work-in-progress: to celebrate the newfound power of my freshly upgraded computer and its Geforce 9600M GT, a million-particle snowstorm, whipping around the screen at 60fps and gratuitously mapped onto a sphere for good measure. The low framerate Vimeo capture unfortunately doesn't do it justice, but I'm still seeking a more satisfying method of capturing motion graphics from OS X.

Another Processing hack following a tweet by Marius Watz: little borderless windows flying around the screen. At least on OS X, the slowdown is sufficient that it begins to creak to a halt with more than a handful, but fun (if essentially useless) sketch.

Another small Processing class developed for Peal, ColourFader takes an array of colour values and smoothly interpolates between them through a series of calls to its get() method.

This is intended for the Peal visualization's idle mode, which acts as a kind of screensaver, drifting from side to side and cycling through its internal colour scheme. It's sorely tempting to include some kind of hidden disco-lighting easter egg...

An absence from technology turned out to be less amenable to hacking than hoped; even with the presence of an iPhone, concocting half-baked hacks to twitpic from a Dorset field was less appealing in practice than in theory. Apologies, therefore, for the break in hackpact programming. Service hereby resumes.

Today's hack is a small Processing sketch to simulate objects moving around on a spring-like arc around a central point. It's a simple implementation of Hooke's law plus trigonometry, but creates pleasantly natural-looking dynamics which are useful, in my case, to spin camera angles around a point with some damping.

This is more rapid work-in-progress for PEAL, appearing at the Sonic Arts Expo in Leeds very shortly.

Continuing the PEAL-related hackpact hacking, today saw the realization of the OSC protocol that the installation will use to communicate with the Processing visualization. As a testbed, this also entailed a Python script (making use of ixi's great simpleosc) to emulate the behaviour of the installation when it's in place - generating events such as clock ticks, bell chimes and aleatoric changes.

Coming from recent work in C++ and perl, it's continually surprising how things in python seem to just work - and moreover, how readable and maintainable the resulting code is. I saw a comment by somebody recently describing Perl as a "read only" language, which can be pretty on the money...

I'm out in the country for the next few days, mostly away from technology, so the next few hackpact entries will be manual hacks, broadcast via iPhone twitpics/twitvids - if signal reception permits.

For this year's Sound And Music Expo, taking place imminently in Leeds, I'm developing the interactive visual elements for Peal, a virtual bell tower realized with lasers, LEDs, surround sound and projection. Lewis and Nick of Monomatic have asked me to transform Malcolm Garrett's vector-based design work into a responsive application that somehow ties together the various elements of bellringing (time, communality, musicality, circularity) into an animated projection, reflecting the current state of the virtual bells as well as providing live scores to established sets of changes.

Lots of concepts to take on board, not least dealing with scalable vector graphics (SVG) in Processing, which is what I've been doing today. The idea is that the application is multi-modal -- switching between contexts based a combination of the time of day and the signalling from the electronics that make up the physical part of the installation -- and so must be able to fade gracefully between different display states.

I might well shoe-horn at least one more Peal-related dev session into the hackpact.