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://220.127.116.11/
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 Terpercaya
yang 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
It's a little diffult to answer without seeing the task. I'm not sure how you implemented the version without the co-coutine and how it compares with the version with it)..
Can you specify which variable you are reading the response times from?
Have you inspected the onset times of the object involved (dot_block1, new_couroutines, keyboard_response)? This might shed some light on what is going on.
Thanks for you quick reply. This is how it looks like without the co-routine. really simple
To give you an idea of the task, this is how it looks like:
a fixation cross ("fixation") appears for 995 ms
then a "facestimulus" appears for 295 ms
then a black dot appears either on the left or right of the screen ("dot_block1"), this should be the onset for the response time. 1 trial lasts no longer than 5000 ms
for the co-routine, the idea was whenever participants did not give a keyboard response after 1995 ms, there would appear a text (feedback) saying "GO FASTER" on the screen.
I'm want to know the response time of the buttonpress (reaction time) of participants when a black dot appears either to the left or the right of the screen. So after the black dot appears (left or right), they have to indicate as fast as possible where the dot appeared. The black dot appears in "dot_block1" and this should be the onset time of the keyboard response(reaction time).
I noticed in the output data when using the co-routine, that the duration of the co-routine was the same as the response_time. However, i'm getting really fast reaction times (<50ms) which is physically impossible unless you start button mashing which I didn't do running the numbers :P
And here the data of experiment WITHOUT the co-routine
Hope this is clarifying.
Thanks again Fabrice!
It looks as if somehow the task is picking up something else then the response to the dot, but it's difficult to pinppoint the problem without examining the task. I've done a quick simulation of your design and got it to work and produce RTs that appear to match my actual responses. I upload here so that you can take a look. Hopefully you'll spot a difference with the way you're implementing it. Otherwse, feel free to upload your task here and I'lkl take a look.
Hope this helps!
Thank you so much for taking the time with this...
I copied your "feedback" reaction time in my own experiment. Unfortunately, it's measuring (unlike yours) really fast reaction times just like the output in my previous post... I dont know what the difference is between your experiment which works as intended, and my experiment which is getting crazy reaction times.
My experiment file is larger than 10mb, therefore I can't upload it here. So I uploaded it with WeTransfer in this link
Hopefully you can download it here (20 mb) and take a look. Maybe you can find what the issue is.
I really appreciate your time and effort Fabrice.
Thanks for upoloading your task. I had a look but the RTs I get with it seem correct. I did the task roughly controlling my RTs and the values displayed fitted. When I responded extremely fast, I got extremely fast RTs. It is possible to produce RTs below 100 ms (especially since in your experiment the onset of the dot is predictable, since it always follows the face by the same interval).
I ran the task on a few trials (0.5 x the cycle in block_loop and 0.01 x the cycle in block_loop_1).
I calculated a manual estimation of the RT based on the onsettime of the onset time of the keyboard_response object and the onset time of the feedback (showdata or showdata_1). These correspond to the time marked on the computer's internal clock when these events were triggered. It is a little longer than the actual RT because it would include the time required to prepara the feedback object on the fly and display it, but the subtraction of the first from the second did correspond to the actual RT measured by the kyyboard_response objects. Here's my calculation based on the datalog:
Note that because the showdata required a keypress and the data logger follows that feedback, it will base its
response_timevariable on the time participant took to produce the latest keyboard response, i.e., pressing a key when the feedback object appears. In that case, the true RT measure is contained ion the
response_time_keyboard_responsevariable. To demonstrat this, I removed the keypress from showdata and replaced it by 1000, but let keypress on for showdata_1. This means that for the practice trials, response_time and response_time_keyboard_response should be the same, but that for the tets trials they won't (response_time will be in response to the keypress to the showdata_1 object). Here's a check from the data log:
You can see that the two variables are equal for the practice trials but not for the test trials. Some of the RTs were very short because I purposefully responded as fast as I could (anticipating the appearance of the dot).
The difference between the two variables would disappear if you placed the logger before the feedback object (becasue then, the last keyboard event registered would always be that related to keyboard_response).
I attach the two Excel spreadsheets illustrated above:
Incidentally, I noticed that you duplicated many objects between your practice and test loops. I imagine that this was because you wanted ton include some objects that would only show in the test trials. An alternative way to work would have been to use linked copies of the objects, and use the content of the practice variable you set in the experient_loop to condition the "Run if" feature of the trial_sequence. You could just indicate there which object should only be deisplayed if practice is equal to "no". The advantage of this method is that avoids duplications, which can be a problem when you make changes to the task (because you have to remember to go make the changes in two places).
In sum, after inspecting your task, I don't find that the RTs are crazy. the task appears to register them correctly. In my tests, they correspond to the time estimated based on the surrounding objects's onset and they correspond to the times displayed in the feedback.