---------- Forwarded message ----------
From:
stefan <stefanpiat@gmail.com>Date: 2009/4/25
Subject: Re: [PD] GEM pix_write bugs (timelapse)
To: Max <
abonnements@revolwear.com>
re-hallo
in fact I have the same eat-up-memory problem with pix_buffer...
(I have to quit pd to solve the problem.....)
Maybe u know an objet to refresh pd's memory?
s.
2009/4/25 stefan
<stefanpiat@gmail.com>
hallo!
I have no problem of file path with pix_write?
I observe the same problem with memory, I think it's a problem of pix_image & pix_multiimage ?
(both crash pd and I don't have to wait for a long time...)
I make some test with pix_buffer, but the problem is when you want to create buffer with loot of images....
and for that pix_image is cool because the frames dont stay in the memory (in theory? maybe this cause the crash?)
P.s: nice trick to control the pix_write index :)
p.p.s : I'm on Osx 10.5 using pd-0.41.4-extended-20090413
cheers
stéfan
2009/3/28 Max
<abonnements@revolwear.com>
hi list,
i've thrown together this tiny gem patch which makes a timelapse slideshow.
i have encountered a few issues with it.
configuration:
Pd version 0.41.4-extended-20090223
GEM: ver: 0.91.3 'tigital'
GEM: compiled: Feb 23 2009
OS X 10.5.6
the issues:
1. pix_write doesn't interpret the file path correctly. it seems it can't understand relative paths at all.
2. pix_write accepts a message [file <file> [<type>](. it creates files with a .jpg ending if the type is >0. But in reality it still is a TIFF. no matter what value you write.
3. pix_write creates files with an acending number 0...9999 this conflicts with how other objects like pix_multiimage do it (00000...99999)
just submitted that to the gem bugtracker.
and the patch:
put this to / because of the bug in pix_write to make it work. put a folder called "frames" beside it.
beware: this patch will also eat up all the memory and will crash pd. this isn't pix_writes problem though - i'll try to find out why this is now.
max