if it sends osc messages to supercollider to generate sound i think it has to run in real time. how does that go with saving images in "not real time" ? 

with screen size(768,576); sending messages to supercollider goes smooth
problems start when i saveFrames and i also need to record that audio
so you think screen capture is the way to go?
i am on ubuntu studio 12.04

if you also need to record audio, i definitely recommend screen capturing. don't know much about linux alternatives though.

ok, thank you, i will test http://recordmydesktop.sourceforge.net/about.php for screen capture
nevertheless i am still interested how to render offline in processing
is it possible to save frames in non real time way?

again, what is offline rendering?

ok, so no matter how badly real time thing hangs while saving frames the saved sequence will be correct
good to know that

The only difference is in how you would handle time dependent animations.

For online rendering:

void draw() {
   float time = millis() / 1000.0f;
   drawGraphics(time);
}

For offline rendering:

int frameCount = 0;
float fps = 30.0f;

void draw() {
   float time = frameCount / fps;
   drawGraphics(time);
   saveFrameToFile(frameCount);
}

true. if your animations are based on millis() they will appear much faster in the final animation.

Once I worked around this by saving all data needed to draw each frame to memory instead of to the disk, then later saving it to disk, like "rendering".I was grabbing video realtime, processing it and drawing weird pixels based on each pixel brightness . So first i "record" the data to an array of PVectors, (xPos, yPOs, brightness) and after the capture was done walked trough the array redrawing everything and saving it. It worked fine for me... Have I been  clear enough ?

Another approach is to do the rendering in two passes: one for video and one for audio. In the first pass you save all the video frames to disk while saving a text file that includes frame numbers of when events take place.

Then you write a SuperCollider program that reads that text file and plays the audio events with the correct timing, saving the result as an audio file. Finally you combine this audio file with the frames you got from processing.

As an example, imagine you want objects bouncing with each other on the screen, and each time the objects hit each other a sound is played. To achieve this you can write a Processing program that renders HD frames to disk on it's own pace. It doesn't matter how slow it is, even if the rendering happens at 1 FPS, you can later play the movie at 25 FPS. Each time there is a collision Processing writes the frame number to a text file.

When this process is done, you end up with a lot of images and a text file that describes on which frames exactly there should be sounds playing. If you plan on playing the final animation at 25 FPS, it means each frame will be shown during 40 milliseconds.

To keep the example simple, imagine there are just 3 collisions: at frame 7, 101 and 125. That means that you should play sounds at 7*40 = 280ms, 101*40 = 4040ms and 125*40 = 5000 ms after the movie begins. You can write a SuperCollider program that plays sounds at those precise moments and saves the whole composition to disk.

What's good about this approach is that you can do really complex stuff with 3D and thousands of objects, and an equally complex sound composition with audio effects, because the rendering in both cases will not happen in real time.

Note: to record the screen I use ffmpeg. That's how I recorded all the video episodes at Fun Programming. See: http://www.davidrevoy.com/article65/recordscreen-py-video-and-audio-capture-for-linux-with-ffmpeg#c1337164257-1

thank you i will try your suggestion
i could save just OSC messages in relation to frames and load it as some sort of score in SC
how about fun programming episode about this? :)

btw i use Open Object quark in SC for OSC , very good
(but in just one direction Processing-SC, other way around is still mystery to me..)


experimenting with ffmpeg settings now
my processing project has framRate 12, what frame rate i should use in ffmpeg when capturing?
tried different settings and it is always too slow or to fast
also i use jack for audio and capturing gives a lot of x runs

considering screen capturing in general...
isn't that just a workaround? can you achieve same quality as with rendering frames?
it can work for web stuff etc.
but is it appropriate for screening in gallery on big screen and stuff like that,
when you need maximum quality?
best, k

I think using ffmpeg to record your animation will always result in some dropped frames. The frame rate in Processing will most likely change over time, depending on the complexity and the sizes of the objects drawn. It can be good enough in some cases, but you have to test if the result is good enough for you. Sometimes using your smartphone to record your screen may be enough, in other cases you will want to save HD frames to disk to get the best quality.
It depends on the project. If perfection is not important you can show your work on old blurry TVs. In that case screen capturing is no problem.

I got rid of x runs by using a low latency kernel in Ubuntu 12.04. It dropped to zero. In some cases it can be a good option.

Sounds like an interesting topic for an episode :) In one month I'll probably be able to record new ones.

Cheers

a