keyboard response not recorded

Comments

• Katharina

  July 2020 edited July 2020

  
  
• Katharina

  July 2020 edited July 2020

  I think now that I added an inlines

  
  

  trial_duration = clock.time() - run_onset

  if trial_duration < 3990:

  self.sleep(3990-trial_duration-prepare_duration)

  
  

  
  

  AND

  
  

  if self.get(u'response') == var.correct_response:

  var.correct = u'1'

  else:

  var.correct = u'0'

  
  

  Still not getting response for space and enter

  it worked but I am the timing differs in trials with and without response.

  I would be thankful if you could just check. I thank you for your generocity!
• AntonyMarsh

  July 2020

  Hello...If I understand your situation correctly, you want to poll simultaneously for multiple keypresses, right? So the user is expected to give two (or more) responses, but not necessarily in a fixed order. The script below shows how you can implement this in an inline_script. Basically, you just continuously poll the keyboard and check whether collected keypresses are part of a predefined list.
• Katharina

  July 2020

  Hi! Sort of :=)

  and the important thing is that the presentation should NOT end with response
• Katharina

  July 2020 edited July 2020

  the issue with the correct response is solved but the timing issue is not.

  
  

  My total preparation time (prepare_duration) is about 300 ms. I want the ITI to be fixed 1000 ms (either waiting for response = timeout) or sleeping the rest to get 1000 in total.

  I have added a new variable timeout

  
  

  run_onset = clock.time()
  prepare_duration = run_onset - prepare_onset
  print('prepare duration: {}'.format(prepare_duration))
  var.duration = prepare_duration
  ITI = 995
  timeout = ITI - prepare_duration
  
  var.timeout = u'timeout' ( I also tried var.timeout = timeout)
  

  
  

  and set the timeout in keyboard [timeout] but I get an error that this variable does not exist. Or that it's not an allowed timeout

  
  

  I dont know if and how I should put the prepare_duration and if it really playes a role because 300 ms is a LOT of time. Many thanks!
• eduard

  July 2020

  Hi Katharina,

  No need to make it so complicated, this script does the same thing as yours;

  var.duration = clock.time() - prepare_onset
  print('prepare duration: {}'.format(var.duration))
  ITI = 995
  var.timeout = ITI - prepare_duration
  

  So, in terms of syntax and logic that script is correct (also your version 2 above). One obvious reason why it did not work would be that you put it at the wrong place in the experiment. The fact that the error message says that timeout does not exist suggests that you have put the code in the run phase of the inline_script. Is that so? In that case try putting it in the prepare phase. That might already do the trick. If not, please share your experiment.

  Thanks,

  Eduard

  
• Katharina

  July 2020

  Thank you!

  Maybe the problem is that I am putting [timeout] into the timeout window of the keyboard element (where it says please an interger or infinite). I guess it doesnt work like this?
• eduard

  July 2020

  I don't think so, but you can give it a try:

  var.duration = clock.time() - prepare_onset
  print('prepare duration: {}'.format(var.duration))
  ITI = 995
  var.timeout = int(ITI - prepare_duration)
  

  So, it still does not work? Have you tried the prepare-run phase thing?

  
• Katharina

  July 2020

  Thank you!

  Unfortunately, it did not help to have the solution but at least I don't get the error. But neither in preparation nor in run it is not removing the prepare-duration so that the ITI is always around 1300 instead of 995. Int() did not help to solve that. This is really strange.
• eduard

  July 2020

  Oh sorry, there was a stupid mistake:

  var.duration = clock.time() - prepare_onset
  print('prepare duration: {}'.format(var.duration))
  ITI = 995
  var.timeout = int(ITI - var.duration)
  

  Actually, given that the code above didn't throw an error is weird and suggests that you have similar code flying around somewhere in the script. Can you share the experiment (if the code here doesn't solve it)?

  Eduard

  
• Katharina

  July 2020

  yes, I also changed it to var.duration but it did not help. I cut the experiment file only to the necessary to test. Thank you again!

  try_mouse.osexp

  
  
• eduard

  July 2020

  Okay, a couple of things:

  prepare_onset = clock.time()
  run_onset = clock.time()
  prepare_duration = run_onset - prepare_onset
  

  prepare_duration will essentially be 0, as the time between the 2 clock.time() calls is virtually identical. So, if you want to test whether your script works, you actually need to do some preparation work in the prep_duration.

  I think what you meant to do, is start measuring the time in the beginning of the prepare phase and then again in the run phase, the difference of which would be the preparation time. With the current set up, the closest you can get to what you described is attached below (taking the prep time from early in the block until right before the mouse response, and not the actual start of the run phase. The difference should be marginal though).

  Second, I think it is unusual to have a fixed ITI consisting of the response period. Normally, you have a fixed and unchangeable response period (say 1000 ms), and after that a variable ITI, depending on the response time so that the total ITI has some fixed value. With the current set up you essentially punish participant for Opensesame's preparation time (300 ms will be deducted from their response time).

  I don't know what your requirements are for this project, but I would recommend, you set a fixed timeout for the mouse response, but add an advanced delay item (or an inline_script) afterwards that will dynamically adapt the length of the ITI, based on prep and response time.

  Does that make sense?

  
  

  Eduard

  try_mouse.osexp

  
  

  
• Katharina

  July 2020 edited July 2020

  But does the inline

  if self.get(u'response') is not "None":

  self.sleep(3995 - trial_duration - prepare_duration)

  not do that?

  
  

  Anyways, now I checked the timing, it's always about 1000 ms between the trials (ITI)! Very cool! The perfect 1000 ms instead of 1032-ish is probably not reachable so I am happy with what it is. You basically just copied it before the response routine, that's clever! Thank you ever so much!

  
  

  I want a fixed time for all elements of the presentation, also ITI, irrespective of if there is a response or not. I guess it is like this now.

  Thank you ever so much!
• eduard

  July 2020

  I am confused. This inline_script is indeed the way to go if you want to have constant ITIs of 4 seconds. However for have such ITIs, there is no need to set the timeout of the mouse response dynamically. If you always fix it at 1000 ms. You can still do that subtraction in the end and you would get a fixed ITI. There is also no need to make a distinction whether a response was given or not. The computation makes sense either way.

  I further simplified your script. I think it already does what it supposed to do (more or less). The problem is that your trials take longer than 3995 anyway, so if you compute how much extra sleep you need to invoke, you'll get negative values, which means that the experiment simple continues.

  So yeah, I don't know exactly the motivation behind this experiment, whether these 4 seconds are critical or not, but I would probably use a longer delay to fit the whole trial in there and have a constant ITI.

  try_mouse.osexp

  Eduard

  
• Katharina

  July 2020 edited July 2020

  Thank you!

  
  

  There either a response (within the ITI) or not, that's why I need a flexible ITI

  
  

  Yes, I figured out the negative values, but it's only when there is no response, that's why I had to do it in that complicated way
• eduard

  July 2020

  I understand that. To have a flexible ITI your procedure is fine. All I am saying is that you should not make the response period in your ITI flexible (if it is 1 seconds max), but only the time that follows after. Currently, there is no time after, your trial sequence seems to take longer than the 4 seconds you intend it to have. So that would require that you have generelly longer ITIs. Then you can still apply the same procedure and make sure the post-trial time is dynamically adapted to make the overall trial time constant. Whether there is a response doesn't matter (provided that you have a fixed timeout of 1 second for the response), because you just need the time the trial is taking so far and add as much time as necessary to fill the intended trial duration.

  Does that make sense?

  One last remark, are you aware that the preparation time of one trial will actually add to the ITI of the previous trial rather than the current one? The starting point of a trial from the participant's point of view is when the fixation cross appeared, but all the preparation happened before that. So effectively, it will look as if the ITI of the previous trial is extended by the preparation time of the current trial.

  If the preparation times are generally similar, this problem doesn't really matter, but if there is quite a bit of variability, you would need to put your clock.sleep() command of the previous trial after then preparation time of the current trial.

  I hope I didn't confuse you too much now ;)

  Eduard