Some questions

Support
1

Hi Chris,

Hope you enjoyed your break!

Following up on where the conversation was left off. The commands were sent at the places where I intended them to be. They were also sent at the exact same places for each trial. It might be an underlying design of the laser so we will try to see if we can figure out why. But we do like configuring each channel individually as needed as it gives us more flexibility.

One question related to the new laser plugin. I think we misunderstood when the channels would be configured to “off” with the new plugin. Now we have to turn the laser on before loading the animal’s experiment. However, we realized that we might not want the laser to be on since the beginning of the session. Sometimes we only need it to be on for some of the protocols happening later in the session. Is there a way to change this? Can this configuration happen when we turn on the laser instead of when we load experiments?

Also, a few more questions on our list that are not related to the laser but these are not urgent at all!

  1. Does the time update_display() takes depends on how many things we are drawing on the screen? It seems like it takes the system longer to draw two stimuli than drawing just one stimulus.
  2. Is there a way to delete unused variable sets? We accidentally added too many new variable sets for the EyeLink starting values instead of updating the existing ones and now it’s getting confusing.
  3. With the new nightly build, we have to load existing variable sets to get the EyeLink starting values after loading the experiments. The variable set was automatically loaded with the experiments with MWORKS 0.12.2 so it was one fewer step for us to do. We are wondering if there is a way to get that back so it will make the experiments more streamlined and one less thing for us to remember at the rig.
  4. We were trying to read display distance from the system variables with the python script (codes pasted below) written by a previous tech. In the config_Vpixx (attached), we defined read_system_variables() as following:

var display_width = 0
var display_height = 0
var display_distance = 0

%define read_system_variables ()
run_python_file(path = ‘read_system_variables.py’)
%end

The read_system_variables.py looks like this (email is giving me trouble sending the original .py file but it only contains these four lines):

from mworkscore import getvar, setvar, message

main_screen_info = getvar(‘#mainScreenInfo’)
message(main_screen_info)
###display_width = main_screen_info(‘’)

Then in the protocol, I did read_system_variables() then display_distance = main_screen_info(‘distance’) but it didn’t work. How should we use this read_system_variables()?

config_Vpixx.mwel (7.47 KB)

2

Hi Taylor,

Does the time update_display() takes depends on how many things we are drawing on the screen? It seems like it takes the system longer to draw two stimuli than drawing just one stimulus.

Yes. Issuing the drawing commands for each stimulus takes a finite amount of time. The more stimuli you want to draw, the longer it takes.

But remember that the actual display update happens after update_display completes. As long as MWorks can issue all the drawing commands within a single display refresh period, the number of stimuli you draw has no bearing on when the actual display update takes place. (And if MWorks can’t issue all the drawing commands in time, you’ll see a “skipped display refresh” warning.)

Is there a way to delete unused variable sets?

Yes. Variable sets are stored in $HOME/Documents/MWorks/Experiment Storage. There’s a directory for each experiment with saved variables. Inside the experiment directory, there’s a subdirectory named Saved Variables that contains an XML file for each saved variable set. To remove a set, just delete its XML file. (You may need to close and re-open the experiment to update MWClient’s list of saved variable sets.)

With the new nightly build, we have to load existing variable sets to get the EyeLink starting values after loading the experiments. The variable set was automatically loaded with the experiments with MWORKS 0.12.2 so it was one fewer step for us to do. We are wondering if there is a way to get that back so it will make the experiments more streamlined and one less thing for us to remember at the rig.

Variable sets are loaded automatically only when you load an experiment via a workspace file that includes the variable set. If loading your workspace isn’t loading the expected variable set, then I suggest checking the workspace file to confirm that it references the correct set. (You could also create a new workspace file after loading the desired variable set manually.)

How should we use this read_system_variables()?

The Python code isn’t complete. It should look like this:

main_screen_info = getvar('#mainScreenInfo')

setvar('display_width', main_screen_info['width'])
setvar('display_height', main_screen_info['height'])
setvar('display_distance', main_screen_info['distance'])

Then, in your protocol, just use the value of display_distance as needed.

Cheers,
Chris

3

Hi Chris,

Following up on the update_display() question. Does that mean if I command the queuing of all the stimuli at a non-time sensitive state, the actual update_display() should not take different amount of time for drawing different number of stimuli?

The issue I am having right now is that for two protocols, I turn the laser on before update_display_and_wait() with the expectation that the laser would be on about 16ms before the stimulus onset.
For the protocol with one stimulus (protocol_LaserAmplitudeWithStim), in the “Stimulus On” state, I turn the laser on, queue the stimulus, and then update_display_and_wait(). The laser onset is about 20ms before the stimulus onset.
For the protocol with two stimuli (protocol_2afcLaser), in the 'Stimulus On - Pre-Saccade’ state, I queue all the stimuli first, turn the laser on, and then update_display_and_wait(). However, the laser onset is about 30ms before the stimulus onset for this protocol.
If I understood correctly, it seems like it is not the drawing commands taking a longer time for the second protocol but it is the actual update_display_and_wait() that is? I’ve attached the two protocol if that helps.

The variable set issue and the read_system_display() question are tested and resolved. Thank you!

Best,
Taylor

protocol_2afcLaser.mwel (52.1 KB)

protocol_LaserAmplitudeWithStim.mwel (16.2 KB)

4

Hi Taylor,

Does that mean if I command the queuing of all the stimuli at a non-time sensitive state, the actual update_display() should not take different amount of time for drawing different number of stimuli?

No. Like I said, update_display does some work for each stimulus, so if there are more stimuli, it will do more work. There’s no way to “pre-perform” that work.

FYI, queue_stimulus does almost nothing – it just adds the stimulus to the list of stimuli to draw. No actual drawing work takes place until update_display.

The issue I am having right now is that for two protocols, I turn the laser on before update_display_and_wait() with the expectation that the laser would be on about 16ms before the stimulus onset.

For the protocol with one stimulus (protocol_LaserAmplitudeWithStim), in the “Stimulus On” state, I turn the laser on, queue the stimulus, and then update_display_and_wait(). The laser onset is about 20ms before the stimulus onset.

For the protocol with two stimuli (protocol_2afcLaser), in the 'Stimulus On - Pre-Saccade’ state, I queue all the stimuli first, turn the laser on, and then update_display_and_wait(). However, the laser onset is about 30ms before the stimulus onset for this protocol.

I doubt the 10ms difference is all due to the additional stimuli. Even if you normally expect update_display_and_wait to take about 16ms, there’s no guarantee that it’s going to do so. It all depends on where update_display is invoked relative to the display’s refresh cycle, and you have no control over that. Sometimes the drawing will take place several frames ahead of the actual display update, so update_display_and_wait will wait for 32ms (with a 60Hz display) or longer. Other times, you’ll be drawing for the very next frame, so the wait may be less than a single refresh period. I suspect this variability is the main source of the timing differences you’re seeing.

As I’ve said previously, you’re going to have a hard time aligning the laser and stimulus timing with the technique you’re using. I think this issue is an example of that difficulty. I’d really recommend switching to the alternative technique that I’ve described elsewhere.

Cheers,
Chris

5

Hi Chris,

Thank you for the reminder of the alternative technique! We go back and forth on whether we would like the laser to be depended on behavior or run on a separate clock like dispense_juice. We will try this alternative technique and think about if and how we want to use the turn_laser_on macro in this case.

Thank you again for your help as we are exploring and figuring things out!

Best,
Taylor