hey thats pretty nice!!
much nicer than my poor gem attempt last month...
and the patch: put this to / because of the bug in pix_write to make it work. put a folder called "frames" beside it.
yeah this is weird huh?
--- On Sat, 3/28/09, Max abonnements@revolwear.com wrote:
From: Max abonnements@revolwear.com Subject: [PD] GEM pix_write bugs (timelapse) To: pd-list@iem.at Date: Saturday, March 28, 2009, 12:52 PM 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:
- pix_write doesn't interpret the file path correctly. it
seems it can't understand relative paths at all.
- 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.
- 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 -----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
here is the same thing with pix_multiimage instead. it will crash pd a little bit later than the version with pix_image.
Am 30.03.2009 um 18:50 schrieb mark edward grimm:
hey thats pretty nice!!
much nicer than my poor gem attempt last month...
and the patch: put this to / because of the bug in pix_write to make it work. put a folder called "frames" beside it.
yeah this is weird huh?
--- On Sat, 3/28/09, Max abonnements@revolwear.com wrote:
From: Max abonnements@revolwear.com Subject: [PD] GEM pix_write bugs (timelapse) To: pd-list@iem.at Date: Saturday, March 28, 2009, 12:52 PM 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:
- pix_write doesn't interpret the file path correctly. it
seems it can't understand relative paths at all.
- 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.
- 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 -----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Max wrote:
here is the same thing with pix_multiimage instead. it will crash pd a little bit later than the version with pix_image.
i guess it is crashing right after you try loading 1000000 images (or so) into RAM. what do you expect? (if you look carefully, you might also notice that [pix_write] gradually fills up your harddisk. this is no bug either ;-))
or am i missing something obvious (it seems so, as i cannot reproduce the memleak you report with [pix_image] either).
fmgas.dr. IOhannes
IOhannes m zmoelnig wrote:
Max wrote:
here is the same thing with pix_multiimage instead. it will crash pd a little bit later than the version with pix_image.
i guess it is crashing right after you try loading 1000000 images (or so) into RAM. what do you expect? (if you look carefully, you might also notice that [pix_write] gradually fills up your harddisk. this is no bug either ;-))
or am i missing something obvious (it seems so, as i cannot reproduce the memleak you report with [pix_image] either).
despite of my sarcasm: have you considered using [pix_buffer] rather than [pix_multiimage]; it is way more flexible. (e.g. if all the images can fit into ram, you don't even need a harddisk)
fgamsrd IOhannes
Am 01.04.2009 um 16:45 schrieb IOhannes m zmoelnig:
despite of my sarcasm: have you considered using [pix_buffer] rather
than [pix_multiimage]; it is way more flexible. (e.g. if all the images can fit into ram, you don't even need a
harddisk)
thanks for the hint, i'll try it out.
m.
Am 01.04.2009 um 15:14 schrieb IOhannes m zmoelnig:
Max wrote:
here is the same thing with pix_multiimage instead. it will crash pd a little bit later than the version with pix_image.
i guess it is crashing right after you try loading 1000000 images
(or so) into RAM. what do you expect?
no it isn't the problem of a sequence wich is too long. it is the
problem that the old sequence doesn't get erased from the ram.
(if you look carefully, you might also notice that [pix_write]
gradually fills up your harddisk. this is no bug either ;-))
that aint a problem either.
or am i missing something obvious (it seems so, as i cannot
reproduce the memleak you report with [pix_image] either).
well, obviously you are missing something. i hope someone can
reproduce that with the attached patches.
run top to see the memory beeing eaten by pd. at least on os x with
GEM: ver: 0.91.3 'tigital'
GEM: compiled: Feb 23 2009
Max wrote:
or am i missing something obvious (it seems so, as i cannot reproduce the memleak you report with [pix_image] either).
well, obviously you are missing something. i hope someone can reproduce that with the attached patches. run top to see the memory beeing eaten by pd. at least on os x with GEM: ver: 0.91.3 'tigital' GEM: compiled: Feb 23 2009
this is exactly what i have been doing on linux (and Pd's memory consumption stayed at 1.7% for the first 15000 frames). so the problem is most likely os-x related. still it would be nice to have a bit more info; e.g. how long do i have to wait before the crash is likely to occur (this is obviously related to the amout of memory; but since i don't want to spend 3 days waiting because only a few bytes are leaking rather than the entire image, it would be nice to know the number (and size) of frames you are using on your machine equipped with how many kilobytes of ram)
fgmard IOhannes
mark edward grimm wrote:
hey thats pretty nice!!
much nicer than my poor gem attempt last month...
and the patch: put this to / because of the bug in pix_write to make it work. put a folder called "frames" beside it.
yeah this is weird huh?
no it's not weird. it's a known issue of Pd on OSX ("fixed" in Pd-extended, afair) where Pd get's started in the / directory. all relative paths are thus relative to the root and not to your home-directory, nor the patch-directory nor to your mailbox).
to make your demo-patch more portable (and not clutter the /) you could have used /tmp/ instead of /frames/; /tmp/ is available (and writeable) on all good and nice un*ces.
fgafmrt IOhannes
Am 01.04.2009 um 15:10 schrieb IOhannes m zmoelnig:
mark edward grimm wrote:
hey thats pretty nice!! much nicer than my poor gem attempt last month...
and the patch: put this to / because of the bug in pix_write to make it work. put a folder called "frames" beside it.
yeah this is weird huh?
no it's not weird. it's a known issue of Pd on OSX ("fixed" in Pd- extended, afair) where Pd get's started in the / directory. all
relative paths are thus relative to the root and not to your home- directory, nor the patch-directory nor to your mailbox).
no. relative paths work fine with pix_film and others. it's a problem
of pix_write.
Max wrote:
Am 01.04.2009 um 15:10 schrieb IOhannes m zmoelnig:
no it's not weird. it's a known issue of Pd on OSX ("fixed" in Pd-extended, afair) where Pd get's started in the / directory. all relative paths are thus relative to the root and not to your home-directory, nor the patch-directory nor to your mailbox).
no. relative paths work fine with pix_film and others. it's a problem of pix_write.
this is still not weird. the difference between pix_film and pix_write is, that the former _reads_ a file from harddisk while the latter _writes_ one to harddisk. reading may involve searching for the file (e.g. Pd can try to evaluate your path specification in realtion to ., /, extra/, /home/max, Maildir:/inbox and http://puredata.info/; you can watch this by specifying the "-verbose" flag).
things are a bit more complicated (or simple) when you want to write a file. should Pd search for an already existing file of the specified name and overwrite it? or find the first path that does not contain a file that matches your specs? or should it try to separate your specs into a "path" and a "filename" portion and try to match the "path"? or(and should it create a directory if the path does not exist? or should it just resolve any relative specs in relation to it's working dir?
the nicest approach would probably be the one trying to match the path.
however, currently most (if not all) file-writing objects use the last mentioned approach. on osx the working-dir with Pd-vanilla (and older versions of Pd-extended) is /, with newer Pd-extended it is ${HOME}; on w32 it is (iirc) ./pd/bin (by default, but you can change this easily); on linux it is wherever you start Pd from (if you start it from the console).
fmgasdr IOhannes
-
IOhannes m zmoelnig -
mark edward grimm -
Max