|Deletions are marked like this.||Additions are marked like this.|
|Line 2:||Line 2:|
|Line 11:||Line 10:|
|However, there will be some minor changes you will have to make to most scripts to make them work correctly in the MEG lab. It is highly recommended to book and hour or so in the MEG lab to convert and test all your scripts. Contact me (Maarten van Casteren) if you need help with this.||However, there will be some minor changes you will have to make to most scripts to make them work correctly in the MEG lab. It is highly recommended to book and hour or so in the MEG lab to convert and test all your scripts.|
|Line 14:||Line 13:|
|Line 21:||Line 19:|
|Line 27:||Line 24:|
|Line 36:||Line 32:|
|Line 44:||Line 39:|
|Line 48:||Line 42:|
Converting your existing scripts to the Windows 7 version of E-Prime
We have recently updated our stimulus machines in the MEG and MRI labs to Windows 7, and this also forced us to upgrade to the latest version of E-Prime 2. E-Prime 1 will not be available on these new machines anymore.
The new version of E-Prime is not backwards compatible with the previous versions, so your scripts will have to be converted and will then not open in the previous version of E-Prime 2 anymore. In the coming months we will convert all other lab machines and all desktop machines in the unit to this new version, but currently most lab machines still use the older version.
This means that you cannot update E-Prime on your desktop machine yet if you are also running experiments in labs other than the MEG and/or the MRI facilities. The only other lab also running the new E-Prime version is the Eye Tracking Lab in room 443.
Converting your scripts is relatively easy: just open each script in the new version and E-Prime will convert it for you. It will make a backup copy of your existing script for you too.
However, there will be some minor changes you will have to make to most scripts to make them work correctly in the MEG lab. It is highly recommended to book and hour or so in the MEG lab to convert and test all your scripts.
The parallel port address has changed. If you are using the SignalData mechanism to send triggers then you will have to change the address for this. The best way to do this, at the moment, seems to ask the ParallelPort device in E-Prime for the correct address. To do this, first add a 'ParallelPort' device to your script (in 'devices') and then add the following code to your script:
Dim address as Long address = CLng("&H" & Hex(ParallelPort.Reserved1))
You can then use the variable 'address' with the 'WritePort' command to write to the correct parallel port address, just as demonstrated here:
WritePort address, 0
You can use the same variable when using the 'SignalData' mechanism:
'Enable port signal (value 1 for now) for DisplayTarget: DisplayTarget.OnsetSignalEnabled = True DisplayTarget.OnsetSignalPort = address DisplayTarget.OnsetSignalData = 1
For receiving button presses you should now use the 'Parallel Port' input device, instead of the 'Port' device. All details in the 'Parallel Port' device can be kept as by default, as the port is on 'LPT1' and this device doesn't need an address.
The old 'Port' object received the 5th button as an inverted value, so that presses showed up as releases and releases as presses. This means that you would have to look for the value '-8' if you want to respond to the 5th button being pressed. The new 'Parallel Port' device corrects for this, and all 5 buttons now come in normally.
The sound device will by default be set to 'DirectSound', but this should be changed to 'Core Audio'.
E-Prime uses a mechanism to allow objects to pre-load files before the become active, to prevent delays due to file retrieval. By setting a 'pre-release' time in the previous object, the object will be given time to prepare before the end of the previous object. Pre-release times used to be 0 by default, so you had to explicitly set a pre-release time to allow pre-loading. But in the new version the default pre-release time is set to the full duration of the object. This can cause problems. If the next object is an inline object, containing user code, it will become active at the time of pre-release and not at the end of the previous object. This can lead to unexpected behaviour, especially when the inline code uses the response gathered by the previous object, which could not be available yet at pre-release. Another serious problem with this is the fact that the OffsetSignal we often use is also triggered at pre-release. This means that the OnsetSignal and the OffsetSignal happen at the same time when pre-release is set to the full duration of the object, resulting in no trigger at all in most cases. See the SignalData section for more information.
E-Prime issues a few warnings when your script is converted. Most are not serious, but a few require some action. Here's an overview of the ones I've encountered.
'Display is cloned' This will always be issued. We use a monitor on the desk and a projector in the MSR, both showing the same picture. E-Prime flags this up as a possible problem, but this can be ignored.
Debounce value. If the paralel port has been included in your script it will not have its 'debounce' value set. Just set this to 0 and you should be fine.
Screen resolution copy. This shows up when you've set your display to copy its settings from Windows. Normally Windows should be set to the same resolution and frame rate as those recommended for you experiment, but it is better to set them explicitly. Use 1024 by 768 at 60Hz.
Clear after. Display objects usually had their 'clear after' box ticked, but that's a feature E-Prime wants to get rid of. You can ignore this for the time being, but if you want to solve this then untick the 'clear after' box and insert an extra 'TextDisplay' object after the current object. Leave this new object blank, and this will then clear the screen.
Frames in percentages. Frame values are often given in pixel values, but E-Prime thinks it is best to use percentages. You can ignore this warning.