3 questions:
(1) Am I right that none of the example MWELS have code for delivering reward?
(2) While an experiment is running, is there a way to prevent the mouse cursor from entering the experimental monitor (VPixx)?
(3) As I think of more questions about writing MWELS, what’s the best way to ask them? Not sure if I should be emailing you or submitting these questions in an online thread?
Thanks!
Yasmine
Hi Yasmine,
Am I right that none of the example MWELS have code for delivering reward?
The RSVPDemo example does. Specifically:
var reward_line = false // e.g. a TTL channel
var reward = 0 {
if (reward > 0) {
play_sound (reward_sound)
reward_line = true
wait (reward)
reward_line = false
}
}
To dispense a reward, you assign the desired reward duration (e.g. 100ms) to the variable reward.
The variable reward_line would control a TTL output line that connects to the juice pump (or other reward device). For example:
datapixx viewpixx (
update_interval = 3ms
) {
datapixx_bit_output (
bit_number = 7
value = reward_line
)
}
There are other ways you could implement reward delivery, but this approach is typical.
While an experiment is running, is there a way to prevent the mouse cursor from entering the experimental monitor (VPixx)?
You can’t prevent it from entering the stimulus display window, but you can hide it when it does by including a mouse input device with hide_cursor set to YES.
As I think of more questions about writing MWELS, what’s the best way to ask them? Not sure if I should be emailing you or submitting these questions in an online thread?
Either way is fine. It’s easy for me to create discussion threads from emails, so if emailing me is easier, feel free to do that.
Also, it occurs to me that you haven’t yet taken me up on my offer to write some example experiments for you. That’s usually what I do to get new users going with their own experiments, as it gives them a useful starting point for customizing things. If you want to send me descriptions of one or two example experiments, I can code up basic versions of them in MWEL, including interfaces to VIEWPixx, EyeLink, and other hardware you’re using. Let me know!
Cheers,
Chris
Hi Chris -
I zoomed with Mariana Cardoso at NYU yesterday - and she sent me an example
MWEL to work through, but of course, it doesn’t include any
ViewPixx-related commands.
I didn’t realize that you could provide us with some example experiments.
That would be indeed super valuable/helpful - so lets do it!
From talking to Mariana, I anticipate that 1-2 of the experiments we need
are a bit trickier to implement. But to get us up and running now, I think
two examples would be particularly useful - especially if they include code
to interface with ViewPixx, Eyelink, Crist juice delivery system (digital
out pin from VPixx to BNC) - and to hide the mouse from the display screen:
(1) An eye calibration experiment. The experiment doesn’t need to sample
the entire screen - just the following x,y positions where N is a
user-controlled variable:
[0,0]
[0,+/-N]
[+/-N,0]
(2) An experiment where the animal must maintain fixation of a central
fixation point while other stimuli are presented peripherally. And if the
animal breaks fixation, the stimulus is taken away. The stimuli could be
the same images as RSVPDemo (I’ll eventually switch them out for my
geometric shapes).
Other than that I had 2 immediate questions:
(1) Does MWorks need to know whether I’m running the VPixx in the “scanning
backlight mode” or the “standard backlight mode”?
(2) I noticed that the screen distance/dimensions are stored in MWServer. I
know that MWClient has access to these variables, but they are not
displayed in the variables window. Can they be? I’m assuming that only the
variables shown in the variables window of an experiment can be saved to
the MWorks file or sent to VPixx (and ultimately to blackrock) - but maybe
that’s untrue?
Thanks!
Yasmine
Hi Yasmine,
But to get us up and running now, I think two examples would be particularly useful
Great. I will try to get these to you soon. (I may ask for some additional details as I work on them.)
Does MWorks need to know whether I’m running the VPixx in the “scanning
backlight mode” or the “standard backlight mode”?
MWorks doesn’t do anything with this at present. However, I see that the DATAPixx library includes functions for managing the backlight mode, so I could easily add support for this to MWorks.
I don’t know anything about this feature, so I’m not sure how much of this functionality you need to access via MWorks. There are basic commands to enable/disable the scanning backlight, which you obviously require. There are also functions for controlling the backlight intensity (0-255), for enabling/disabling backlight pulsing (which “can be used to make a tachistoscope by pulsing DOUT15 with a schedule”), and for setting the “8-bit unsigned phase of the VESA 3D waveform” (which looks like it matters only if you’re presenting stereoscopic images to a subject wearing 3D glasses). Do you know if you’ll need any of this other stuff, or will scanning backlight on/off suffice?
I noticed that the screen distance/dimensions are stored in MWServer. I know that MWClient has access to these variables, but they are not displayed in the variables window. Can they be? I’m assuming that only the variables shown in the variables window of an experiment can be saved to the MWorks file or sent to VPixx (and ultimately to blackrock) - but maybe that’s untrue?
They’re included in the system variable #mainScreenInfo, which you can access from MWClient’s variables window. The value of this variable is saved to the MWorks event file, and it’s certainly possible to extract the screen dimensions from it and output them to the Blackrock NSP (though, as I’ve said before, you will need to decide on a way to encode them into a sequence of 16-bit words that the NSP can record).
Cheers,
Chris
Hi Yasmine,
Quick question: Are you planning on tracking the left eye, right eye, or both? (You can always change your mind about this. I just want to know how I should set up the example.)
Regarding calibration: If possible, I’d recommend using tracker-driven calibration. This is described in the docs as well as in this discussion. In short, the EyeLink drives the calibration process, telling MWorks when and where to draw the calibration targets and computing the mapping between the raw eye camera coordinates and MWorks screen coordinates. This should be both much easier and more accurate than using MWorks’ eye calibrator, which has proved problematic for some MWorks users when applied to EyeLink’s digital outputs.
If this sounds good to you, I’ll include the necessary components in the example.
Thanks,
Chris
Hi Chris -
We are tracking the left eye (with Eyelink 1000Plus).
Today - I managed to get an animal’s eye’s somewhat calibrated with code
that has this type of function (which I got from RSVP demo):
standard_eye_calibrator eyeCalibrator_Left (
eyeh_raw = eye_lh_raw
eyev_raw = eye_lv_raw
eyeh_calibrated = eye_h_calibrated_L
eyev_calibrated = eye_v_calibrated_L
)
I have yet to try out the “linear” function Mariana uses:
//linear_eye_calibrator eyeCalibrator_Left (
// eyeh_raw = eye_lh_raw
// eyev_raw = eye_lv_raw
// eyeh_calibrated = eye_h_calibrated_L
// eyev_calibrated = eye_v_calibrated_L
// )
But it seems your recommendation is get away from that and do all the
calibration in Eyelink, yes? If so, does that mean that we set the Eyelink
calibration values in MWorks to the default 0,0 offsets and 1,1 gain at all
times? I’m totally fine with this - and would be happy to go this direction
if it’s more accurate!
Thanks - and happy Friday!
Yasmine
Hi Yasmine,
But it seems your recommendation is get away from that and do all the calibration in Eyelink, yes?
Correct.
If so, does that mean that we set the Eyelink calibration values in MWorks to the default 0,0 offsets and 1,1 gain at all times?
Actually, you can just remove the MWorks calibrator (standard_eye_calibrator or linear_eye_calibrator) entirely and get calibrated eye coordinates directly from the variables assigned to the EyeLink device’s eye_lx and eye_ly parameters.
If you want to try this out, the discussion I mentioned previously has a working example attached (eyelink_demo.mwel). When you run the experiment, MWorks prepares the EyeLink for a 13-point calibration. (You can change this with the calibration_type parameter.) It then launches the setup screen on the EyeLink PC. You use the setup screen to start the calibration; be sure to select the same calibration type as was specified in the MWorks experiment.
The calibration process is automatic. When it’s done, I think you get a chance to review and accept/reject the results. When you’re happy, exit the setup screen. At this point, the MWorks experiment will resume and should start receiving calibrated eye positions from the EyeLink.
I will integrate this stuff in to the example experiment I’m writing for you.
Thanks,
Chris
Got it. Will try this out soon - thank you!
Yasmine
Hi Yasmine,
An experiment where the animal must maintain fixation of a central fixation point while other stimuli are presented peripherally. And if the animal breaks fixation, the stimulus is taken away. The stimuli could be the same images as RSVPDemo (I’ll eventually switch them out for my geometric shapes).
I’ve attached an example implementation of this. The main experiment file (the one to load via MWClient) is example1.mwel. The ViewPIXX and EyeLink configurations are in separate files, which get included by the main file. My thinking was that you’ll probably want to reuse these with multiple experiments.
I included a scheme for sending synchronization data to the Blackrock NSP. This is mainly to demonstrate the mechanics of sending 16-bit, strobed words. I don’t know how suitable it would be for you in production. Again, I’d recommend checking with colleagues who use Blackrock and MWorks for suggestions on what to send to the recording system.
While developing the example, I fixed a few minor issues and annoyances that I encountered in MWorks. The fixes are in the current nightly build, so you should use that to run the example. (If you absolutely must use an older MWorks version, I can make a few tweaks to the experiment to work around the issues.)
Hopefully, things will be relatively self explanatory. If you have any questions, please don’t hesitate to ask!
Chris
Thanks Chris - I’ll try this out soon! I’ve been dedicating daily 5-9pm
slots to learning MWorks! 
For my info - what’s the best way to handle fresh downloads of MWorks from
the “nightly builds”?
Do I uninstall and reinstall MWorks, or simply download the files here
https://github.com/mworks/mw_suite (via green arrow)?
Thanks!
Yasmine
Adding a couple of high-level conceptual questions to my earlier email as I
learn more about MWorks…
(1) Is it typical for MWorks users to have one big “experiment” that
includes many different “protocols” rather than an “experiment” per
“protocol”?
(2) When an experiment includes several protocols, is there an easy/good
way to re-set initial values for parameters (e.g. x/y position of stimulus)
between protocols?
(3) I want to be able to edit some experimental variables from the
variables window. When an experiment includes several protocols, do you
advise creating groups of variables for each separate protocol (with
non-overlapping names between protocols)?
Thanks!
Yasmine
Hi Yasmine,
For my info - what’s the best way to handle fresh downloads of MWorks from
the “nightly builds”? Do I uninstall and reinstall MWorks, or simply download the files here https://github.com/mworks/mw_suite (via green arrow)?
Just download and run the nightly build’s installer package. (Maybe it’s not obvious, but the “Nightly build” heading on the downloads page is also a link to the installer.)
As noted in the user manual, the installer will remove any existing MWorks installation, so you don’t need to uninstall first.
Is it typical for MWorks users to have one big “experiment” that includes many different “protocols” rather than an “experiment” per “protocol”?
It’s really up to you. I think the main question is how much other stuff (variables, stimuli, I/O devices) is shared between the protocols. If there’s a lot in common, then it probably makes sense for them to be part of a single experiment.
That said, I think the idea of multiple protocols in a single experiment was much more compelling back when everything had to go in to a single XML file. With MWEL, you have the option of putting the shared stuff in separate files and including them in multiple experiments. So it’s really just a question of what makes more sense to you.
When an experiment includes several protocols, is there an easy/good way to re-set initial values for parameters (e.g. x/y position of stimulus) between protocols?
Probably your best option is to define a statement macro that resets the variables and invoke that in each protocol. For example:
var stim_pos_x = 0
var stim_pos_y = 0
%define reset_vars ()
stim_pos_x = 0
stim_pos_y = 0
%end
protocol 'Protocol 1' {
reset_vars ()
...
}
protocol 'Protocol 2' {
reset_vars ()
...
}
I want to be able to edit some experimental variables from the variables window. When an experiment includes several protocols, do you advise creating groups of variables for each separate protocol (with non-overlapping names between protocols)?
Again, I’d recommend doing what is most convenient and/or makes the most sense to you. Going back to your previous question, this might be an argument for sticking with one protocol per experiment, just to avoid confusion when multiple protocols have similar but independent variables.
FYI, in case you aren’t aware, the easiest way to create variable groups is to declare all the variables inside a single group or folder, e.g.
folder 'Stim Params' {
var stim_pos_x = 0
var stim_pos_y = 0
}
While you can also create groups by including a groups parameter in each variable declaration, that approach requires a lot more typing.
Cheers,
Chris
Great - thank you Chris.
One more Q:
Can we save/load new starting values for the EyeCalibrator window for each
animal so that MWorks doesn’t always start with the default values of
0,0,1,1? Alternatively, maybe we can save user-defined starting values in
our “workspace” along with our preferred windows/arrangement?
Thanks,
Yasmine
Hi Yasmine,
Can we save/load new starting values for the EyeCalibrator window for each animal so that MWorks doesn’t always start with the default values of 0,0,1,1? Alternatively, maybe we can save user-defined starting values in our “workspace” along with our preferred windows/arrangement?
Calibrator parameters are included in saved variable sets. If you create a separate saved variable set for each animal, then you can easily reload the calibration info for each one. You can also specify a saved variable set to load as part of a workspace, so you can simplify things further by having a workspace for each animal. (For a bit more info, see Saving and restoring client state.)
Chris