Millisecond Forums

Seems that the only solution for my problem would be if Inquisit did not clear the response queue at the beginning of a new trial.

I got word from Cedrus support. They write:

"If
you are meaning to ask if the response pads can do an “auto repeat” like the
standard keyboard does, then the answer is no. It can not send a continuous
signal if you are holding down a key. It only sends a signal upon button press
or release."

There you go.

I fear so, too, which would mean that the responsepad implements different behaviors for different output lines at the same time.

I always thought those modes only affected / applied to the box's *accessory connector*, not the box itself (cf. http://www.cedrus.com/xid/acon.htm; http://www.cedrus.com/xid/a1_set_mode.htm). I might be wrong, though. My personal knowledge of these pads is limited and I personally don't have one handy for testing.

Ok, did some testing.

The xid.XIDname.lastevent displays the last registered response, not the last actual response. This is probably due to Inquisit implementing the following control flow:

polling for response
  |
response is registered
  |
response polling stops and posttrialpause starts
  |
trial ends and pretrialpause for the next trial starts
  |
Inquisit does all preparations and as one of the final steps it clears the response queue
  |
with an empty response cue stimulus presentation starts

Huh, I just posted a longer answer to Dave's previous post but it doesn't show up. So I'll write again.

I just read into the XID protocol and looked at the abstraction layer http://cedrus-opensource.github.io/xid_device_library/d3/dfe/a00025_source.html. It offers some basic function to control an XID responsepad, such as get_next_response() and clear_response_queue(). Inquisit must be using these to control the Cedrus response pads. Apparently, my problems arise due to a very particular combination of circumstances.

(1) The XID function get_next_response() pops the oldest element from the queue, thus reducing queue length by 1.

(2) An XID responsepad offers three basic modes of signalling: continuous, pulse and doublepulse. Obviously, what I would require is "continuous" but Inquisit initializes to "pulse".

(3) Inquisit probably calls the clear_response_queue() function during trial initialization so that responses issued during the inter-trial interval are lost.

May I call on Sean Draine whether there is any way to either change (2) or (3) from within an Inquisit script?

That's interesting. Did not think about it, d'oh. I'll try that!

I was thinking more along the lines of using the lastevent property. Shouldn't matter whether said event occurred during an ITI or not. I.e. you should be able to detect a state-change in any case.

That is massively helpful! I wasn't aware that there is an XID element in v4. I'll play around with that... NOW.

My current line of thinking is:

xid.XID_cedrus.erase=0

Maybe that will do already. I'll test and report.

Those are XID devices, aren't they? If so, might be possible through the <xid> element and its properties:

https://www.millisecond.com/support/docs/v4/html/language/elements/xid.htm