Using mouse to control stimulus locations

Support
1

Hi Chris,

I’m trying to create a handmapping program where I can use the mouse to change the location of a stimulus on the screen. I can’t figure out how (or if it’s possible) to change the stimulus on the fly so the display is constantly updated rather than just at the start of the display when the display is updated. Any help is greatly appreciated.

Thank you,
Brittany

2

Attachment: RSVP_handmap.xml (56.7 KB)

3

Hi Brittany,

It is indeed possible. The attached experiment demonstrates one approach. While the experiment is running, clicking a spot on the mirror window will move the stimulus to that spot, and clicking and dragging will make the stimulus move with the mouse pointer. If you want the subject to be clicking/touching the main stimulus display, change the value of the mouse input device’s use_mirror_window parameter to NO.

The two crucial points in getting this to work are

  1. The rectangle stimulus is “wrapped” in a frame list stimulus. The rectangle is the frame list’s only frame, and the frame list is configured to loop indefinitely. The net effect is that the rectangle is redrawn on every display refresh, instead of just being drawn when needed or requested.

  2. The frame list (and thereby the rectangle) is live queued. Normal queuing “freezes” all stimulus parameters, so that any changes to, e.g., position made after queuing won’t be visible until the stimulus is de-queued and re-queued. Live queuing does not freeze parameters, so any changes will be visible on the next display update.

I actually use this technique surprisingly often to make normally static stimuli dynamic.

If you have any questions, please let me know.

Cheers,
Chris

4

Attachment: move_stim_with_mouse.xml (4.44 KB)

5

Thanks Chris. That was really easy to implement. It’s working well with
manual testing, but once I started running it with an animal I ran into two
problems. 1) After ~10 trials with eye movement and everything, the server
started freezing on me and I got the spinning beach ball. Is this likely a
result of poor handling in my program, me overloading the server, or
something else? 2) there’s an offset between the mouse and stimulus
location (not really an actual problem).

Here’s my updated program for reference:

6

Attachment: handmap.xml (57.6 KB)

7

Hi Brittany,

After ~10 trials with eye movement and everything, the server started freezing on me and I got the spinning beach ball.

My guess is that this is happening due to the “Schedule Actions” in “RSVP StartIO_state”. Every time this runs, MWorks creates a new OS thread that executes every millisecond, repeating indefinitely. While you do specify a cancellation variable (“done”), you never set it. This means that every trial adds a new, frequently-active thread to the MWServer process. Eventually, most of the available CPU cycles will go to the accumulated threads, and the rest of the MWServer process will appear to hang.

The easiest fix would be to set “done” to 1 at the end of the trial (probably in “RSVP StopIO_state”). However, a better approach would be to avoid using scheduled actions entirely, as they can use a lot of resources and get you in to trouble (as you’ve seen). If possible, I recommend using the approach from my example, i.e. attaching actions to “raw_mouse_x” and “raw_mouse_y” that set “mouse_x” and “mouse_y”.

there’s an offset between the mouse and stimulus location

Yes, while the mouse is moving, the stimulus is going to lag it a bit. There’s really no way around that.

Cheers,
Chris