Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Changing (removing) a text stimulus while the mouse is being tracked

Hi all,

I'm trying to realise the following design:

  • per trial, a sentence gets displayed on a word-by-word basis
  • each word gets displayed for a fixed amount of time (300ms)
  • just as with the previous words, the last word disappears from the screen after that fixed period
  • tracking of the mouse starts simultaneously with the last word of the sentence

As of now, I managed to get the first two points working (please feel free to have a look at the example experiment attached), but I'm struggling with the third. As you can see in the file, the mousetrap item is only able to start working its magic after the clock.sleep has finished. In looking for a way to display the last word and start tracking in parallel, I found that mousetrap-os is not contained in the list of items compatible with coroutines. As a result, I’m stumped with how to proceed.

Seeing as this is my first time trying to use Python, I’m sure I’m missing something really obvious here. If anyone could point out to me how to go about doing this, I would much appreciate it!


  • Hi,

    I don't like this solution as it is rather hacky and probably produces messy logfiles, but see for yourself whether it helps you. Basically, I make the last word appear in a special sketchpad linked to a special mousetrap item, lasting only for 300ms before the experiment moves on to the actual response item.

    Normally, I would try to implement it all in plain python script (as I am not used to the Mousetrap plugin), so I tried to help you, without introducing too many structural changes.


  • Many thanks for taking the time to think about this (and solving my problem)!

    I'm doubly relieved; your suggestion is definitely a workable solution, plus it's sort of nice to see that I didn't miss some really un-hacky way of doing things (with a singular mousetrap-item) 😀. And I think the resulting log files should be manageable, as mousetrap-os has a neat output anyways, timestamps and all.

    I noticed that, in the special 'last word'-sketchpad as well as in the main mousetrap item, you reduced the desired time period of 300ms to slightly shorter values, which is in keeping with the logic found in Is there a specific reason, though, why you chose 295ms for the sketchpad and 290ms for the mousetrap item?

    Again, thank you very much for your kind help.

  • Hi all,

    thanks a lot @eduard for providing a solution! I was out of office for a conference so I only checked the forum again today.

    Regarding the times < 300 ms: I think that this has to do with ensuring an accurate presentation time taking the monitor refresh rate into account - an issue that is discussed in more detail here: However, this is just a guess so please correct me if I am wrong, Eduard.

    When looking at Eduard's solution, I noticed one minor thing: I think that the duration of the lastWord sketchpad should be set to 0, as its presentation duration is already controlled by the Timeout value of the subsequent tracking_1 mousetrap_response item.

    There are probably also a number of additional fine tuning things required, e.g., thinking about whether participants should already be able to provide an answer as soon as the last word is displayed or only after it disappears (in the latter case you could set the number of buttons for tracking_1 to 0). In addition, the initiation time warning should only be displayed on one of the mousetrap_response items (if you do want to display one at all), depending on how you instruct the participants.



  • Hi Eduard, hi Pascal,

    thanks for your input and especially the helpful correction regarding the sketchpad duration!

    I'm just posting to state that the experiment containing Eduard's solution is running very nicely and the log files are easily manageable, thanks to the great mousetrap R package.



Sign In or Register to comment.