| Reference | Downloads | Github

Use mouse in different routines causes a long delay



PsychoPy version (e.g. 1.85.4):

Hi! I’m working in a program for an experiment about choice (in pigeons). The animal has forced and choice trials. In a choice trial the animal can choose between two alternatives -A and B- (one ‘click’), if the animal choose A, two different images can appear (one each trial) for 30s (images have a different probability of occurrence and a different probability of reinforcement). The same is true for alternative B.
Because what happen is conditional to the initial choice, I attached an excel file with all the conditions. So, I have 4 routines after the choice routine (one per image).

Depending of the choice and the probability, the program skip the other routines. For instance: if the animal chooses B, and it’s selected S4 (routine in the picture), the program skip Splus, Sminus, and S3 routines. So far so good.

I need to record all the pecks of the animal during the images (‘clicking’ for the program). The code added to that works just fine. The problem is that, when I added a mouse in each routine (Splus, Sminus, S3 and S4) there is a long delay (around 10s) between the presentation of routine S3 or S4 and the next routine (foodreward). It does not happen if the image (and therefore routine) presented is Splus or Sminus.

I though it was the code to register clicks, but when I remove it, I still have the delay. But for instance, if I remove the mouse in S3, the delay after S3 and foodreward disappeares.

I don’t know how to fix it :frowning:


Well done, it seems like you have most of your trial procedure implemented. To find the cause of this unexpected delay, though, we’ll probably need to see your Builder .psyexp file, to be able to see the settings of your various mouse components and the effects of the custom code.


blockSelection.xlsx (8.4 KB)
CH IL1 IL2 RH sub_opt_choice.xlsx (9.5 KB)
sub_opt_TEST.psyexp (101.1 KB)
SV tl1.xlsx (9.9 KB)



Sorry for the long delay. From only a quick look at your code, I can’t pretend to understand all of the logic, but would make a recommendation that you remove anything like this from your code components:

while mouseS3.isPressedIn(S3_) and not (mouseS3.isPressedIn(background_5)):

In general Python programming terms, a tight loop like this will completely consume your CPU, strangling any other processes. This can cause unexpected delays as other processes (outside PsychoPy) finally jump in and wrest control of the CPU from you. The normal Builder drawing loop (of effectively pausing for a few milliseconds on every screen refresh) allows PsychoPy to be a good citizen and give other processes some access to the CPU.

So the consequences of these sorts of loop are two-fold:

  • you cause bottlenecks for other programs, which can then cause poor performance as they try to compete.
  • you’re also stopping Builder’s natural drawing cycle. If the conditions of your test aren’t met for a while, your effectively pausing all drawing and anything else other than this specific check for mouse presses. This means everything else that Builder normally intends to do on a frequenct cycle (checking the keyboard, redrawing the screen, checking the onset and offset time of stimuli, and so on, is being put on ice.

As a general rule, avoid putting any indefinite loops or pauses in Builder code components, as they disrupt Builder’s inherent event/draw loop cycle.

But I guess that loop is there for some reason, so you need to restructure your code to achieve the same result. Again, I’m not too sure of the required logic here, so can’t give specific advice.


Hi Michael!
Thank you for the advice! But the problem persist even when I remove all the response-related code (I was of course just testing but I actually need to record data). So, I don’t know what the problem can be.


I’m still a bit puzzled by this myself, and just realised that I don’t really understand how Builder decides when a component is finished even in normal circumstances. Some points that are unlikely related to your issues, but anyway:

  • I love looking at other people’s experiments and finding a routine called Put_bird_in_box.
  • You define circle stimuli with 999999 vertices. Nothing comes for free: these stimuli with nearly a million points are massive overkill in terms of memory required, to achieve no real advantage (i.e. the pixels on your screen have a finite size. If a circle with 100 vertices still has visible corners, then bump it up to 200, say, rather than orders of magnitude more vertices than can physically be drawn on the pixel grid.
  • I’m not sure why you call thisExp.nextEntry(). Calls to nextEntry() shouldn’t really be necessary in Builder code, as it is taking care of all of your loops and trials for you.

Those points above probably won’t fix anything related to this particular issue. So how about you post a version of your .psyexp file that works in every respect except for this mystery delay, but has had the (potentially) infinite loops removed from your code? That might help to narrow things down.


I did a simpler version checking the number of vertices and deleting most of the saving data code. I even deleted the pictures. So far, the only thing that deletes the delay in the choice loop is when I delete the mouses.

sub_opt_TEST2.psyexp (80.2 KB)

-I call thisExp.Entry() because that is what is suggested in the basic manual (

EDIT: Here is a version with only choice trials. Still the same problem
sub_opt_TESTONLYCHOICE.psyexp (70.9 KB)