agen judi bola , sportbook, casino, togel, number game, singapore, tangkas, basket, slot, poker, dominoqq,
agen bola. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 50.000 ,- bonus cashback hingga 10% , diskon togel hingga 66% bisa bermain di android dan IOS kapanpun dan dimana pun. poker , bandarq , aduq, domino qq ,
dominobet. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 10.000 ,- bonus turnover 0.5% dan bonus referral 20%. Bonus - bonus yang dihadirkan bisa terbilang cukup tinggi dan memuaskan, anda hanya perlu memasang pada situs yang memberikan bursa pasaran terbaik yaitu
http://45.77.173.118/ Bola168. Situs penyedia segala jenis permainan poker online kini semakin banyak ditemukan di Internet, salah satunya TahunQQ merupakan situs Agen Judi Domino66 Dan
BandarQ Terpercaya yang mampu memberikan banyak provit bagi bettornya. Permainan Yang Di Sediakan Dewi365 Juga sangat banyak Dan menarik dan Peluang untuk memenangkan Taruhan Judi online ini juga sangat mudah . Mainkan Segera Taruhan Sportbook anda bersama
Agen Judi Bola Bersama Dewi365 Kemenangan Anda Berapa pun akan Terbayarkan. Tersedia 9 macam permainan seru yang bisa kamu mainkan hanya di dalam 1 ID saja. Permainan seru yang tersedia seperti Poker, Domino QQ Dan juga
BandarQ Online. Semuanya tersedia lengkap hanya di ABGQQ. Situs ABGQQ sangat mudah dimenangkan, kamu juga akan mendapatkan mega bonus dan setiap pemain berhak mendapatkan cashback mingguan. ABGQQ juga telah diakui sebagai
Bandar Domino Online yang menjamin sistem FAIR PLAY disetiap permainan yang bisa dimainkan dengan deposit minimal hanya Rp.25.000. DEWI365 adalah
Bandar Judi Bola Terpercaya & resmi dan terpercaya di indonesia. Situs judi bola ini menyediakan fasilitas bagi anda untuk dapat bermain memainkan permainan judi bola. Didalam situs ini memiliki berbagai permainan taruhan bola terlengkap seperti Sbobet, yang membuat DEWI365 menjadi situs judi bola terbaik dan terpercaya di Indonesia. Tentunya sebagai situs yang bertugas sebagai
Bandar Poker Online pastinya akan berusaha untuk menjaga semua informasi dan keamanan yang terdapat di POKERQQ13. Kotakqq adalah situs
Judi Poker Online Terpercayayang menyediakan 9 jenis permainan sakong online, dominoqq, domino99, bandarq, bandar ceme, aduq, poker online, bandar poker, balak66, perang baccarat, dan capsa susun. Dengan minimal deposit withdraw 15.000 Anda sudah bisa memainkan semua permaina pkv games di situs kami. Jackpot besar,Win rate tinggi, Fair play, PKV Games
Comments
Hi Michel,
Would it perhaps be possible to upload your experiment? Although your explanation is very clear and obviously rules out some possibilities, it is still a bit difficult to find out what might be causing the delay without seeing the experiment.
Best wishes,
Lotje
Did you like my answer? Feel free to
![:) :)](https://forum.cogsci.nl/plugins/emojiextender/emoji/twitter/smile.png)
Sure!
The prepare phase for the path attachment is a little bit crowded/overly nested. But in a nutshell it produces a list of canvas', each loaded a single picture from a path depending on the condition and the variables defined as in the block loop.
Prepare-phase
The run phase then loops through the canvas list and shows each item for 100 ms.
Run Phase
If I calculate the time of just the for loop in the run phase my subjective feeling that each picture is presented too long in only the latest version of OpenSesame is confirmed. Also sometimes I get weird trials in which only the very first picture lags (presented slightly longer than the other 16). However, I can't reproduce that error at the moment.
Thanks for the help!
EDIT: I reduced the code to make it more readable.
Hi Michel,
You're code looks fine, but I was wondering: How do you check the presentation time? It's probably best to store the timestamps returned by img.show() in a list, and print them out afterwards. It could very well be that presentation is indeed slow, but then we know exactly what we're talking about:
Btw, the reason for storing the timestamps in a list first, rather then printing them out directly, is that printing to the debug window causes a slight delay in itself.
Cheers!
Check out SigmundAI.eu for our OpenSesame AI assistant!
Hi sebastiaan,
I actually deleted the time check lines, since I included them only for debugging reasons. My assumption was however not entirely based on the values but also on the mere perception when starting the same code in either the v26 or v27. Here is what I did to check the time:
I am aware that there are delays in the presentation times between trials as well as when started in different version which might be entirely due to the print function. However, the pattern appears very distinct:
v26 - mean after 10 trials: 1850ms (around 110ms for each picture)
v27 - mean after 10 trials: 3600ms (around 210ms for each picture)
...both with low variability (around 100-200ms). I might check for more trials in a row.
This in combination with my subjective experience (which occurred before I checked the objective presentation times) gives me the impression that the timing is really not correct.
I will quickly run with your code and update this post.
Edit:
Ok, now I just got these weird fluctations again. But see yourself:
Here the times for the first 17 pictures in v26 (follow up trials are comparable):
Looks like decent ~110 ms steps.
And for v27 the first 17:
Also, decent ~110ms in the first two trials.
But then in the third trial:
Now we got stable 200ms for each picture. Looks like some memory issue or what could be the reason why the times change all of the sudden? Note that the time have almost NO variation anymore (only for the first picture)! The same in the upcoming trials.
Also, I rechecked with my old printing time attemps: It looks like my initial thought of having a comparable variation of 210ms in the new OpenSesame versions, was basically also exactly 200ms except for the first trial which is apparently even slower than the subsequent 16 pictures and therefore reducing the overall time to just a little bit more than 200ms per picture.
You're probably right, I'm not questioning that, but the code I posted potentially gives more insight, because it logs the timestamp for every image. Could you please run that and post the results? Perhaps you could try it with sequences of varying lengths (say with 1, 4, 8, and 16 images), to see if memory load might be an issue.
Check out SigmundAI.eu for our OpenSesame AI assistant!
Short update:
I ran it with 1,4,8,16. The pattern is always the same now. It always works fine the first 2 times I run it. But as soon as the third trial starts the presentation times start to lag. Also when I stop the script and restart it, the problem persists and presentation times directly lag in the first trial. Only a restart of the program solves the problem then.
I just ran more thorough tests. The longer I keep on running the experiment with the lag, the slower the whole computer appears to become. After about 18-20 trials with 8 pictures, the program hardly reacts, and even if I press esc and close the program the computer works only slow. A new start of the program then quickly results in a Visual C++ Runtime Library error of opensesame.exe.
Maybe memory overload? The latter problem btw, needs more trials to occur when I only work with 1 or 2 pictures in each trial.
Hi Michel,
Right, I see. Indeed, there is a clear and consistent slowdown.
The ITIs for the first trials are exactly 116.66ms, which is what you would expect given a 100ms sleep on a 60Hz monitor (where each cycle is 16.66Hz). If you want to get an ITI of 100ms, you should use a slightly shorter sleep, say 90ms. For a short discussion about this (which might not be intuitively obvious), see this post: http://www.cogsci.nl/forum/index.php?p=/discussion/comment/1054#Comment_1054
But that's not the main issue, of course. I suspect that the memory of the graphics card fills up. Once memory is full, PsychoPy can no longer pre-load the images and a pre-load delay is added to the presentation time (I think). This could be a bug in PsychoPy/ PyOpenGL (which have been updated since the 0.26 package), it might be an issue in your experiment, or perhaps a combination of both. There haven't been any significant changes in the psycho back-end itself, since 0.26.
You could do a number of things:
[pastebin:T9JVwGCL]
I'm not sure how keen you are to get to the bottom of this, but you could see what happens if you downgrade PsychoPy to the version that came with OpenSesame 0.26 (you can check by running modules() in the debug window). To downgrade, you can simply replace the psychopy sub-folder of OpenSesame with the folder from the PsychoPy source: http://code.google.com/p/psychopy/downloads/list
If this resolves the issue, then we could consider reporting it to the PsychoPy developers. If it doesn't than the problem is elsewhere.
Cheers!
Check out SigmundAI.eu for our OpenSesame AI assistant!
Hey sebastiaan,
some interesting news: First, the backend indeed solves the problem. No problems with e.g. legacy. The other interesting news is that with my code even when reduced to this bit:
... in the run phase, the problem occurs. However when I simply copy pasted yours, the problem does not occur that much. However, there are still changes in the time. Sometimes it jumps between pictures from 100ms to 200ms (or something in between), but these jumps rarely occur! As you can see in my first post I also used a comparable loop structure like you did in my first attempt as compared to the MATLAB-like i-iteration structure I used in my last attempt. So that's probably not it (would have surprised me anyways. So it basically boils down to fluctuations in the .show time "lag".
Also: Sure, I want to get to the bottom of this problem. So your suggestion is now to downgrade the psychopy engine and rerun the stuff in order to check whether they made some changes that caused this problem?
Cheers, and thanks for the help Sebastiaan!
Edit: example first three trials ( I marked the jumps) :
Good! The script basically throttles the presentation, so that it doesn't go too fast. But when canvas.show() by itself takes longer than the intended delay, there will still be timing glitches, of course. I would definitely double check on the PC that you intend to use for actual testing to see how it goes there. If it's a very fast PC the timing might be perfect, if it's a very slow PC you might see substantial glitches.
Yes, exactly. It's very puzzling that this problem didn't occur before (the results from 0.26 and 0.27 are from the same computer, right?), so there must be a regression somewhere.
Check out SigmundAI.eu for our OpenSesame AI assistant!
Allright,
I'll check it as soon as I got time.
For the moment, your solution with subtracting the time needed for the show function, seems a decent temporary solution, right?
Thanks for the support!