[solved] Second keyboard response not being logged...

LeeB_86

Me again (feeling like I live on this forum of late)!

I have finally dragged my experiment kicking and screaming into the working world. But... the essential responses are not being logged! I've tried various configurations for the various objects, the latest of which is below:

This is just a working file of a bigger experiment, but essentially further sessions are similar (I just find it an easier way to tweak issues without wrecking the actual experiment file).

My problem is that whilst the keyboard_response_script (and its associated keyboard_response object) log the responses ('z', 'm') very well, the cue_responses are just coming up as '0' in the relevant column of the logger file. This is the code I have for collecting responses for ongoing and cue responses (I claim no credit for the ongoing task code - not written by me, just for me):

# For the ongoing task: (corresponds to 'keyboard_response_script' in overview)

# Determine correct response, depending on whether the words come from 
# the rhyming or the non-rhyming list
if stim_pair in list_rhymes:
    correct_keyboard_response = 'm'
if stim_pair in list_non_rhymes:
    correct_keyboard_response = 'z'

# Set the correct response by giving the built-in OpenSesame variable 
# 'correct_response' a value:
exp.set("correct_response", correct_keyboard_response)

# For the cues: (corresponds to 'cue_response_script' in overview)

# Get variables from GUI
correct_cue_response = self.get('correct_cue_response')
frame_colour = self.get('frame_colour')

# Determine correct keyboard responses to session 1 cue
if frame_colour == 'Green':
    correct_cue_keyboard_response = 'g'
if frame_colour == 'Black':
    correct_cue_keyboard_response = ''

# Set the variable 'correct_cue_response' with the values determined above
exp.set("correct_cue_response", correct_cue_keyboard_response)

So either there is a bug or (more likely) my coding is wrong/incomplete. The only response not collected correctly is to the cues, so I'm guessing I've created the variables but not the ties that bind them....

I'm pretty new at this and it's had me banging my head in frustration! I've searched the forum history for similar problems, all for naught. Any help would surely save my sanity....

Thanks,

Lee

LeeB_86

...afterthought, the screenshot below shows how the variables involved are set up. The 'Green'/'g' occurs twice to represent prospective memory intentions.

The idea is that p's engage in an ongoing task (the word rhyming task) and have to respond to previously encoded cues (like the frame around the pair turning green) with a designated keypress - in this case 'g'.

Hope this makes it a bit clearer (if not I'm at this aalll day!)

sebastiaan

Hi Lee,

As a first step, I would determine whether the response is really not collected at all, or whether it is collected, but not correctly classified by the script.

Do you see a column called response_cue_keyboard_response in the log file, and does it contain sensible responses? If not, then the response is really not properly collected. In that case, I suspect this may be due to the use of the parallel plug-in, which is known to interfere with response collection on some systems (but not all, it's quite unpredictable).

If the response is collected (so if you see a sensible response_cue_keyboard_response column in the log file), then the problem is most likely in the inline script. It's not entirely clear to me what the inline script should do though. What exactly do you expect to see in the log file? And what do you see now?

Cheers!
Sebastiaan

LeeB_86

Sebastiaan,

Thanks for the reply. I did a 'quickrun' (here) with auto response and a manual full screen run (here) where I entered responses myself. Interesting results!

The quickrun recorded responses for the ongoing word pairing correctly as I expected.
The 'response_cue_keyboard_response' column in the logger contained the correct response of 'g' in various places also as expected, but the 'correct_cue_keyboard_response' column was just filled with zeros (even when the cue response was correct and it should have showed 1). Looks like a code problem...

Then I looked at the results for the manual run and found that nothing had been recorded and all responses had timed out at the 1500ms mark. So I suspect that you are also correct in saying that the parallel plug-in has stopped the keyboard responses (the 'm'/'z' responses worked fine before I tried the parallel approach).

What I would expect to see are 'm' and 'z' responses for the ongoing rhyming word-pair task as well as the 'g' response for presentations when the 'frame_colour' is green (occurs twice). I found that using one keyboard response element caused the second response to be ignored and the logger file seemed 'confused'.

Essentially I need the 'm/z' responses to be recorded independently to the 'g' responses , with all the associated timings etc...(further sessions will have more cue responses so you can see how it might get more complicated!)

I have put the main file on pastebin here so that you can seen the entire experiment, how it functions, what it needs etc... I have put session 1 as a parallel but the rest are as they were before.

Word pair files:
non_rhyme pairs.csv
rhyming pairs.csv

Thanks for the help!

Lee

sebastiaan

Hi Lee,

I think you will be better of implementing the response collection using an inline_script. It might be possible using only the GUI items, but I think this will be more trouble than it's worth.

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. If so, that keypress is stored as a response. The example illustrates how to do this with two responses, but you can easily extend this to work with three or more responses.

Is this about what you have in mind?

Cheers!
Sebastiaan

from openexp.keyboard import keyboard

# The keypress timeout
timeout = 1500

# We poll for two responses. The first 'keyboard_response_1'
# waits for a 'g'. The second waits for a 'z' or an 'm'. These
# responses can be given in arbitrary order, are stored in
# different variables, and can time out indendently of each
# other.
exp.set('keyboard_response_1', None)
exp.set('keyboard_response_time_1', None)
keylist_1 = ['g']
exp.set('keyboard_response_2', None)
exp.set('keyboard_response_time_2', None)
keylist_2 = ['z', 'm']

# Create a keyboard object that doesn't block the
# experiment, so we can use it to poll for keypresses
# continuously.
my_keyboard = keyboard(exp, timeout=0)

# Loop until we timeout
start_time = self.time()
while self.time() - timeout < start_time:
    key, key_time = my_keyboard.get_key()

    # If a key from keylist 1 is pressed, set keyboard_response_1
    # and keyboard_response_time_1. Also, set key_list_1 to [], so
    # that we do not capture multiple keypresses from this list.
    if key in keylist_1:
        exp.set('keyboard_response_1', key)
        exp.set('keyboard_response_time_1', key_time - start_time)
        keylist_1 = []

    # The same principle is applied for keylist 2.
    if key in keylist_2:
        exp.set('keyboard_response_2', key)
        exp.set('keyboard_response_time_2', key_time - start_time)
        keylist_2 = []

LeeB_86

Sebastiaan,

Many thanks for the solution. I have used the code in place of the GUI keyboard object (pastebin code). Returned a few issues when tested though...

(1) It still records the 'z/m' responses, but it's a bit hit and miss with the 'g' response.
(2) Timing isn't being recorded properly. On the test run that I did it seemed to only log a time when two keys were pressed and then it was recorded as if for the next word pair along... do you think it might just be a timing lag? (might also explain the previous point)
(3) I wrote in two variables 'correct_1' and 'correct_2' in place of the built-in 'correct'. Only the one linked to the ongoing pairs seems to work as it should, the other just returns zeros - I have no idea why as everything appears to be as it should be...

I can't see any problem with the coding above, which is why I can't see the solution!

I also was wondering how to replicate the acc and avg_rt elements in an inline script as the built-in objects wouldn't be suitable for the same reason as the keyboard element...

Continually thankful!

Lee

sebastiaan

Hi Lee,

I think the problem might be that you have set the duration of the sketchpad to 2000. This means that the experiment will simply wait for 2000 ms after the sketchpad has been presented, before moving on to the response collection script. But I'm assuming that you want response collection to start immediately after the sketchpad is shown, right? In that case, you need to set the duration to 0, so that the sketchpad doesn't block the experiment.

Cheers!
Sebastiaan

LeeB_86

Sebastiaan,

You were right, all the responses are now being collected, but apparently there is a response collection lapse... Despite my having run the experiment several times to check, the first pair is always logged as 'none, N/A... etc....' and the collection begins at the 2nd pair.
I am certain of this as I did a run where I only responded to word pairs with cues (i.e. where 2 keys had to be pressed) and while they were collected, they were consistently shown as being logged for the subsequent word pair. I thought at first it was due to my having an awful RT, but the cue-only run eliminated that possibility...

Does xpyriment have timing issues with experiments over a certain size?

Many thanks,

Lee

sebastiaan

Despite my having run the experiment several times to check, the first pair is always logged as 'none, N/A... etc....' and the collection begins at the 2nd pair

Do you mean that responses are only logged from the second trial onwards? So that first trial always appears to time out? If this is the case, it sounds like the logger is placed before the response collection script. Could that be it? Another symptom of this would be that the logged responses on trial i are actually the responses on trial i-1.

Does xpyriment have timing issues with experiments over a certain size?

Some delays may occur when there are too many stimuli to all be pre-loaded at the same time, as for example in this discussion. But those delays are relatively small and related to display presentation, not response collection. So this is probably not an issue in your case.

LeeB_86

Do you mean that responses are only logged from the second trial onwards? So that first trial always appears to time out? If this is the case, it sounds like the logger is placed before the response collection script. Could that be it? Another symptom of this would be that the logged responses on trial i are actually the responses on trial i-1.

It seems from your description that my logger might be placed too late... It is the last item as you can see, but the responses for trial i are appearing as if for trial i+1...

I thought that the logger was usually the last item? Can it be placed earlier...?

Thanks,

Lee

sebastiaan

Hi Lee,

Hmm, the logger is placed correctly, so that can't be it. The logger should indeed be the last item of the trial_sequence, unless the experiment has a very atypical structure (which yours doesn't).

I'm not sure what causes the problem, but one thing that comes to mind is that some code is placed in the prepare phase of the various inline_script items, where they should be placed in the run phase. Could that be it? I cannot be more specific without seeing the actual experiment, so if you cannot figure it out, please post the experiment as it is now to Pastebin.

Cheers,
Sebastiaan

LeeB_86

Sebastiaan,

I have the code on pastebin. I've tried everything I can think of. I still can't see the problem, I'm hoping it will turn out to be something small and fixable...

Thanks as always!

Lee

sebastiaan

Hi Lee,

As I suspected, you have placed the response collection script in the prepare phase of the inline_script item called 's1_keyboard_response'. This means that you are collecting responses before the trial has actually started, during the phase intended for stimulus preparation etc. The response collection code should instead be placed in the run phase.

This can be a bit confusing, but in general you should place 'preparatory' scripts (e.g., stimulus generation, defining correct responses, etc.) in the prepare phase and scripts that really implement the execution of the trial (e.g., showing stimuli, collecting responses, etc.) in the *run phase.

You can read more about the distinction between the prepare and run phases here:

• http://osdoc.cogsci.nl/usage/prepare-run/

I hope this clears things up!

Cheers,
Sebastiaan

LeeB_86

Solved!! OS is fantastic, but you really have to commit to learning the ins and outs!

Thanks for all the help - it really is appreciated. Just a similar visuospatial version to design now... should be far easier given that the issues have mostly been sorted now.

Thanks again!

Lee