hello!
I'm working on a patch where I have to load multiple image to create an animation (I don't want to make a .mov file cause it's kind of real-time editing)
I tried with pix_image, pix_film, pix_buffer...
and with all of these objects (same if frames are looped or not) the used-memory increase until it crash pd... some people already had the same problem before:
http://lists.puredata.info/pipermail/pd-list/2004-10/023361.html http://lists.puredata.info/pipermail/pd-list/2009-03/069086.html http://lists.puredata.info/pipermail/pd-list/2006-09/042312.html
I was wondering if there is a way to fix this without having to restart pd? a way to unload the image which stays in memory?
I'm on Osx 10.5.6 - and use pd-extended compiled against Pd version 0.40.3.extended GEM: ver: 0.91.1 'tigital'
"and the patch : put this to / and put a folder called "frames" beside it."
thanks for your help... stefan
I usually load images in pix_buffer and from what i see monitoring RAM use it controls what is allocated, but perhaps someone else can confirm this.
j
On Mon, Apr 27, 2009 at 3:05 AM, stefan stefanpiat@gmail.com wrote:
hello!
I'm working on a patch where I have to load multiple image to create an animation (I don't want to make a .mov file cause it's kind of real-time editing)
I tried with pix_image, pix_film, pix_buffer...
and with all of these objects (same if frames are looped or not) the used-memory increase until it crash pd... some people already had the same problem before:
http://lists.puredata.info/pipermail/pd-list/2004-10/023361.html http://lists.puredata.info/pipermail/pd-list/2009-03/069086.html http://lists.puredata.info/pipermail/pd-list/2006-09/042312.html
I was wondering if there is a way to fix this without having to restart pd? a way to unload the image which stays in memory?
I'm on Osx 10.5.6 - and use pd-extended compiled against Pd version 0.40.3.extended GEM: ver: 0.91.1 'tigital'
"and the patch : put this to / and put a folder called "frames" beside it."
thanks for your help... stefan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
stefan wrote:
hello!
I'm working on a patch where I have to load multiple image to create an animation (I don't want to make a .mov file cause it's kind of real-time editing)
I tried with pix_image, pix_film, pix_buffer...
and with all of these objects (same if frames are looped or not) the used-memory increase until it crash pd... some people already had the same problem before:
http://lists.puredata.info/pipermail/pd-list/2004-10/023361.html http://lists.puredata.info/pipermail/pd-list/2009-03/069086.html http://lists.puredata.info/pipermail/pd-list/2006-09/042312.html
I was wondering if there is a way to fix this without having to restart pd? a way to unload the image which stays in memory?
first of all, this bug in Gem has been fixed in recent SVN (after your initial bug-report) the obvious solution is to run the hottest Gem (no release out, though; so you have to compile it yerself)
and since it is (was) a bug in the implementation of Gem, there is no way you can "fix" it in Pd. the only workaround is to restart Pd (which will free all stray memory). "unloading" does not work, because the memory had been lost.
"and the patch : put this to / and put a folder called "frames" beside it."
do not do that.
fgmadr IOhannes
thanks!
I will try to compile the "hottest" gem...
++ stéfan
2009/4/27 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
hello!
I'm working on a patch where I have to load multiple image to create an animation (I don't want to make a .mov file cause it's kind of real-time editing)
I tried with pix_image, pix_film, pix_buffer...
and with all of these objects (same if frames are looped or not) the used-memory increase until it crash pd... some people already had the same problem before:
http://lists.puredata.info/pipermail/pd-list/2004-10/023361.html http://lists.puredata.info/pipermail/pd-list/2009-03/069086.html http://lists.puredata.info/pipermail/pd-list/2006-09/042312.html
I was wondering if there is a way to fix this without having to restart pd? a way to unload the image which stays in memory?
first of all, this bug in Gem has been fixed in recent SVN (after your initial bug-report) the obvious solution is to run the hottest Gem (no release out, though; so you have to compile it yerself)
and since it is (was) a bug in the implementation of Gem, there is no way you can "fix" it in Pd. the only workaround is to restart Pd (which will free all stray memory). "unloading" does not work, because the memory had been lost.
"and the patch : put this to / and put a folder called "frames" beside
it."
do not do that.
fgmadr IOhannes
On Mon, Apr 27, 2009 at 6:27 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
first of all, this bug in Gem has been fixed in recent SVN (after your initial bug-report) the obvious solution is to run the hottest Gem (no release out, though; so you have to compile it yerself)
and since it is (was) a bug in the implementation of Gem, there is no way you can "fix" it in Pd. the only workaround is to restart Pd (which will free all stray memory). "unloading" does not work, because the memory had been lost.
Is this also bug with pix_film? I used pix_film for permanent installations to load hundreds of thousands of films over years without running into this problem. The same patch also had large pix_buffer objects that are stable in RAM usage.
yes, with pix_film too... (I load .jpg files into it) (and with pix_buffer too)
but maybe I'm wrong somewhere? I join patchs with pix_buffer and pix_film... (maybe you have to change file path to make it work)
is gem 0.91.3 the hottest Gem ?
thx. stéfan
2009/4/27 chris clepper cgclepper@gmail.com
On Mon, Apr 27, 2009 at 6:27 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
first of all, this bug in Gem has been fixed in recent SVN (after your initial bug-report) the obvious solution is to run the hottest Gem (no release out, though; so you have to compile it yerself)
and since it is (was) a bug in the implementation of Gem, there is no way you can "fix" it in Pd. the only workaround is to restart Pd (which will free all stray memory). "unloading" does not work, because the memory had been lost.
Is this also bug with pix_film? I used pix_film for permanent installations to load hundreds of thousands of films over years without running into this problem. The same patch also had large pix_buffer objects that are stable in RAM usage.
stefan wrote:
yes, with pix_film too... (I load .jpg files into it) (and with pix_buffer too)
but maybe I'm wrong somewhere? I join patchs with pix_buffer and pix_film... (maybe you have to change file path to make it work)
is gem 0.91.3 the hottest Gem ?
no, the hottest is: svn co https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem
however, if there is really something i [pix_film] there might be another fix (which has not yet been found...)
anyhow, trying the svn is certainly a start...
fgamsdr IOhannes
sorry but I don't understand how to use the svn... I can't find any explanations on the web
maybe you know a good link where I could learn the method to compile it for osX ?
thanks stéfan
2009/4/27 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
yes, with pix_film too... (I load .jpg files into it) (and with pix_buffer too)
but maybe I'm wrong somewhere? I join patchs with pix_buffer and pix_film... (maybe you have to change file path to make it work)
is gem 0.91.3 the hottest Gem ?
no, the hottest is: svn co https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem
however, if there is really something i [pix_film] there might be another fix (which has not yet been found...)
anyhow, trying the svn is certainly a start...
fgamsdr IOhannes
Hello Stefan,
If you've installed developer tools on your mac, then was installed
along with XCode and all the other goodies.. If you haven't installed
the package, I'd highly suggest it, there's some good stuff in there..
Once you've got developer tools installed, open a terminal, and
navigate to, and create the folder, where you want to put the source
code...
cd Documents
mkdir GemSource
cd GemSource
now download the source code off the svn: svn co https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem
you will know the checkout is complete when you see the line "Checked
out Revision xxxx". Now that you've got the sourcecode, head into
"Gem/build/osx-xcode" and open the Gem.xcodeproj. Now, once you're
looking at the project in XCode, you should be able to build it from
here, but i get ~90 errors.. maybe someone can offer advice as to
other required sources or anything
On Apr 27, 2009, at 10:02 AM, stefan wrote:
sorry but I don't understand how to use the svn... I can't find any explanations on the web
maybe you know a good link where I could learn the method to compile
it for osX ?thanks stéfan
2009/4/27 IOhannes m zmoelnig zmoelnig@iem.at stefan wrote: yes, with pix_film too... (I load .jpg files into it) (and with pix_buffer too)
but maybe I'm wrong somewhere? I join patchs with pix_buffer and pix_film... (maybe you have to change file path to make it work)
is gem 0.91.3 the hottest Gem ?
no, the hottest is: svn co https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem
however, if there is really something i [pix_film] there might be
another fix (which has not yet been found...)anyhow, trying the svn is certainly a start...
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Skye Book 516.816.4762
Skye Book wrote:
Hello Stefan,
you will know the checkout is complete when you see the line "Checked out Revision xxxx". Now that you've got the sourcecode, head into "Gem/build/osx-xcode" and open the Gem.xcodeproj. Now, once you're looking at the project in XCode, you should be able to build it from here, but i get ~90 errors.. maybe someone can offer advice as to other required sources or anything
any hints which errors you get? most likely you will have to install FTGL+freetype2 as well and fix the search-paths for these in the xcode-project.
the xcode-project works fine here (with everything installed in the right place of course)
fgasdmr IOhannes
I get =78 errors but I can't manage to use FTGL+freetype2...
s.
2009/4/27 IOhannes m zmoelnig zmoelnig@iem.at
Skye Book wrote:
Hello Stefan,
you will know the checkout is complete when you see the line "Checked out Revision xxxx". Now that you've got the sourcecode, head into "Gem/build/osx-xcode" and open the Gem.xcodeproj. Now, once you're looking at the project in XCode, you should be able to build it from here, but i get ~90 errors.. maybe someone can offer advice as to other required sources or anything
any hints which errors you get? most likely you will have to install FTGL+freetype2 as well and fix the search-paths for these in the xcode-project.
the xcode-project works fine here (with everything installed in the right place of course)
fgasdmr IOhannes
2009/4/28 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
I get =78 errors
better than 90 :-)
but I can't manage to use FTGL+freetype2...
do you need it?
not really, but maybe you need to know the errors I get?
are there any other errors you get?
I don't think so.. I always heve these 78 errors... and the build failed
fgamsdr IOhannes
stefan wrote:
2009/4/28 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
I get =78 errors
better than 90 :-)
but I can't manage to use FTGL+freetype2... do you need it?
not really, but maybe you need to know the errors I get?
well, if you want more than a generic answer: yes :-)
are there any other errors you get?
I don't think so..
it's simple: if you want text, you need it; else you don't...
I always heve these 78 errors... and the build failed
obviously, since they are "errors" (not "warnings")
fmsdr IOhannes
I don't succeed to use the hottest gem...
anyway I will explain some others things I observe about that bug... (using os X 10.5 + pd-0.41.4-extended-20090429)
with pix_film and .mov files there is no problem (but there is a problem with still images when pix_film is used as pix_image)
with pix_buffer, when the buffer is looped there is no problem
when I resize the buffer using [resize $1(
the used memory increase
if I resize to a buffer with less frames the used-memory decrease...but...
each times I resize pix_buffer there is a little bit less ram disponible..
hope this help
stefan
2009/4/28 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
2009/4/28 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
I get =78 errors
better than 90 :-)
but I can't manage to use FTGL+freetype2... do you need it?
not really, but maybe you need to know the errors I get?
well, if you want more than a generic answer: yes :-)
are there any other errors you get?
I don't think so..
it's simple: if you want text, you need it; else you don't...
I always heve these 78 errors... and the build failed
obviously, since they are "errors" (not "warnings")
fmsdr IOhannes
stefan wrote:
I don't succeed to use the hottest gem...
anyway I will explain some others things I observe about that bug... (using os X 10.5 + pd-0.41.4-extended-20090429)
with pix_film and .mov files there is no problem (but there is a problem with still images when pix_film is used as pix_image)
that is quite interesting, as i think that Gem is agnostic whether [pix_film] opens an image or a film: it just passes the request to QuickTime (which might then return a 1-frame "film")
with pix_buffer, when the buffer is looped there is no problem
when I resize the buffer using [resize $1(
the used memory increase
if I resize to a buffer with less frames the used-memory decrease...but...
each times I resize pix_buffer there is a little bit less ram disponible..
that's something else and more interesting (in terms of fixability) for me. could you please post an example patch that exposes this behaviour?
f dasrm IOhannes
here is the patch
++ s.
2009/4/30 IOhannes m zmoelnig zmoelnig@iem.at
stefan wrote:
I don't succeed to use the hottest gem...
anyway I will explain some others things I observe about that bug... (using os X 10.5 + pd-0.41.4-extended-20090429)
with pix_film and .mov files there is no problem (but there is a problem with still images when pix_film is used as pix_image)
that is quite interesting, as i think that Gem is agnostic whether [pix_film] opens an image or a film: it just passes the request to QuickTime (which might then return a 1-frame "film")
with pix_buffer, when the buffer is looped there is no problem
when I resize the buffer using [resize $1(
the used memory increase
if I resize to a buffer with less frames the used-memory decrease...but...
each times I resize pix_buffer there is a little bit less ram disponible..
that's something else and more interesting (in terms of fixability) for me. could you please post an example patch that exposes this behaviour?
f dasrm IOhannes
On Thu, Apr 30, 2009 at 7:24 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
stefan wrote:
I don't succeed to use the hottest gem...
anyway I will explain some others things I observe about that bug... (using os X 10.5 + pd-0.41.4-extended-20090429)
with pix_film and .mov files there is no problem (but there is a problem with still images when pix_film is used as pix_image)
that is quite interesting, as i think that Gem is agnostic whether [pix_film] opens an image or a film: it just passes the request to QuickTime (which might then return a 1-frame "film")
Yes, the code just opens any file Quicktime recognizes and loads it. This looks like a Quicktime bug.
-
chris clepper -
IOhannes m zmoelnig -
Jaime Oliver -
Skye Book -
stefan