Ulrich Kehrer wrote:
hy bernard, list
since ulrich is the only one i know, who has used pix_write (without hacking the source, i guess ??), maybe holds more truth than mine. i used pix_write a week ago, and i hacked it to make it run...
pix_write has to be the last object of the gem-list (for example you have to connect the OUTLET of a cube object to the inlet of pix_write)
this should not be true; you can use pix_write in it's own gemlist, but you should make sure, that this list is rendered *after* all the other lists, you want to be on the frameshot.
the snapshots will be saved in the pd/bin directory with successive numbers as tif files (gemmgem100000.tif). i didn't find out yet how to tell pix_write a costum place to save the tiffs and how to change the default name and the starting number. ...johannes?
in theory, you can just call it with "write <my_custom_path_and_nameprefix>" or, alternatively (and i do not know right now whether they work together) "auto <my_custom_path_and_nameprefix>". calling with "auto" should reset the counter.
with a "metro 40" banging pix_write i grabbed a few seconds with 720x576px at 25fps. it was a patch with 9 cubes spinning around and i noticed that pd/gem waited with the action until a snapshot was written to disk. the 5 seconds i "recorded" took about 30 seconds to be saved. i then got a 125 frame tiff-sequence with a smooth movement just like in the gemwin. that's cool! can anyone explain this behavior?
not that cool, i would say.... "bang" does not immediatly save the current frame to disk; instead the next time, things are rendered, the snapshot is taken and saved.
by the way, what videocard are you using ? do you have a slow harddisk ? when i was recording 20secs of full PAL-resolution in "auto"-mode, i had no speed-problems at all.
mfg.-cd.asdr IOhannes