Fluxus is designed for realtime use, this means interactive performance or games mainly, but you can also use the frame dump commands to save out frames which can be converted to movies. This process can be fairly complex, involving syncing to audio, osc or keyboard input.
Used alone, frame dumping will simply save out frames as fast as your machine can render and save them to disk. This is useful in some cases, but not if we want to create a movie at a fixed framerate, but with the same timing as they are generated at - ie synced with an audio track at 25fps.
The (process) command does several things, it switches the audio from the jack input source to a file, but it also makes sure that every buffer of audio is used to produce exactly one frame. Usually in realtime operation, audio buffers will be skipped or duplicated, depending on the variable framerate and fixed audio rate.
So, what this actually means is that if we want to produce video at 25fps, with audio at 44100 samplerate, 44100/25 = 1764 audio samples per frame. Set your jack and (start-audio) buffer settings to this. Then all you need to do is make sure the calls to (process) and (start-framedump) happen on the same frame, so that the first frame is at the start of the audio. As this process is not realtime, you can set your resolution as large as you want, or make the framerate as slow as you like.
If you also want to use this technique for re-rendering animations which involve keyboard presses or OSC input, things are a little more involved. Fluxus contains a recorder for these inputs, which is not exactly easy to use, (ok, I'll admit it was a crazy hack :)) but I've used it quite a lot and it seems to work fine.
What it actually does is record the time of every keypress or OSC message, so it can replay them at different framerates correctly.
It also works with the process command in the same way as the audio does (you always need an audio track, even if it's silence). So the recorder will advance the number of seconds per frame as it renders, rather than using the realtime clock - so again, you can make the rendering as slow as you like, it will appear correct when you view the movie.
So to give it a try, press F6 until "recording" is printed in the terminal window, type some keys, hit F7 to stop, delete the text, and press F6 again to select "playing". Hit F8 to reset the timer, which will then magically recreate the text you just entered.
As I said, it's not exactly obvious, but I ran out of F keys to use... I will change it at some point to be a little more friendly, ie change the colour of the cursor to indicate the mode.
You can save this recording out to a file, with (save-code "filename") and reload it with (load-code "filename"). The files are ascii format, and contain the timestamps and the information to recreate the key presses. They are not scheme files.
If you are using fluxus to recieve osc information, the details of the messages will also be stored in this file for later use. When playing back a recording, the osc interface treats the recorded messages the same as normal ones, so your script doesn't need to be modified to pick them up.
It's easier to set up if you start your script from an empty workspace - ie start the recording with the (edit "myscript.scm") or write a script from scratch. Play with fluxus as you normally would, move the camera around, change bits of the script, etc. Then, after saving out the code, you can then use a little startup script which does the following:
(start-audio "" 1764 44100)
(load-code "codefile")
(process "audiofile")
(start-framedump "outputframes" "jpg")
Then select all the code, hit F5 to run it, delete to remove it, F6 to start the playback and F8 to reset the recorder time. Then, if everything has worked out the recorder will type out (edit "myscript.scm") and run it, saving frames out at a fixed framerate.
Getting the syncing right when combining audio/keyboard and OSC input can be a bit tricky. Some common problems I've seen with the resulting movies fall into two categories.
The call to (start-audio) has the wrong buffer size. As I set this in my .fluxus.scm I often forget this. Set it correctly and re-render. Some lagging may happen unavoidably with really long (over 20 minutes or so) animations.
This happens when the start of the audio does not quite match the first frame. You can try adding or removing some silence at the beginning of the audio track to sort this out. I often just encode the first couple of seconds until I get it right.