Hi,
A friend from our schools psychology department wants to use PD and GEM for an experiment. Here is his question and attached is the example patch. We need you help on this. Thanks.
OK, this is the patch that I'm going to use to conduct a research on cross-modal interactions in human perception. I'd be happy to fill anyone in on the topic because generally human cognition is fun to poke around.
So the required stimuli are a "beep" sound (which is a 3.5khz sine with 7 ms duration) and a "flash" (which is basically a white circle visible only for 20ms).
The problem is, it is very hard for an object to "flash" with this short duration. If you look at the patch you'll see that less than 50% of the trials do not produce anything.
I have to come up with a workaround to this and I thought maybe if I can syncronize the onset of the flash with the refreshing rate, I can at least make the disk visible for all of the trials. I can sacrifice the precision in terms of duration but that is bound to happen I guess.
I made this patch on windows with my laptop with a poor refreshing rate and another laptop with Macosx did not perform any better on the task(they are both 60hz screens). But I am guessing that a non-lcd monitor may do better? Any comments or suggestions on this?
Relevant information on the stimuli and the procedure can be found in this reference article for those of you who are interested "Visual illusion induced by sound" by Ladan Shamsa, Yukiyasu Kamitanib, Shinsuke Shimojoa.
#N canvas 78 53 295 395 10; #X obj 13 248 gemhead; #X msg 101 259 0 0 0; #X obj 13 311 disk 3 40; #X msg 72 173 255 255 255; #X obj 72 147 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 158 232 problem number; #X obj 72 200 t b l; #X obj 20 30 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 22 454 304 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X restore 25 69 pd gemwin; #X msg 25 50 create; #X text 21 29 Create window:; #X obj 101 233 delay 20; #X obj 13 284 color 0 0 0; #X connect 0 0 12 0; #X connect 1 0 12 1; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 6 0 11 0; #X connect 6 1 12 1; #X connect 8 0 9 0; #X connect 9 0 8 0; #X connect 11 0 1 0; #X connect 12 0 2 0;
set the framerate of your gemwin higher, then you get a flash at
every bang.
change [gemwin] to [gemwin 80]
(default with no argument is 20)
m.
Am 11.10.2007 um 12:42 schrieb Batuhan Bozkurt:
#N canvas 78 53 295 395 10; #X obj 13 248 gemhead; #X msg 101 259 0 0 0; #X obj 13 311 disk 3 40; #X msg 72 173 255 255 255; #X obj 72 147 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 158 232 problem number; #X obj 72 200 t b l; #X obj 20 30 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 22 454 304 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X restore 25 69 pd gemwin; #X msg 25 50 create; #X text 21 29 Create window:; #X obj 101 233 delay 20; #X obj 13 284 color 0 0 0; #X connect 0 0 12 0; #X connect 1 0 12 1; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 6 0 11 0; #X connect 6 1 12 1; #X connect 8 0 9 0; #X connect 9 0 8 0; #X connect 11 0 1 0; #X connect 12 0 2 0;
Batuhan Bozkurt wrote:
So the required stimuli are a "beep" sound (which is a 3.5khz sine with 7 ms duration) and a "flash" (which is basically a white circle visible only for 20ms).
The problem is, it is very hard for an object to "flash" with this short duration. If you look at the patch you'll see that less than 50% of the trials do not produce anything.
hmm,
I have to come up with a workaround to this and I thought maybe if I can syncronize the onset of the flash with the refreshing rate, I can at least make the disk visible for all of the trials. I can sacrifice the precision in terms of duration but that is bound to happen I guess.
the first thing i noticed is that you are running Gem with the default framerate, which is 20 fps (50ms!) there is plenty of time where you can trigger the flash right after a render-cycle and the flash will disappear before the next one.
so the first thing you ought to do is use a higher framerate, best choice will be the same rate as your monitor (60Hz): [gemwin 60]
it's hard to display a flash for 10ms if every frame stays there for 50ms... :-)
the next thing is to synchronize your trigger events with the gem-rendering.
just insert a [t a b] object to the gemchain (e.g. [gemhead]), the 2nd outlet will band everytime the gemchain is executed (the actual rendering (buffer swapping) is done immediately after all gemheads have returned, which is 0 logical time after the bang (but some microsecs real time)
fmadsr. IOhannes
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Yes there is. Your monitors have to have the same refresh rate in your xorg.conf (for all your monitors) as Gems refresh rate and you have to set up the opengl params of your card so that it refreshes the opengl in between synchs (called sync to VBlank in my nvidia-settings panel).
On 10/11/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the
gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le jeudi 11 octobre 2007 à 15:32 -0400, Thomas O Fredericks a écrit :
Yes there is. Your monitors have to have the same refresh rate in your xorg.conf (for all your monitors)
do you mean this part of xorg.conf:
Section "Monitor" Identifier "builtin" Option "DPMS" HorizSync 28-72 VertRefresh 43-60 EndSection
Section "Monitor" Identifier "flatpanel" Option "DPMS" HorizSync 28-72 VertRefresh 43-60 EndSection
Once I have checked "Sync to VBlank" for Video Texture Adpator and Video Blitter Adaptor, the nvidia-settings suggest to reset them to this:
Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor1" VendorName "Unknown" ModelName "LPL" HorizSync 30.0 - 75.0 VertRefresh 60.0 Option "DPMS" EndSection
Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "Unknown" ModelName "LG L1720B" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 75.0 Option "DPMS" EndSection
which would mean that according to the connected screen I display the Gem window on , I have to set the Gemwin framerate to 60 for "Monitor1" and to 75 for "Monitor0", If I got all your explanations well?
Or woudl it be better to lower the fastest screen's maximal VertRefresh rate to the slowest's?
++ O.
BOTH screens must have the same refresh rate or you will get tearing.
Tom
On 10/12/07, Olivier Heinry olivier.heinry@manga-burgah.net wrote:
Le jeudi 11 octobre 2007 à 15:32 -0400, Thomas O Fredericks a écrit :
Yes there is. Your monitors have to have the same refresh rate in your xorg.conf (for
all your monitors)
do you mean this part of xorg.conf:
Section "Monitor" Identifier "builtin" Option "DPMS" HorizSync 28-72 VertRefresh 43-60 EndSection
Section "Monitor" Identifier "flatpanel" Option "DPMS" HorizSync 28-72 VertRefresh 43-60 EndSection
Once I have checked "Sync to VBlank" for Video Texture Adpator and Video Blitter Adaptor, the nvidia-settings suggest to reset them to this:
Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor1" VendorName "Unknown" ModelName "LPL" HorizSync 30.0 - 75.0 VertRefresh 60.0 Option "DPMS" EndSection
Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "Unknown" ModelName "LG L1720B" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 75.0 Option "DPMS" EndSection
which would mean that according to the connected screen I display the Gem window on , I have to set the Gemwin framerate to 60 for "Monitor1" and to 75 for "Monitor0", If I got all your explanations well?
Or woudl it be better to lower the fastest screen's maximal VertRefresh rate to the slowest's?
++ O.
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
First and foremost, Windows XP does not have vsync enabled on desktop, so when you move a window around you will see tearing on sides of windows. This is not enabled in XP and I don't know a way of enabling it actually. I've heard that there was a beta of XP where vsync was enabled as default so I think this is a choice of developers(as it affects performance afair). And GEM is not synced too. You can try with the attached patch. I found no ways of enabling it for OpenGL applications. (I think vista has it enabled by default, did not try it though)
In linux, that is another story. Vsync is not enabled by default. You need to have direct rendering enabled to have vsync enabled. If you have a ATI graphics card with closed source drivers and you are using compositing(via XGL), that is not possible. If you are not using XGL, it is not enabled as default. If you have direct rendering enabled, you can use a tool called ''driconf'' to enable vsync. When you enable it, regular desktop is still not synced(move windows and you will see tearing). But GEM(and opengl) will be synced as they are using direct rendering. So you will be fine.
On Macos, vsync is enabled both on desktop and opengl by default. It looks smooth and nice, because of that. So you won't see any tearing whatsoever on your desktop or in GEM. This is really nice.
You can see the attached example to see if you have vsync on or off. If you are synced, the bar will move smoothly. If not, you will see tearing in movement.
In my experiments, XP had tearing and I had no fix, in Ubuntu Linux, tearing by default but can be fixed by driconf, and in osx there were no problems.
Batuhan
#N canvas 0 29 753 593 10; #N canvas 6 63 454 304 gemwin 0; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X obj 132 136 gemwin 60; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 2 1 4 0; #X connect 2 1 5 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 6 0 7 0; #X restore 39 82 pd gemwin; #X msg 39 63 create; #X obj 45 179 gemhead; #X obj 45 211 rotate 0 0 0 1; #X obj 45 250 translateXYZ; #X obj 190 210 line; #X obj 204 87 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 202 110 t b b; #X msg 189 176 4 1000; #X msg 255 189 -4 1000; #X obj 241 143 delay 1000; #X obj 330 166 delay 1000; #X obj 47 342 cuboid 0.06 4 0; #X text 199 61 bangme; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 1 10 0; #X connect 8 0 5 0; #X connect 9 0 5 0; #X connect 10 0 9 0; #X connect 10 0 11 0; #X connect 11 0 6 0;
Batuhan Bozkurt a écrit :
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
well, sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some).
First and foremost, Windows XP does not have vsync enabled on desktop, so when you move a window around you will see tearing on sides of windows. This is not enabled in XP and I don't know a way of enabling it actually. I've heard that there was a beta of XP where vsync was enabled as default so I think this is a choice of developers(as it affects performance afair). And GEM is not synced too. You can try with the attached patch. I found no ways of enabling it for OpenGL applications. (I think vista has it enabled by default, did not try it though)
In linux, that is another story. Vsync is not enabled by default. You need to have direct rendering enabled to have vsync enabled. If you have a ATI graphics card with closed source drivers and you are using compositing(via XGL), that is not possible. If you are not using XGL, it is not enabled as default. If you have direct rendering enabled, you can use a tool called ''driconf'' to enable vsync. When you enable it, regular desktop is still not synced(move windows and you will see tearing). But GEM(and opengl) will be synced as they are using direct rendering. So you will be fine.
well, with nvidia driver, you just have to click on the sincr to vbank toggle box in order to enable it. (and select on wich screen to sync in case of diferent screen frame rate)
cyrille
On Macos, vsync is enabled both on desktop and opengl by default. It looks smooth and nice, because of that. So you won't see any tearing whatsoever on your desktop or in GEM. This is really nice.
You can see the attached example to see if you have vsync on or off. If you are synced, the bar will move smoothly. If not, you will see tearing in movement.
In my experiments, XP had tearing and I had no fix, in Ubuntu Linux, tearing by default but can be fixed by driconf, and in osx there were no problems.
Batuhan
#N canvas 0 29 753 593 10; #N canvas 6 63 454 304 gemwin 0; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X obj 132 136 gemwin 60; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 2 1 4 0; #X connect 2 1 5 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 6 0 7 0; #X restore 39 82 pd gemwin; #X msg 39 63 create; #X obj 45 179 gemhead; #X obj 45 211 rotate 0 0 0 1; #X obj 45 250 translateXYZ; #X obj 190 210 line; #X obj 204 87 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 202 110 t b b; #X msg 189 176 4 1000; #X msg 255 189 -4 1000; #X obj 241 143 delay 1000; #X obj 330 166 delay 1000; #X obj 47 342 cuboid 0.06 4 0; #X text 199 61 bangme; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 1 10 0; #X connect 8 0 5 0; #X connect 9 0 5 0; #X connect 10 0 9 0; #X connect 10 0 11 0; #X connect 11 0 6 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate. You are syncing the open gl redraw to the framerate. The GPU takes care of that.
On 10/11/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Batuhan Bozkurt a écrit :
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left
with
a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at
all
to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
well, sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some).
First and foremost, Windows XP does not have vsync enabled on desktop, so when you move a window around you will see tearing on sides of windows. This is not enabled in XP and I don't know a way of enabling it actually. I've heard that there was a beta of XP where vsync was enabled as default so I think this is a choice of developers(as it affects performance afair). And GEM is not synced too. You can try with the attached patch. I found no ways of enabling it for OpenGL applications. (I think vista has it enabled by default, did not try it though)
In linux, that is another story. Vsync is not enabled by default. You need to have direct rendering enabled to have vsync enabled. If you have a ATI graphics card with closed source drivers and you are using compositing(via XGL), that is not possible. If you are not using XGL, it is not enabled as default. If you have direct rendering enabled, you can use a tool called ''driconf'' to enable vsync. When you enable it, regular desktop is still not synced(move windows and you will see tearing). But GEM(and opengl) will be synced as they are using direct rendering. So you will be fine.
well, with nvidia driver, you just have to click on the sincr to vbank toggle box in order to enable it. (and select on wich screen to sync in case of diferent screen frame rate)
cyrille
On Macos, vsync is enabled both on desktop and opengl by default. It looks smooth and nice, because of that. So you won't see any tearing whatsoever on your desktop or in GEM. This is really nice.
You can see the attached example to see if you have vsync on or off. If you are synced, the bar will move smoothly. If not, you will see tearing in movement.
In my experiments, XP had tearing and I had no fix, in Ubuntu Linux, tearing by default but can be fixed by driconf, and in osx there were no problems.
Batuhan
#N canvas 0 29 753 593 10; #N canvas 6 63 454 304 gemwin 0; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X obj 132 136 gemwin 60; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 2 1 4 0; #X connect 2 1 5 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 6 0 7 0; #X restore 39 82 pd gemwin; #X msg 39 63 create; #X obj 45 179 gemhead; #X obj 45 211 rotate 0 0 0 1; #X obj 45 250 translateXYZ; #X obj 190 210 line; #X obj 204 87 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 202 110 t b b; #X msg 189 176 4 1000; #X msg 255 189 -4 1000; #X obj 241 143 delay 1000; #X obj 330 166 delay 1000; #X obj 47 342 cuboid 0.06 4 0; #X text 199 61 bangme; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 1 10 0; #X connect 8 0 5 0; #X connect 9 0 5 0; #X connect 10 0 9 0; #X connect 10 0 11 0; #X connect 11 0 6 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock. if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock) so sometime, the screen has to display the same image twice. from my own perception, of an installation i made on osX, this was visible. (small, but visible) when gemrate was set to 70 and screen at 60, sync was perfect, but obvioulsy, pd was not able to generated 70fps, (only 60), so this create audio drop.
so, sync to Vblank is mandatory in order to have good images quality, but it's not the only need. the fps sould be exactly the same a your screen (or multiple of this), but you can only an aproximative syncronisation.
a perfect syncronisation between gem and the screen could be using a sync to Vblank, and gem fps faster than the screen and in a diferent thread than the audio.
cyrille
, b
On 10/11/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Batuhan Bozkurt a écrit :
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left
with
a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at
all
to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
well, sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some).
First and foremost, Windows XP does not have vsync enabled on desktop, so when you move a window around you will see tearing on sides of windows. This is not enabled in XP and I don't know a way of enabling it actually. I've heard that there was a beta of XP where vsync was enabled as default so I think this is a choice of developers(as it affects performance afair). And GEM is not synced too. You can try with the attached patch. I found no ways of enabling it for OpenGL applications. (I think vista has it enabled by default, did not try it though)
In linux, that is another story. Vsync is not enabled by default. You need to have direct rendering enabled to have vsync enabled. If you have a ATI graphics card with closed source drivers and you are using compositing(via XGL), that is not possible. If you are not using XGL, it is not enabled as default. If you have direct rendering enabled, you can use a tool called ''driconf'' to enable vsync. When you enable it, regular desktop is still not synced(move windows and you will see tearing). But GEM(and opengl) will be synced as they are using direct rendering. So you will be fine.
well, with nvidia driver, you just have to click on the sincr to vbank toggle box in order to enable it. (and select on wich screen to sync in case of diferent screen frame rate)
cyrille
On Macos, vsync is enabled both on desktop and opengl by default. It looks smooth and nice, because of that. So you won't see any tearing whatsoever on your desktop or in GEM. This is really nice.
You can see the attached example to see if you have vsync on or off. If you are synced, the bar will move smoothly. If not, you will see tearing in movement.
In my experiments, XP had tearing and I had no fix, in Ubuntu Linux, tearing by default but can be fixed by driconf, and in osx there were no problems.
Batuhan
#N canvas 0 29 753 593 10; #N canvas 6 63 454 304 gemwin 0; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X obj 132 136 gemwin 60; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 2 0 6 0; #X connect 2 1 4 0; #X connect 2 1 5 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 6 0 7 0; #X restore 39 82 pd gemwin; #X msg 39 63 create; #X obj 45 179 gemhead; #X obj 45 211 rotate 0 0 0 1; #X obj 45 250 translateXYZ; #X obj 190 210 line; #X obj 204 87 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 202 110 t b b; #X msg 189 176 4 1000; #X msg 255 189 -4 1000; #X obj 241 143 delay 1000; #X obj 330 166 delay 1000; #X obj 47 342 cuboid 0.06 4 0; #X text 199 61 bangme; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 1 10 0; #X connect 8 0 5 0; #X connect 9 0 5 0; #X connect 10 0 9 0; #X connect 10 0 11 0; #X connect 11 0 6 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 2007-10-12 at 01:49 +0200, Roman Haefeli wrote:
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
yo, it seems, that [gemhead] uses pd's logical time, which probably makes a lot of sense for many applications.
but for many other applications it would be better (read: the result would look nicer), if [gemhead] would get it's tick from the gpu and not from pd/audiocard, i think.
is that something that would be possible to do and might be worth a feature request on gem-dev?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I agree! It would guarentee better results but would increase the chance of a cpu lock up I think!
Tom
On 10/11/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Fri, 2007-10-12 at 01:49 +0200, Roman Haefeli wrote:
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame
rate, but
that's not the original question. to my knowledge, there is no possibility to sync gem rendering with
the
screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd
(cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as
the gpu clock.
so, sometime (specially with big patch), you can have desincronisation
between this 2 clocks, even if they should be at the same speed.
(there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
yo, it seems, that [gemhead] uses pd's logical time, which probably makes a lot of sense for many applications.
but for many other applications it would be better (read: the result would look nicer), if [gemhead] would get it's tick from the gpu and not from pd/audiocard, i think.
is that something that would be possible to do and might be worth a feature request on gem-dev?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2007-10-11 at 20:34 -0400, Thomas O Fredericks wrote:
I agree! It would guarentee better results but would increase the chance of a cpu lock up I think!
yo, i don't know anyhting about how these things are handled internally, but i wonder, what makes you think that.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
There is no clock available from the GPU.
On 10/11/07, Roman Haefeli reduzierer@yahoo.de wrote:
but for many other applications it would be better (read: the result would look nicer), if [gemhead] would get it's tick from the gpu and not from pd/audiocard, i think.
is that something that would be possible to do and might be worth a feature request on gem-dev?
roman
On Thu, 2007-10-11 at 19:39 -0500, chris clepper wrote:
There is no clock available from the GPU.
yo, sorry, i am just guessing 'into the blue'. i actually don't know, from where the screen gets its clock.
but you sure understand, what i mean. whereever from the screen gets its clock to, it would be nice to have the opportunity to sync [gemhead] with that clock.
what would be the drawbacks, if there are any?
roman
On 10/11/07, Roman Haefeli reduzierer@yahoo.de wrote: but for many other applications it would be better (read: the result would look nicer), if [gemhead] would get it's tick from the gpu and not from pd/audiocard, i think.
is that something that would be possible to do and might be worth a feature request on gem-dev? roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 10/11/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Thu, 2007-10-11 at 19:39 -0500, chris clepper wrote:
There is no clock available from the GPU.
yo, sorry, i am just guessing 'into the blue'. i actually don't know, from where the screen gets its clock.
The display device has an internal clock for its electronics.
but you sure understand, what i mean. whereever from the screen gets its
clock to, it would be nice to have the opportunity to sync [gemhead] with that clock.
There is no access to the GPU clock and certainly not the display device clock.
what would be the drawbacks, if there are any?
Other than the fact it is not really possible to do there aren't any drawbacks.
Roman Haefeli a écrit :
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
gemhead 50 | t b b | | realtime | print
you should have only 50. what i've got is :
print: 46.48 print: 52.183 print: 52.213 print: 46.474 print: 52.186 print: 46.505 print: 52.192 print: 52.179 print: 46.512 print: 52.174 print: 52.209 print: 46.484 print: 52.179 print: 46.512 print: 52.159
(with audio off, nothing else than the gemwin and this 4 object in the patch)
this jitter make it impossible to compute 1 and only 1 frame for each frame on the screen, even with sync on vblank.
cyrille
roman
___________________________________________________________ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
There is one catch to using vsync that not many know about. This illustrates it pretty well:
[gemwin 60] with pix_movie playing back a 29.97 fps DV clip:
print: 6.001 print: 27.532 print: 5.823 print: 27.144 print: 6.313 print: 27.383 print: 5.992 print: 28.492 print: 4.613 print: 29.411 print: 3.936 print: 28.189
Note that every other frame pattern. Why is that? The low number is probably a fairly accurate number for the CPU to fetch the frame from disk, decode and then fling it up onto the GPU for texturing, but what about the other number? Add the two numbers together and they are almost exactly the time for two frames to render (about 33 ms at 60fps). The reason is that the driver will wait on the 'no load' frame for the next sync before returning which is why it runs too long.
On 10/12/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
gemhead 50 | t b b | | realtime | print
you should have only 50. what i've got is :
print: 46.48 print: 52.183 print: 52.213 print: 46.474 print: 52.186 print: 46.505 print: 52.192 print: 52.179 print: 46.512 print: 52.174 print: 52.209 print: 46.484 print: 52.179 print: 46.512 print: 52.159
(with audio off, nothing else than the gemwin and this 4 object in the patch)
this jitter make it impossible to compute 1 and only 1 frame for each frame on the screen, even with sync on vblank.
On Fri, 12 Oct 2007, chris clepper wrote:
Note that every other frame pattern. Why is that? The low number is probably a fairly accurate number for the CPU to fetch the frame from disk, decode and then fling it up onto the GPU for texturing, but what about the other number? Add the two numbers together and they are almost exactly the time for two frames to render (about 33 ms at 60fps). The reason is that the driver will wait on the 'no load' frame for the next sync before returning which is why it runs too long.
Is it possible to make the frame-display call non-blocking ?
Just like when you read from or write to a socket with O_NONBLOCK so that it returns immediately, or use SIGALRM to put a timeout on a read or write operation.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 10/12/07, Mathieu Bouchard matju@artengine.ca wrote:
Is it possible to make the frame-display call non-blocking ?
Just like when you read from or write to a socket with O_NONBLOCK so that
it returns immediately, or use SIGALRM to put a timeout on a read or write operation.
This used to be an option on the Mac, but it stopped working at some point. It might have to do with the fact that all windows in the manager are locked to VBL already. Other OS might do it differently when just one GL app is set to sync.
On Fri, 12 Oct 2007, chris clepper wrote:
This used to be an option on the Mac, but it stopped working at some point. It might have to do with the fact that all windows in the manager are locked to VBL already. Other OS might do it differently when just one GL app is set to sync.
Ok, then the only solution is to start a small thread that only tries to display the last completed frame. It's sort of like the threaded soundfiler.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 10/12/07, Mathieu Bouchard matju@artengine.ca wrote:
Ok, then the only solution is to start a small thread that only tries to display the last completed frame. It's sort of like the threaded soundfiler.
Threading and OpenGL are a no-no. Plus, the driver is just going to stall on all GL calls until the swap is done at refresh.
Also, this isn't really a problem to being with. There is enough time to complete the calls and it runs at the correct Quicktime framerate and the request GL one too.
On 10/12/07, chris clepper cgclepper@gmail.com wrote:
On 10/12/07, Mathieu Bouchard matju@artengine.ca wrote:
Ok, then the only solution is to start a small thread that only tries to display the last completed frame. It's sort of like the threaded soundfiler.
Threading and OpenGL are a no-no. Plus, the driver is just going to stall on all GL calls until the swap is done at refresh.
On Fri, 12 Oct 2007, chris clepper wrote:
On 10/12/07, chris clepper cgclepper@gmail.com wrote:
On 10/12/07, Mathieu Bouchard matju@artengine.ca wrote:
Ok, then the only solution is to start a small thread that only tries to display the last completed frame. It's sort of like the threaded soundfiler.
Threading and OpenGL are a no-no. Plus, the driver is just going to stall on all GL calls until the swap is done at refresh.
If you can render to an explicitly off-screen buffer, I imagine that it would bypass the stalling at the level of all gl commands that use that buffer, and then you would have that other thread try to copy that buffer to screen and stall, instead of stalling the main thread. I don't know whether you can do that with OpenGL. Perhaps it can only be done in an OS dependent way or maybe not at all. I don't know enough OpenGL to tell. Maybe you can tell?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
hello,
i'm not 100% sur i agree with your analyse. could you test the same patch without Vsync?
if the driver wait for the "no load", introducing a 26ms frame. the next "no load" will be 1 frame latter: i.e. 16.6ms but the next frame is 6ms latter.
i'm wondering if the explanation is not : 16ms after the laste frame, pd try to render a frame, but rendering took 10ms, introducing a 26ms frame. pd clock is then 10ms late regarding the real world clock, so it try to compensate. the next 16ms will be only 16-10=6ms. so 6ms latter, pd try to render a new frame. this frame is quite easy to draw, as the image was already decoded, so there is no delay.
cyrille
chris clepper a écrit :
There is one catch to using vsync that not many know about. This illustrates it pretty well:
[gemwin 60] with pix_movie playing back a 29.97 fps DV clip:
print: 6.001 print: 27.532 print: 5.823 print: 27.144 print: 6.313 print: 27.383 print: 5.992 print: 28.492 print: 4.613 print: 29.411 print: 3.936 print: 28.189
Note that every other frame pattern. Why is that? The low number is probably a fairly accurate number for the CPU to fetch the frame from disk, decode and then fling it up onto the GPU for texturing, but what about the other number? Add the two numbers together and they are almost exactly the time for two frames to render (about 33 ms at 60fps). The reason is that the driver will wait on the 'no load' frame for the next sync before returning which is why it runs too long.
On 10/12/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
gemhead 50 | t b b | | realtime | print
you should have only 50. what i've got is :
print: 46.48 print: 52.183 print: 52.213 print: 46.474 print: 52.186 print: 46.505 print: 52.192 print: 52.179 print: 46.512 print: 52.174 print: 52.209 print: 46.484 print: 52.179 print: 46.512 print: 52.159
(with audio off, nothing else than the gemwin and this 4 object in the patch)
this jitter make it impossible to compute 1 and only 1 frame for each frame on the screen, even with sync on vblank.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2007-10-12 at 20:17 +0200, cyrille henry wrote:
Roman Haefeli a écrit :
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
gemhead 50 | t b b | | realtime | print
you should have only 50. what i've got is :
print: 46.48 print: 52.183 print: 52.213 print: 46.474 print: 52.186 print: 46.505 print: 52.192 print: 52.179 print: 46.512 print: 52.174 print: 52.209 print: 46.484 print: 52.179 print: 46.512 print: 52.159
(with audio off, nothing else than the gemwin and this 4 object in the patch)
this jitter make it impossible to compute 1 and only 1 frame for each frame on the screen, even with sync on vblank.
yo, i trapped my self by measuring with [timer].
anyway, if you calculate the average of these values, you'll come pretty close to 50ms (49.9094 to be accurate, though adding another 52.xx value will give you a result slightly above 50).
i cannot see that as a prove for your statement, that this would make it impossible to show exactly one frame on each screenrefresh. let's say each gem render cycle happens just half in between each screen refresh tick, then the jitter could be almost 30ms in both directions without showing the same frame twice or leaving out one frame.
i made a patch, that scrolls an image, whose pixel grid matches the pixel grid of the gemwin, by shifting the image an integer pixel value on each gem render cycle and i got an (almost) perfectly smooth and glitchfree movement, which is for me the empirical proof, that gem is able (or at least comes close) to show exactly one frame on each screen refresh tick. since gem and the screen apparently use different clocks, as mentioned in previous posts, this probably won't be true in the long run.
i'd rather to not want to send the patch to list (because of the weight of the images), but if you want i could send it to you privately.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli a écrit : ...
this jitter make it impossible to compute 1 and only 1 frame for each frame on the screen, even with sync on vblank.
yo, i trapped my self by measuring with [timer].
anyway, if you calculate the average of these values, you'll come pretty close to 50ms (49.9094 to be accurate, though adding another 52.xx value will give you a result slightly above 50).
yes.
i cannot see that as a prove for your statement, that this would make it impossible to show exactly one frame on each screenrefresh. let's say each gem render cycle happens just half in between each screen refresh tick,
how could that be possible without syncronisation?
then the jitter could be almost 30ms in both directions without showing the same frame twice or leaving out one frame.
i made a patch, that scrolls an image, whose pixel grid matches the pixel grid of the gemwin, by shifting the image an integer pixel value on each gem render cycle and i got an (almost) perfectly smooth and glitchfree movement, which is for me the empirical proof, that gem is able (or at least comes close) to show exactly one frame on each screen refresh tick. since gem and the screen apparently use different clocks, as mentioned in previous posts, this probably won't be true in the long run.
i think we agree : "almost perfect" is not "perfect"...
cyrille
i'd rather to not want to send the patch to list (because of the weight of the images), but if you want i could send it to you privately.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2007-10-11 at 22:53 +0300, Batuhan Bozkurt wrote:
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
thank you for all that info. though, it seems, that this is not the answer, i was initially looking for, it addresses a few issues i had in the past (mplayer -vo gl has tearing, gem has tearing) and which your hint seems to be the solution to. i tried driconf (basically it's just a graphical tool, that simply creates a file called .drirc). i enabled 'sync to vblank', and it worked, though running your testpatch now eats the whole cpu. i tried mplayer -vo gl (-vo gl is the opengl video output driver of mplayer) and there it works without pegging the cpu. i tested also armagetron and it worked as well.
Gem-devs: have you an idea, why enabling 'sync to vblank' does make Gem pegging the cpu? (ubuntu dapper, fresh gem-cvs, ati radeon mobility 9600, fglrx 7.0.0)
i would also like to hear if other users can have it enabled while doing gem.
for so many applications with gem, this option would make the result looking soo much better. it would be a huge gain to have that working, i think.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 2007-10-12 at 02:08 +0200, Roman Haefeli wrote:
On Thu, 2007-10-11 at 22:53 +0300, Batuhan Bozkurt wrote:
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the screen refresh rate? i noticed, that when using [gemwin <screenrefreshrate>], both are quite in synch, but not really. i made a patch, that shows a part of an image with a very width. now, when scrolling the image from right to left with a counter, that is hardsynced to [gemhead], i still see some glitches, the scrolling is not stable in movement. wouldn't it be cool, to have an option for [gemwin], that automatically hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at all to get 'screen clock' (i don't know how this is called correctly) on every os?
roman
I think this is called vsync(and seen as an option on some systems as ''sync to vblank''). And afaik this is not just tied to the software that is rendering things to screen but to the graphics card driver itself. I'm very frustrated about this in linux and windows.
thank you for all that info. though, it seems, that this is not the answer, i was initially looking for, it addresses a few issues i had in the past (mplayer -vo gl has tearing, gem has tearing) and which your hint seems to be the solution to. i tried driconf (basically it's just a graphical tool, that simply creates a file called .drirc). i enabled 'sync to vblank', and it worked, though running your testpatch now eats the whole cpu. i tried mplayer -vo gl (-vo gl is the opengl video output driver of mplayer) and there it works without pegging the cpu. i tested also armagetron and it worked as well.
yo, i just found out, that when i first create the Gemwin and then start rendering after some seconds, it works without any problems. the cpu-peak seems to appear only, when the gemwin is created. rendering itself doesn't harm the cpu more, as it would do without 'sync to vblank' enabled. when switching workspace, while rendering is on, cpu is pegged again and x reacts only very slowly.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
You need to raise the gemwin framerate. Just create the object like this: [gemwin 50] and you should see all of the flashes. Also, setting the gemwin to the refresh rate of the display might be best.
On 10/11/07, Batuhan Bozkurt batuhan@batuhanbozkurt.com wrote:
Hi,
A friend from our schools psychology department wants to use PD and GEM for an experiment. Here is his question and attached is the example patch. We need you help on this. Thanks.
OK, this is the patch that I'm going to use to conduct a research on cross-modal interactions in human perception. I'd be happy to fill anyone in on the topic because generally human cognition is fun to poke around.
So the required stimuli are a "beep" sound (which is a 3.5khz sine with 7 ms duration) and a "flash" (which is basically a white circle visible only for 20ms).
The problem is, it is very hard for an object to "flash" with this short duration. If you look at the patch you'll see that less than 50% of the trials do not produce anything.
I have to come up with a workaround to this and I thought maybe if I can syncronize the onset of the flash with the refreshing rate, I can at least make the disk visible for all of the trials. I can sacrifice the precision in terms of duration but that is bound to happen I guess.
I made this patch on windows with my laptop with a poor refreshing rate and another laptop with Macosx did not perform any better on the task(they are both 60hz screens). But I am guessing that a non-lcd monitor may do better? Any comments or suggestions on this?
Relevant information on the stimuli and the procedure can be found in this reference article for those of you who are interested "Visual illusion induced by sound" by Ladan Shamsa, Yukiyasu Kamitanib, Shinsuke Shimojoa.
#N canvas 78 53 295 395 10; #X obj 13 248 gemhead; #X msg 101 259 0 0 0; #X obj 13 311 disk 3 40; #X msg 72 173 255 255 255; #X obj 72 147 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 158 232 problem number; #X obj 72 200 t b l; #X obj 20 30 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 22 454 304 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 198 112 destroy; #X msg 132 112 create , 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 7 0; #X connect 3 1 5 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X restore 25 69 pd gemwin; #X msg 25 50 create; #X text 21 29 Create window:; #X obj 101 233 delay 20; #X obj 13 284 color 0 0 0; #X connect 0 0 12 0; #X connect 1 0 12 1; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 6 0 11 0; #X connect 6 1 12 1; #X connect 8 0 9 0; #X connect 9 0 8 0; #X connect 11 0 1 0; #X connect 12 0 2 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Batuhan Bozkurt -
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
Jack -
Mathieu Bouchard -
Max Neupert -
Olivier Heinry -
Roman Haefeli -
Thomas O Fredericks