Hi,
Usually at work I use GEM version gem-CVS20060412-NT-i686-bin, the only one that always worked for what I needed.
Now I am at home (where I didn't have gem) and have just downloaded an up-to-date CVS snapshot of 0.91 beta (dated 22 april). I've opened a patch that used to work on gem-CVS20060412-NT-i686-bin, and some things don't work, others behave differently... a chaos. Since the patch is quite complex, I wanted to try to build simpler patches, compare things and isolate issues, to see if I can work them around, find out exactly what and why behaves differently or at least be able to ask simple and meaningful questions to the list, or report bugs if any.
The problem is, I don't have gem-CVS20060412-NT-i686-bin here (I have it at the office and I won't be there untill next monday) and I can't find where the heck I downloaded it from.
I remember a few months ago I asked the list (pd-list or gem-dev) for versions more recent than the prehistoric 0.90, and somebody directed me to a directory somewhere at iem.at with lots of cvs snapshot (is that what they are?) and that's where I found gem-CVS20060412-NT-i686-bin...... but I can't find neither that page nor the thread in the list archives.
Can anybody help me find gem-CVS20060412-NT-i686-bin.zip?
Thanks in advance, m.
Matteo Sisti Sette wrote:
I remember a few months ago I asked the list (pd-list or gem-dev) for versions more recent than the prehistoric 0.90, and somebody directed me to a directory somewhere at iem.at with lots of cvs snapshot (is that what they are?) and that's where I found gem-CVS20060412-NT-i686-bin...... but I can't find neither that page nor the thread in the list archives.
Can anybody help me find gem-CVS20060412-NT-i686-bin.zip?
all these should be in http://gem.iem.at/releases/0.91
the old builds are just hidden, so that people do not get confused.
you are most likely looking for: http://gem.iem.at/releases/0.91/gem-CVS20060412-NT-i686-bin.zip/view
anyhow, the old binaries are hidden on purpose: the latest binary (which is visible) is meant to be a release-candidate.
if yo are experiencing problems, please elaborate so that they can hopefully be fixed within the next days (or weeks): which things do NOT work? which behave differently?
mfgasd.r IOhannes
Hi,
This is also related to the thread: "GEM: where to find gem-CVS20060412-NT-i686-bin (windows binaries)"
IOhannes wrote:
which things do NOT work? which behave differently?
Here's one thing that behaves differently (and annoyingly) in the new version - dunnow if it can be set to work the other way.
I have DirectX 9.0c and QuickTime 7.4.5 installed in my Windows XP machine.
I attach a modified version of the help-patch of pix_film: the only change I've made is to add "RGBA 1" arguments to the [open...( message fed into the pix_film. The important part is the "1" argument, which forces pix_film to use QuickTime rather than DirectX.
Now, try it with a dv-pal AVI file with audio - or maybe with ANY avi file with audio - or maybe even with a mov (I reproduced it with a dv-pal avi). The annoying thing is that it is playing the file audio track, and it does not come from PD (dsp is turned off). I dunnow where the heck the audio comes from but i hear it. If you don't activate the "auto" check nor move the frame number, a 1-frame-long (which is 40msec) fragment of audio is repeated over and over again, and the patch consumes almost 100% CPU.
With old gem-CVS20060412-NT-i686 this doesn't happen, with the same version of quicktime. GEM only reproduced the video, through QuickTime, and ignores the audio (which is what you expect from GEM isn't it). Also, if you don't activate "auto" nor move the frame number, it consumes much less CPU (which is reasonable cause it's not decoding new frames).
I guess I do can assume that 2006 version is also using quicktime because of the "1" argument in the open message. I don't know if the attached output (obtained with old 2006 version) (at the end of the message)confirms this.
Why and where is the audio being played? How can I turn it off and avoid useless cpu usage???
Thanks bye m.
Gem Man: QT init OK MAN::resetState entered pix_film:: avi support handle 0 11A4530 filmQT created pix_film:: quicktime support handle 1 11A45E8 handle 2 11A4698 handle 3 11A4730 handle 4 11A47C0 handle 5 11A4858 handle 6 11A48F8 pix_filmNEW : openMessCallback closing 8 handles close 7 close 6 close 5 close 4 close 3 close 2 close 1 close 0 closed movie size x:720 y:576 got handle = 11A45E8 GEM: pix_film: Loaded file: F:/currentwork/patches_marceli/patchesvideo_03_2007/testvideo/Clip02.avi with 14474 frames (720x576) at 482.000000 fps GEM: connected to tablet GemMan: create window GLEW version 1.3.3
Quoting Matteo Sisti Sette matteosistisette@gmail.com:
Now, try it with a dv-pal AVI file with audio - or maybe with ANY avi file with audio - or maybe even with a mov (I reproduced it with a dv-pal avi). The annoying thing is that it is playing the file audio track, and it does not come from PD (dsp is turned off). I dunnow where the heck the audio comes from but i hear it. If you don't activate the "auto" check nor move the frame number, a 1-frame-long (which is 40msec) fragment of audio is repeated over and over again, and the patch consumes almost 100% CPU.
hmm, quicktime has the bad habit of playing back the audio of a movie on it's own. it is weird that it did not happen before.
anyhow, i have uploaded yet another version to http://gem.iem.at/releases/0.91/gem-CVS20080509-W32-i686.exe
this version should at least mute the audio-output when using QuickTime
With old gem-CVS20060412-NT-i686 this doesn't happen, with the same version of quicktime. GEM only reproduced the video, through QuickTime, and ignores the audio (which is what you expect from GEM isn't it). Also, if you don't activate "auto" nor move the frame number, it consumes much less CPU (which is reasonable cause it's not decoding new frames).
indeed
I guess I do can assume that 2006 version is also using quicktime because of the "1" argument in the open message. I don't know if the attached output (obtained with old 2006 version) (at the end of the message)confirms this.
it does.
Why and where is the audio being played? How can I turn it off and avoid useless cpu usage???
i will probably have a look into the CPU-thing; nevertheless, there haven't been any real changes to the code (that would explain both the sudden appearance of sound and the cpu-thing) i assume that you are doing your tests on the same machine with just Gem.dll exchanged (so directX and quicktime should _really_ be the same)
anyhow, you probably will notice that Gem now comes as an installer (.exe) i hope this eases the installation procedure...
Hans, if you read this: is this installer ok for you too? (i guess you have downloaded the zip and extracted it manually, so there shouldn't be any real difference in terms of work)
fgamdsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
nevertheless, there haven't been any real changes to the code (that would explain both the sudden appearance of sound and the cpu-thing) i assume that you are doing your tests on the same machine with just Gem.dll exchanged (so directX and quicktime should _really_ be the same)
Yes, of course!!! Same machine, same everything. I just close PD, exchange the gem.dll, restart PD, open the patch again, and compare behaviours.
Something _must_ have changed that causes the appearance of audio. I assumed the CPU thing was the consequence of the audio thing but that was just my guess.
Now I'll try the new one.
zmoelnig@iem.at a écrit :
anyhow, i have uploaded yet another version to http://gem.iem.at/releases/0.91/gem-CVS20080509-W32-i686.exe
this is great, many object are fixed, pix_record almost doesn't crash anymore, pix_write can write jpg files, pix_zoom zooms...
pix_record only crashes pd when we submit a file in a folder that doesn't exist, and this can happen often because the object does't have an expected pd object behavior...
the message [file my/path/to/file.mov( will look into c:\Users\patco\my\path\to on vista or c:\Documents And Settings\patco on XP instead of mypatchfolder\my\path\to like usually do pd internal objects...
My guesses are that the default record folder is choosen by QT instead of pd, then I have to use another external [ggee/getdir] to tell [pix_record] where my patch is installed.
patco
On May 9, 2008, at 10:02 PM, zmoelnig@iem.at wrote:
Quoting Matteo Sisti Sette matteosistisette@gmail.com:
Now, try it with a dv-pal AVI file with audio - or maybe with ANY avi file with audio - or maybe even with a mov (I reproduced it with a dv- pal avi). The annoying thing is that it is playing the file audio track, and it does not come from PD (dsp is turned off). I dunnow where the heck the audio comes from but i hear it. If you don't activate the "auto" check nor move the frame number, a 1-frame-long (which is 40msec) fragment of audio is repeated over and over again, and the patch consumes almost 100% CPU.
hmm, quicktime has the bad habit of playing back the audio of a movie on it's own. it is weird that it did not happen before.
anyhow, i have uploaded yet another version to http://gem.iem.at/releases/0.91/gem-CVS20080509-W32-i686.exe
this version should at least mute the audio-output when using QuickTime
With old gem-CVS20060412-NT-i686 this doesn't happen, with the same version of quicktime. GEM only reproduced the video, through QuickTime, and ignores the audio (which is what you expect from GEM isn't it). Also, if you don't activate "auto" nor move the frame number, it consumes much less CPU (which is reasonable cause it's not decoding new frames).
indeed
I guess I do can assume that 2006 version is also using quicktime because of the "1" argument in the open message. I don't know if the attached output (obtained with old 2006 version) (at the end of the message) confirms this.
it does.
Why and where is the audio being played? How can I turn it off and avoid useless cpu usage???
i will probably have a look into the CPU-thing; nevertheless, there haven't been any real changes to the code (that would explain both the sudden appearance of sound and the cpu-thing) i assume that you are doing your tests on the same machine with just Gem.dll exchanged (so directX and quicktime should _really_ be the same)
anyhow, you probably will notice that Gem now comes as an installer (.exe) i hope this eases the installation procedure...
Hans, if you read this: is this installer ok for you too? (i guess you have downloaded the zip and extracted it manually, so there shouldn't be any real difference in terms of work)
Miraculously, I did read it. But I don't understand the question.
.hc
fgamdsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
Hans, if you read this: is this installer ok for you too? (i guess you have downloaded the zip and extracted it manually, so there shouldn't be any real difference in terms of work)
Miraculously, I did read it. But I don't understand the question.
it's a wonderous world.... the question was: whether you can live with an interactive .exe-installer just as happily as you can live with a .zip-file. i haven't had a look at how you actually include Gem in the nightly windows builds, but it could be that you are downloading the zip and install it using a script, which might be unhappy, if confronted with an installer (however, you can run the installer in silent mode, which will be as non-interactive as a zip-file)
fmadr IOhannes
On May 12, 2008, at 10:39 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
Hans, if you read this: is this installer ok for you too? (i guess you have downloaded the zip and extracted it manually, so there shouldn't be any real difference in terms of work)
Miraculously, I did read it. But I don't understand the question.
it's a wonderous world.... the question was: whether you can live with an interactive .exe-installer just as happily as you can live with a .zip-file. i haven't had a look at how you actually include Gem in the nightly windows builds, but it could be that you are downloading the zip and install it using a script, which might be unhappy, if confronted with an installer (however, you can run the installer in silent mode, which will be as non-interactive as a zip-file)
I manually download the binary and stick it into the rsync source that the auto-builds are built from.
It seems to me that it would be a better use of effort to get Gem building every night using MinGW, and then making a pd-vanilla+libs distro including Gem.
.hc
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
It seems to me that it would be a better use of effort to get Gem building every night using MinGW, and then making a pd-vanilla+libs distro including Gem.
patches welcome :-D
fgmadr IOhannes
On May 12, 2008, at 12:38 PM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
It seems to me that it would be a better use of effort to get Gem building every night using MinGW, and then making a pd-vanilla+libs distro including Gem.
patches welcome :-D
Funnily enough, I believe I have submitted some. So I guess that is your way of saying that you do not think this is a good approach?
.hc
fgmadr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner wrote:
On May 12, 2008, at 12:38 PM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
It seems to me that it would be a better use of effort to get Gem building every night using MinGW, and then making a pd-vanilla+libs distro including Gem.
patches welcome :-D
Funnily enough, I believe I have submitted some.
i am not aware of them. could you re-point me to them?
So I guess that is your way of saying that you do not think this is a good approach?
no, i have nothing against buing able to build Gem with mingw. i have just said, that _i_ will not spend the time to set it up.
however, it is my way of saying that i don't think (yet) that including Gem in the pd-ext build-system and having a Gem installer for w32 are not mutually exclusive.
fgmadsr IOhannes
Matteo Sisti Sette wrote:
i don't think (yet) that [...] are not mutually exclusive.
Was the double negation intentional?
no, it was a mistake.
Is the final product positive or negative?
i do believe, that we can (and should) have _both_ Gem standalone installers and a good integration into Pd-ext.
fmasr IOhannes
Hi,
IOhannes wrote:
which things do NOT work? which behave differently?
Another problem with the current 0.91 beta for Windows XP is that, whatever video file I open with pix_film (even using the pix_film help patch), I get a continuous flow of error messages: "GL: invalid enumeration" one message per frame!!!
This does not happen with old 2006 version, on the same machine, same everything except gem version. With that version, I only get ONE such error message every time I create the gemwin, not one per frame.
I have DirectX 9.0c and QuickTime 7.4.5.
Apart from preventing you to see any other useful debug information or any [print] output, and apart from being certainly a symptom of something very wrong, I suspect such a huge flow of messages to the console may be affecting performance: is it possible?
Any idea of the possible cause and of any workaround?
Thanks m.
Quoting Matteo Sisti Sette matteosistisette@gmail.com:
Hi,
IOhannes wrote:
which things do NOT work? which behave differently?
Another problem with the current 0.91 beta for Windows XP is that, whatever video file I open with pix_film (even using the pix_film help patch), I get a continuous flow of error messages: "GL: invalid enumeration" one message per frame!!!
hmm, which gfx-card do you have? (which driver?) does it support openGL-2.0?
anyhow, i have added a new object [GEMglReportError], which you can use to find the source even more easily. just put it into the gemchain, and it will output a non-0 value to it's right output whenever it encounters an error (probably use [change]->[print])
This does not happen with old 2006 version, on the same machine, same everything except gem version. With that version, I only get ONE such error message every time I create the gemwin, not one per frame.
i get ONE error on _some_ machines; but i don't see it here on w32 (though i think the same machine on linux does produce this error)
I have DirectX 9.0c and QuickTime 7.4.5.
Apart from preventing you to see any other useful debug information or any [print] output, and apart from being certainly a symptom of something very wrong, I suspect such a huge flow of messages to the console may be affecting performance: is it possible?
not directly. but once you have generated thousands of these, the buffer of the pd-console will fill up and eventually eat all your memory. a quick workaround is to run pd with "-stderr" which is faster.
fmkadsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
hmm, which gfx-card do you have?
ATI Mobility Radeon 9000
(which driver?)
Driver vendor: ATI Technologies Inc. Driver date: 09/12/2002 Driver version: 6.13.10.6250
Then if I click on "details" a long list of files appears (c:\windows\system32\something.dll), but I can't copy-paste, would have to write it manually
does it support openGL-2.0?
How can I find that out?
However, I think I had made the same comparison (20080422 vs 20060412) on another windows machine, at the office, a dual core with an Intel gfx chipset, with the same results: 2006 version only one invalid enumeration, 2008 version one invalid enumeration per frame.
anyhow, i have added a new object [GEMglReportError], which you can use to find the source even more easily. just put it into the gemchain, and it will output a non-0 value to it's right output whenever it encounters an error (probably use [change]->[print])
Did I understand its use correctly: I put several of them in different points of the chain (or try and move it), so that I find out which point of the chain produces the error, correct?
Thanks m.
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Matteo Sisti Sette -
Patrice Colet -
zmoelnig＠iem.at