Collecting responses during RSVP paradigm

Hi Mario,
This follows my previous query, which was unilaterally closed. By “looking to allocate” means the approval has to go through my supervisor and through the university finance department. My token number is JTKTU2AV-202322110417:059b4e141afb382956cd2ecd8e0f1c23f06b58088ede94174ffe9a41f7e09387

Now to the problem. I’m don’t use ListenChar or GetChar at any point during my code. To recap, I’m having the following error when calling “KbQueueStart”:

Keyboard queue for device NaN already in use by GetChar() et al. Use of GetChar and keyboard queues is mutually exclusive!

My design is an adaptation of the classical RSVP paradigm. Participant information is gathered at the beginning of the experiment on a dialog box (using inputdlg, in case that’s of any relevance). The design is as follows: I first present 7 rapidly displayed stimuli (50 ms +150 ms blank) and it is followed by a 200 ms search display. After a 150 ms blank, the experiment automatically moves to the next trial. Therefore, participant response for trial i is collected on trial i+1.

Here what I believe are the important parts of the code:

%% Initialize block
for block = 1:t_params.n_block
 %% Initialize trial
    KbQueueReserve(1,2,[]); % I was using both PsychHID and KbQueueReserve to get through the error explained above, but it seems not to be working now.

%% Start trial loop
    for trial = 1:t_params.n_trial 
%% Present 7 stimuli before Search display
        for stimuli = 1:t_params.n_stimuli 
        %Here I do the drawing and flips
%% Collect the response (for trial-1)
        while trial>0 % Response collection starts during trial 2 (for trial 1), so I skip response check on trial 1 
            if trial==1
            else % Check response
                KbQueueStop(); % Stop keyboard monitoring for response, just after (trial+1) search onset 

                [pressed,firstPress] = KbQueueCheck();
                % I collect the response data here
                %% Save trial data
                % Here I save the trial data, I need to know which key was pressed to compute accuracy
%% Present the search display
       %More drawing here
%% Start keyboard monitoring for response (just after search offset)
%%It goes back to the beginning of the loop, unless it is the last trial. Each block ends with the presentation of the 7 shortly presented stimuli
 if trial==t_params.n_trial  % In the last trial of the block, I collect the response after search display 
            %% Present last 7 stimuli
            %% Collect response for the last trial (trial ==12)
            KbQueueStop(); % Stop keyboard monitoring for response
            trial=trial+1; % This will be now trial 13, otherwise we would overwrite the response collected in trial 12 (which belongs to trial 11)

            [pressed,firstPress] = KbQueueCheck();
            % Collect the response data

end %% Block ends 

This is the design. The code crashes when it gets to KbQueueStart().
I’m using Windows 10, Matlab 2022b and Psychtoolbox 3.0.18.


Try with KbQueueCreate(), not PsychHID(‘KbQueueCreate’). The latter is not meant to be used by usercode directly

Hi dcnieho,
I had tried that before. Same error message.

I’m not near the help pages, but i guess in that case that KbQueueCreate needs a device id input. Read the help of that function. If so, all the other KbQueue functions should be passed the same device id on each invocation

Ok, license is authenticated now.

KbQueueCreate() is correct, the PsychHID variants are not meant for regular users.
KbQueueReserve(1,2,[]) must go, as its help texts says, for our internal use only.

FlushEvents('keyDown') is what triggers the error. It is non-sensical in any script that does not use GetChar() or CharAvail, and as its help text says, one should read help ListenChar carefully for the caveats and potential problems when using it. As described in the help text, use of keyboard queues is often incompatible with use of ListenChar, GetChar, CharAvail, FlushEvents. Especially on MS-Windows. This because these functions at least on Windows are implemented on top of the default keyboard queues one gets with KbQueueCreate without specifying a specific deviceIndex of a specific keyboard, this as a workaround for MS-Windows deficiencies. Another deficiency of MS-Windows is that there is essentially only the default keyboard, one can’t select individual keyboards, ie. the deviceIndex parameter does not have any effect. So in practice on MS-Windows it is always either use of keyboard queue functions or of the old GetChar/CharAvail/FlushEvents. KbEventGet, KbEventAvail etc. are modern replacements for these old functions. We have KbQueueDemo.m to demonstrate the modern ways. But in general, most flexibility is to be had on Linux when it comes to keyboard/mouse/… input.

Hope it helps.
[19 minutes of 30 minutes paid support used up].

That seemed to be the problem, thanks.