Hi all, I currently have a large video piece setup using pd+Gem with several complex sections which follow one another. After about 20 minutes into the performance, pd starts becoming unstable, and the solution I've currently implemented is to split the performance in two sections, closing pd, and opening then the second section. (By unstable I mean that sometimes it crashes, and sometimes it continues, but very sluggish and unusable) It seems to me that the culprits might be [pix_film] and [pix_movie]. I'm using these objects a lot, and when the performance has run, and I close pd, it exits with an error, and the only object left on the canvas is the subpatch that includes these objects. So I have these questions: -Has anyone experienced similar behaviour in large complex patches with separate sections? -Is there a message that can be sent to [pix_film] and [pix_movie] that 'frees' these objects? -Are there programming practices that should be avoided when building large patches?
Cheers, Andres
pd. I'm not posting the patch since it is very large and convoluted, and the problems don't occur with small patches. I'm running pd 0.37-1 and gem 0.888pre1 on Windows XP.
Andres Cabrera wrote:
gem 0.888pre1 on Windows XP.
i cannot help you right now, but how about upgrading to gem-0.90.1 ?
mfg.asd.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
gem 0.888pre1 on Windows XP.
i cannot help you right now, but how about upgrading to gem-0.90.1 ?
If my experience is anything to go by, [pix_movie] and [pix_film] are pretty broken in new versions of gem for windows. pd crashes when I try to load my own avi files.
Cheers, Peter
IOhannes,
Following your suggestion, I tried 0.90.1, but I've found a change in behaviour of pix_coordinate. In previous versions, the coordinates were normalized, however in 0.90.1, these seem to be related to absoulte positions of the texture. (This is on windows XP) Can you confirm?
Cheers, Andres
gem 0.888pre1 on Windows XP.
i cannot help you right now, but how about upgrading to gem-0.90.1 ?
mfg.asd.r IOhannes
Andres Cabrera wrote:
IOhannes,
Following your suggestion, I tried 0.90.1, but I've found a change in behaviour of pix_coordinate. In previous versions, the coordinates were normalized, however in 0.90.1, these seem to be related to absoulte positions of the texture. (This is on windows XP) Can you confirm?
not 100% true but: since gem-0.90.1 gem tries to use rectangle-textures for texturing (for some reasons - probably consistency - it tries to use rectangle textures for 2^n-textures by default too) if the gfx-card supports it.
unfortunately, when using rectangle-textures, you do not work with normalized texture-coordinates but with absolute ones (which i think is non-sense, but that is just the way it is);
you could switch rectangle-texturing off by sending a [mode 0( to [pix_texture]
mfg.a.sdr IOhannes
Hi IOhannes,
That's very good information! I hadn't updated my help files (that information is in the new help files), so that information was not available for me. I'll check when I boot windows again...
Thanks, Andrés
IOhannes m zmoelnig wrote: Andres Cabrera wrote:
IOhannes,
Following your suggestion, I tried 0.90.1, but I've found a change in behaviour of pix_coordinate. In previous versions, the coordinates were normalized, however in 0.90.1, these seem to be related to absoulte positions of the texture. (This is on windows XP) Can you confirm?
not 100% true but: since gem-0.90.1 gem tries to use rectangle-textures for texturing (for some reasons - probably consistency - it tries to use rectangle textures for 2^n-textures by default too) if the gfx-card supports it.
unfortunately, when using rectangle-textures, you do not work with normalized texture-coordinates but with absolute ones (which i think is non-sense, but that is just the way it is);
you could switch rectangle-texturing off by sending a [mode 0( to [pix_texture]
mfg.a.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
Andres Cabrera -
IOhannes m zmoelnig -
Peter Todd