chris clepper wrote:
On May 14, 2004, at 12:41 PM, IOhannes m zmoelnig wrote:
Try a negative number for offset - that's what I use to crash RGBA on
well, i have tried both +10000 and -10000 and it *seemed* to work.
furthermore i have fixed the [pix_dot] on macOS.
I didn't even know it needed fixing.
oh...on our G4 in YUV it produced little green squares instead of white circles. they didn't change at all. (actually it was the same bug as in pix_halftone : the shifts where for the high-byte where we low-byte was needed)
and finally i have added a "yuv"-message to the [pix_texture]-object to disable direct YUV-texturing on demand (because our g4 doesn't like em)
Let me guess - you have a Geforce 2MX card and run 10.3? It might be worth trying the 10.2 drivers which don't seem to have the crazy dual image problem. I have no idea how to get this problem fixed because Nvidia has little to no presence in the Mac developer sphere.
it is a geForce-4MX; but i think 10.3 might be right (i have no idea how to get the version when logging in via ssh)
so that should be it (?)
I don't think Jamie has committed the halftone fixes yet.
i have to admit, that halftone is working almost perfectly for me on windows, linux and macOS in rgba/yuv/grey.
I'm ready to get this release out, and can have builds ready to go by Monday or Tuesday of next week.
i think that is fine (although i am not sure whether i can make builds by this date too because i might be on an emergency trip to suisse (i'll now by sunday evening ;-))
mfg.a.sdr IOhannes
On May 15, 2004, at 3:06 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
On May 14, 2004, at 12:41 PM, IOhannes m zmoelnig wrote: Try a negative number for offset - that's what I use to crash RGBA on
well, i have tried both +10000 and -10000 and it *seemed* to work.
...uh, guys, the range of values in the original source code for line offset is supposed to only be -127 to 127 ;-) Do ya really think we need to go all the way to +/-10000?
furthermore i have fixed the [pix_dot] on macOS.
I didn't even know it needed fixing.
...cool, I'd totally forgotten about this after getting pix_halftone working...
oh...on our G4 in YUV it produced little green squares instead of white circles. they didn't change at all. (actually it was the same bug as in pix_halftone : the shifts where for the high-byte where we low-byte was needed)
and finally i have added a "yuv"-message to the [pix_texture]-object to disable direct YUV-texturing on demand (because our g4 doesn't like em)
Let me guess - you have a Geforce 2MX card and run 10.3? It might be worth trying the 10.2 drivers which don't seem to have the crazy dual image problem. I have no idea how to get this problem fixed because Nvidia has little to no presence in the Mac developer sphere.
it is a geForce-4MX; but i think 10.3 might be right (i have no idea how to get the version when logging in via ssh)
so that should be it (?)
I don't think Jamie has committed the halftone fixes yet.
...working on getting it in tonight: real life deadlines have been everywhere for me lately...
I'm ready to get this release out, and can have builds ready to go by Monday or Tuesday of next week.
...yeh, I think we're really getting close! But, I've got a question: why did whoever it was add all those inlets? Unless we're gonna put in some kind of "tooltips", I think that having 8 different unlabeled inlets is a great example of bad user interface...
jamie
James Tittle II wrote:
On May 15, 2004, at 3:06 AM, IOhannes m zmoelnig wrote: ...yeh, I think we're really getting close! But, I've got a question: why did whoever it was add all those inlets? Unless we're gonna put in some kind of "tooltips", I think that having 8 different unlabeled inlets is a great example of bad user interface...
i think it was me. but i have no idea, what object you are talking about (or are you talking about 8 unlabeled inlets in all the objects together ? would be a great example of a good user interface, with some minor inconsitencies...) i do think that most (if not all) inlets are explained in the help-patches but i might be wrong here (damned, 2 days ago i walked through all of the help-patches to see whether they do work on a windos-machine with a crappy graphics card; it took hours - and i have to admit, it becomes rather boring after 30 minutes and my concentration went away)
mfg.asd.r IOhannes
PS: Gem completely froze my laptop under w2k (under linux it works fine) - i was almost panicking before i noticed that each single openGL-application makes a total freeze; and on other machines my win-build works, so i am kind of ready
On May 19, 2004, at 1:44 AM, IOhannes m zmoelnig wrote:
i think it was me. but i have no idea, what object you are talking about (or are you talking about 8 unlabeled inlets in all the objects together ? would be a great example of a good user interface, with some minor inconsitencies...)
I got some clarification on this, and it's pix_kaleidoscope which has all those inlets. I think most objects have gone to sending messages to the left inlet anyway, and that's just fine. I've never liked the way Pd handles object sizing and multiple inlets anyway.
i do think that most (if not all) inlets are explained in the help-patches but i might be wrong here (damned, 2 days ago i walked through all of the help-patches to see whether they do work on a windos-machine with a crappy graphics card; it took hours - and i have to admit, it becomes rather boring after 30 minutes and my concentration went away)
I did the same thing on a G5 and my AMD box this weekend. I threw some pmpd into the mix for entertainment. I still laugh at the 'hollywood explosion' patch.
PS: Gem completely froze my laptop under w2k (under linux it works fine) - i was almost panicking before i noticed that each single openGL-application makes a total freeze; and on other machines my win-build works, so i am kind of ready
0888-r2 runs ok on my win2k box, although can you double check the compilation settings? A few things like pix_biquad ran slower than I would have expected them too, and maybe the optimization settings aren't maxed out.
If Jamie has checked in the final halftone code then I think it's ready to go. We should work up some release notes while waiting for the builds.
Also, I'm just going to post a G3, G4 and G5 build on my page and you can either link to it from IEM or copy them to the local server. My server is on multiple 100 Mbit lines off the main backbone in the midwest so there is no problem handling the load.
cgc
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
chris clepper wrote:
On May 19, 2004, at 1:44 AM, IOhannes m zmoelnig wrote:
I got some clarification on this, and it's pix_kaleidoscope which has all those inlets. I think most objects have gone to sending messages to the left inlet anyway, and that's just fine. I've never liked the way Pd handles object sizing and multiple inlets anyway.
i see your point (with 8 or more inlets - remembers me of zexy's matrix-objects with 24 inlets (or whatever) ;-))
i do think that most (if not all) inlets are explained in the help-patches but i might be wrong here (damned, 2 days ago i walked through all of the help-patches to see whether they do work on a windos-machine with a crappy graphics card; it took hours - and i have to admit, it becomes rather boring after 30 minutes and my concentration went away)
I did the same thing on a G5 and my AMD box this weekend. I threw some pmpd into the mix for entertainment. I still laugh at the 'hollywood explosion' patch.
let me share your amusement. i don't get a clue
0888-r2 runs ok on my win2k box, although can you double check the compilation settings? A few things like pix_biquad ran slower than I would have expected them too, and maybe the optimization settings aren't maxed out.
the 0.888-rc2 has been compiled as Debug (no optimization) - i have just forgotton to switch it to Release....
If Jamie has checked in the final halftone code then I think it's ready to go. We should work up some release notes while waiting for the builds.
alright
Also, I'm just going to post a G3, G4 and G5 build on my page and you can either link to it from IEM or copy them to the local server. My server is on multiple 100 Mbit lines off the main backbone in the midwest so there is no problem handling the load.
ok.
mfg.asd.r IOhannes
On May 19, 2004, at 10:08 AM, IOhannes m zmoelnig wrote:
If Jamie has checked in the final halftone code then I think it's ready to go. We should work up some release notes while waiting for the builds.
alright
ok,
...trying to commit, but can't! What's this trying to tell me?
tiggity:~/puredataDev/Gem/src/Pixes tigital$ cvs commit -f -m "New version of YUV luma, which is more sensitive" pix_halftone.cpp cvs commit: Up-to-date check failed for `pix_halftone.cpp' cvs [commit aborted]: correct above errors first!
...there are many conflicts with the "latest" version, but that's because I've gone back to looking at yuv luma two at a time, among other things...how do I get around this?
jamie
James Tittle II wrote:
...trying to commit, but can't! What's this trying to tell me?
tiggity:~/puredataDev/Gem/src/Pixes tigital$ cvs commit -f -m "New version of YUV luma, which is more sensitive" pix_halftone.cpp cvs commit: Up-to-date check failed for `pix_halftone.cpp' cvs [commit aborted]: correct above errors first!
...there are many conflicts with the "latest" version, but that's because I've gone back to looking at yuv luma two at a time, among other things...how do I get around this?
my (not very sensible) solution for this kind of problems is normally: a) copy my "original" file to somewhere else b) delete the original file c) cvs up (getting the newest version) d) look at the differences (optional ;-)) e) replace the new file with my old one f) cvs ci
mfg.as.dr IOhannes
On May 19, 2004, at 11:18 AM, IOhannes m zmoelnig wrote:
my (not very sensible) solution for this kind of problems is normally: a) copy my "original" file to somewhere else b) delete the original file c) cvs up (getting the newest version) d) look at the differences (optional ;-)) e) replace the new file with my old one f) cvs ci
excellent: I finally figured out that sometimes it's better to just move everything outta the way and start over...
...so, it's committed, and needs to be checked (especially on other platforms), because it's a bit different than the previous version: I think the images stand out much better, but I may just be seeing things :-)
...so, I've also committed a "ChangeLog" generated via "cvs2cl --accum": I think it's a great resource for figuring out what we've gotten ourselves into!
jamie
hello,
I had problem with data files in gem cvs. it look like most of picture and movie (in gem/examples/data are corrupted on the cvs. I tried to removed them from my computer and update, but the new ones are still not valid. does anybody else have this problem?
thank's cyrille
cyrille henry wrote:
hello,
I had problem with data files in gem cvs.
does anybody else have this problem?
no
what do you mean by "not valid"/"corrupted" ? i have removed all of the files in examples/data and checked them out again and they are still ok.
mfg.as.dr IOhannes
what do you mean by "not valid"/"corrupted" ?
I can't read the jpeg picture (no picture-wiever can load them) anim-1.mov can't be read by quick time ... tif file are ok!
i have removed all of the files in examples/data and checked them out again and they are still ok.
ok, that not the case here that mean something really stange happend on my computer I change from winCVS to tortoiseCVS and did not solve this.
hum... I'll try on linux.
thank's a lot cyrille
James Tittle II wrote:
On May 19, 2004, at 11:18 AM, IOhannes m zmoelnig wrote:
...so, it's committed, and needs to be checked (especially on other platforms), because it's a bit different than the previous version: I think the images stand out much better, but I may just be seeing things :-)
actually i was not very convinced : i remembered pix_halftone to be kind of grey and now it turned out so colourful ;-) i have removed the hardcoded shifts and replaced them by SHIFT_* (yah, i know, this is also hardcoded, but kind of platform-independent)
now it works (on linux), but: are there vertical stripes of lower intensity intended ? see http://iem.at/~zmoelnig/GEM/halftone/ for what i mean
...so, I've also committed a "ChangeLog" generated via "cvs2cl --accum": I think it's a great resource for figuring out what we've gotten ourselves into!
cool. i especially loved the "initial check-in" ;-) joking aside, it's good to have such file (and even without initial-checkins it is still 170k !!!9
mfg.a.sdr IOhannes
On May 19, 2004, at 12:10 PM, IOhannes m zmoelnig wrote:
James Tittle II wrote:
On May 19, 2004, at 11:18 AM, IOhannes m zmoelnig wrote: ...so, it's committed, and needs to be checked (especially on other platforms), because it's a bit different than the previous version: I think the images stand out much better, but I may just be seeing things :-)
actually i was not very convinced : i remembered pix_halftone to be kind of grey and now it turned out so colourful ;-)
...d'oh!
i have removed the hardcoded shifts and replaced them by SHIFT_* (yah, i know, this is also hardcoded, but kind of platform-independent)
now it works (on linux), but: are there vertical stripes of lower intensity intended ? see http://iem.at/~zmoelnig/GEM/halftone/ for what i mean
...sorry I didn't get the shift's in there right off the bat...as far as the vertical stripes, it looks the same here: that's why I held off committing it...I'm guessing that there's something wrong with the area averaging, but I haven't found it...in any event, it seems better at getting an image across than the previous method?
...so, I've also committed a "ChangeLog" generated via "cvs2cl --accum": I think it's a great resource for figuring out what we've gotten ourselves into!
cool. i especially loved the "initial check-in" ;-) joking aside, it's good to have such file (and even without initial-checkins it is still 170k !!!
...yep, we've typed lotsa stuff in the last year and a half...so, maybe it's time to figure out who's buying the virtual celebratory beer?
jamie
On May 19, 2004, at 12:19 PM, James Tittle II wrote:
On May 19, 2004, at 12:10 PM, IOhannes m zmoelnig wrote:
i have removed the hardcoded shifts and replaced them by SHIFT_* (yah, i know, this is also hardcoded, but kind of platform-independent)
now it works (on linux), but: are there vertical stripes of lower intensity intended ? see http://iem.at/~zmoelnig/GEM/halftone/ for what i mean
...sorry I didn't get the shift's in there right off the bat...as far as the vertical stripes, it looks the same here: that's why I held off committing it...I'm guessing that there's something wrong with the area averaging, but I haven't found it...in any event, it seems better at getting an image across than the previous method?
...ok, after playing around with this even more, I noticed that it's not a problem with area averaging, but with how the "dots" actually get drawn...it became apparent when I was looking at some of the other shapes (diamond especially): the left side is being drawn correctly in yuv, but not the right side...this must have something to do with the calcCorners or the rotate vertex algorithm, but I haven't picked it totally yet...
...just some public musings... jamie
-
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
James Tittle II