[solved] latency between different cycles in a loop

Comments

• eduard

  February 2015 edited February 2015

  Hi,

  The reason for these breaks is that you specified a time out for the keyboard_response item that corresponds to the position of your target sound in seconds. So if the target appears at the first position, the sequence will continue quite quickly. However, if the target comes last, you'll wait 8 seconds more.
  What you should do is setting the time out to 'infinite' and untick the box Flush pending keypress (see image)

  

  Aside of this, you don't use the right way of specifying allowed responses. If you open List all available keys, you will see that RCTRL should be right control and accordingly for the left key. Both keys have to be separated by a semicolon.

  Addionally, o make sure that there is only one key press per trial, you can add later in the sequence another keyboard_response, whose time out is set 0 (so just skipped) but flushes all keypresses.

  Finally, a rather unrelated remark. According to your instruction, I believe reaction time is your dependent measure. If so, I'm afraid, you will run into trouble, because the reaction time is only measured after the audio player is finished. So what you must do, is setting its duration to 0. Be aware, this will cause other (solvable) issues. Let us know if you can't figure out how to solve them.

  I hope this was helpful.

  Eduard

  
• destear

  February 2015 edited 5:27AM

  Thank you for your answer!

  The Keyboard responses have to be RCTRL and LCTRL, otherwise the circle won't show - the keys work either way separated by comma or semicolon and a also listed in available keys written like that.

  I realize now that setting the audio duration to 0 is required. The Key-Response time out should be set at "[eigthpos]000 ms" an the response onset on "([eigthpos]000-500) ms"
  The subjects should always have 500 ms at the offset of the eighth-note to press the button (left or right ctrl depends on the circle/dot shown beforehand)

  Setting the audio to 0 causes new cycles to be played after I press a key, it should of course always play 8 seconds (+ that one second for the circle in each cycle)
• eduard

  February 2015 edited 5:27AM

  Hi,

  The Keyboard responses have to be RCTRL and LCTRL, otherwise the circle won't show -

  I don't get why the key identity has any effect on the stimuli on the canvas.

  the keys work either way separated by comma or semicolon and a also listed in available keys written like that.

  Okay, apparently the key labels are not the same between our versions, but if you can see the correct key labels in your logfile, everything is fine (running your uploaded experiment, only showed "None"s in my case, not "LCTRL/RCTRCL")

  I'm confused here. Does it work now like you want, or is the next video still starting too early?

  
• destear

  February 2015 edited 5:27AM

  I uploaded a new version, same link as above. I changed the experiment according to your instructions except the keymapping. The lag seems to be gone

  It still does not work though, because it won't let me use calculations for the duration of that last sketchpad called ISI and the button response, its onset should be on sth like [eighthpos]000-1000, the timeout on [eighthpos]000, an the entire trial should be 9 seconds long.
• eduard

  February 2015 edited 5:27AM

  Hi,

  Yes, I don't think you can put operations into the duration field of a sketchpad.
  Instead, you can add an inline_script just before the ISI item and put

  # check whether the math does what you want it to
  exp.ISI = 8000-exp.eighthpos*1000
  

  in its prepare phase. Then you can place [ISI] as duration in the sketchpad. This should do the trick, right?

  Eduard

  
• destear

  February 2015 edited 5:27AM

  the inline script did the job, thanks!
• destear

  February 2015 edited February 2015

  -