Zitiere IOhannes m zm?lnig zmoelnig@users.sourceforge.net:
Update of /cvsroot/pd-gem/Gem/src/Base In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30297
Modified Files: GemCache.cpp GemCache.h Log Message: added a reset()-method to re-set an instance without having to destroy and re-create it (see [gemhead])
hi. while i have changed the [gemhead]'s behaviour with handling the GemCache only because it crashed once(!) on my machine while debugging (and i have no idea, why), it seems that this has also fixed the crash-problem that was reported by beau (e.g: "sending messages to gem-objects while rendering is turned off and then moving the mouse while rendering is started" crashes pd.)
to be honest: i really have no idea why: memory was deleted and allocated allright, but sometimes it just crashed (either in the "new" for GemCache or while "malloc"ating memory for pd's binbuf_text).
anyhow i don't understand, why the GemCache had to be destroyed and re-instantiated every time the rendering was turned on.
ok. probably this fixes the "pressing Ctrl while turning rendering on and going for a loo"-crash (sorry, forgot the original bug-report text and my old emails are not at hand) too.
mfg.a.sdr IOhannes
zmoelnig@iem.at wrote:
Zitiere IOhannes m zm?lnig zmoelnig@users.sourceforge.net:
Update of /cvsroot/pd-gem/Gem/src/Base In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30297
Modified Files: GemCache.cpp GemCache.h Log Message: added a reset()-method to re-set an instance without having to destroy and re-create it (see [gemhead])
and then i changed the code a bit to enable [gemhead]s to be created on the fly and immediately start rendering (without having to restart it manually by sending [0,1( to the [gemwin])
anyhow, this (and the prior changes to the GemCache) created a bunch of other mis-behaviour but i finally got an idea what made Gem crashing when objects where modified (e.g: sending floats to [rotate]) while rendering was turned off: all the objects hold local copies of the pointer to the GemCache. AND they modify the GemCache with setModified().
so i added a magic-number to the GemCache to ensure that the pointer is still valid. (and accordingly changed all the involved objects)
so i hope this issue is really fixed for now. any tests ?
mfg.as.dra IOhannes
On Mar 25, 2004, at 11:40 AM, IOhannes m zmoelnig wrote:
and then i changed the code a bit to enable [gemhead]s to be created on the fly and immediately start rendering (without having to restart it manually by sending [0,1( to the [gemwin])
anyhow, this (and the prior changes to the GemCache) created a bunch of other mis-behaviour but i finally got an idea what made Gem crashing when objects where modified (e.g: sending floats to [rotate]) while rendering was turned off: all the objects hold local copies of the pointer to the GemCache. AND they modify the GemCache with setModified().
so i added a magic-number to the GemCache to ensure that the pointer is still valid. (and accordingly changed all the involved objects)
so i hope this issue is really fixed for now. any tests ?
This magically cured the random crash on OSX deep inside the OS window destruction routines. Why the hell this worked I have no clue.
The only thing I've found broken now is that stopping then starting rendering turns off all of the pix_ objects. I put m_processOnOff = 1; in the startRendering() in GemPixObj, but that didn't seem to work. I couldn't find any explicit setting of this beyond the constructor arguments anywhere else in GEM. Any ideas?
cgc
mfg.as.dra IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Zitiere chris clepper cgc@humboldtblvd.com:
On Mar 25, 2004, at 11:40 AM, IOhannes m zmoelnig wrote:
any tests ?
This magically cured the random crash on OSX deep inside the OS window destruction routines. Why the hell this worked I have no clue.
good to hear. basically it was just about using freed memory, which naturally leads to random crashes.
The only thing I've found broken now is that stopping then starting rendering turns off all of the pix_ objects. I put m_processOnOff = 1;
in the startRendering() in GemPixObj, but that didn't seem to work. I
couldn't find any explicit setting of this beyond the constructor arguments anywhere else in GEM. Any ideas?
i just tried and it seems to work for me (on linux): tried [pix_rtx] (with [pix_video]), [pix_rds], [pix_aging] and [pix_halftone] (with [pix_image]) to set the m_processOnOff when turning rendering on does *not* seem to be a good idea, as it is the On/Off flag for the pix-fx (e.g.: you can turn off an effect by sending a 0 to the leftmost inlet) as is defined in the floatMessCallback of GemPixObj.
furthermore i don't think that the problem is hidden in the m_processOnOff (who would turn it off ?); the only changes that have been made, effected the m_cache (resp: m_rightCache) so probably we should look for the bug in there.
could you send (or mention) a patch that does not work ?
mfga.sdr. IOhannes
chris clepper wrote:
On Mar 25, 2004, at 11:40 AM, IOhannes m zmoelnig wrote:
This magically cured the random crash on OSX deep inside the OS window destruction routines. Why the hell this worked I have no clue.
The only thing I've found broken now is that stopping then starting rendering turns off all of the pix_ objects. I put m_processOnOff = 1; in the startRendering() in GemPixObj, but that didn't seem to work. I couldn't find any explicit setting of this beyond the constructor arguments anywhere else in GEM. Any ideas?
i compiled Gem today for windows and macOS and everything seems to work (apart from the YUV-texturing on our G4...(we've talked about this already))
so what is on the TODO-list ? ....releasing ?
mfg.a.sdr IOhannes
ps: i have checked a lot of things in and out of the cvs, mostly the .pd-files have all become binaries. some more documentation added (i noticed that the [pix_chroma_key] still takes values between 0..255; shouldn't this change before the release ? and i have removed some unneeded variables to keep mac's gcc silent.
On Mar 29, 2004, at 2:13 PM, IOhannes m zmoelnig wrote:
i compiled Gem today for windows and macOS and everything seems to work (apart from the YUV-texturing on our G4...(we've talked about this already))
so what is on the TODO-list ? ....releasing ?
...yeh, maybe so! I still need to make a help patch for [camera]...also, wasn't there a problem with text3d? In any event, I've been having fun actually playing with the damn thing the last few days...I think we might wanna include some more examples of the OpenGL wrapper, or at least kinda go through and figure out what is known to actually work ;-)
ps: i have checked a lot of things in and out of the cvs, mostly the .pd-files have all become binaries. some more documentation added (i noticed that the [pix_chroma_key] still takes values between 0..255; shouldn't this change before the release ? and i have removed some unneeded variables to keep mac's gcc silent.
...I've got a few more of these to file later today, too...I thought .pd files were text?
jamie
Zitiere James Tittle II tigital@mac.com:
On Mar 29, 2004, at 2:13 PM, IOhannes m zmoelnig wrote:
[camera]...also, wasn't there a problem with text3d? In any event,
which problem ? i know chris has mentioned [text] not to work after my pre-latest check-ins but i tried on all three platforms and indeed they worked like anything.
.pd-files have all become binaries. some more documentation added (i
...I've got a few more of these to file later today, too...I thought .pd files were text?
that's the question. of course, pd files *are* text-files. but if two concurrent versions are merged the result will not be usable at all. and it is not fun to go through a dis-merged pd-file by hand - so i consider them rather binaries than text files (if they were more structured, like XML, they would definitely be text)
mfg.ar.d IOhannes
On Mar 30, 2004, at 1:11 AM, zmoelnig@iem.at wrote
which problem ? i know chris has mentioned [text] not to work after my pre-latest check-ins but i tried on all three platforms and indeed they worked like anything.
Yep, all is well here too. I apparently had some old stuff cached in the build somewhere causing problems. Starting with a fresh checkout solved everything.
cgc
-
chris clepper -
IOhannes m zmoelnig -
James Tittle II -
zmoelnig＠iem.at