Version 4.0
Version 4.0.5, released 02 May 2019
Technical improvements in RMVideo. Developed an alternative implementation of RMVideo conforming to OpenGL 3.3 Core Profile. During extensive testing of this and the current OpenGL 1.1-based implementation, introduced some technical improvements to the program's runtime loop in animate mode. (1) Fixed a bug that led to a slight underestimate of the RMVideo display's refresh period. Since practical trials are only a few seconds long at most, this bug did not cause problems in Trial mode. However, RMVideo may remain in the animate mode for a very long time in Continuous mode, and since Maestro was sending frame update commands too frequently due to the underestimated frame period, these commands "built up" in RMVideo's network receive buffer, resulting in an ever-growing response lag over time. One way this lag manifested itself: Upon returning to Idle mode, Maestro would terminate its RTX driver because it failed to respond to the mode switch -- because it was waiting for RMVideo to stop animating; RMVideo, in turn, was busy processing the backlog of update commands due to aforementioned bug. (2) Changed how RMVideo syncs to the vertical refresh rate of the monitor. In previous versions, the system's vertical synchronization (VSync) was disabled, and RMVideo would busy-wait (using an obscure GLX extension) for the vertical blanking interval to begin before swapping the front and back buffers. This invites the so-called tearing artifact, which we did observe on occasion during testing. [It is unlikely that the tearing artifact affected past experiments; it was only noticeable if you swept a bar-like target along the top edge of the display.] The new implementation requires that VSync be enabled, and relies on the OpenGL driver to perform the buffer swap in the blanking interval. The tearing artifact is eliminated. (3) Improved how RMVideo detects "duplicate frame" events and reports them to Maestro. The program sends a message back to Maestro every time a duplicate frame event occurs, and also sends the elapsed frame count once per second. NOTE that the updated RMVideo is still based on OpenGL 1.1, as tests demonstrated that frame drops were more frequent and severe for the OGL 3.3 implementation, particularly at refresh rates >= 120Hz. RMVideo version = 9.
Updated cxdriver IAW the changes in the communication protocol when RMVideo is in the time-critical animating state. Also introduced safeguards to ensure that Maestro neither gets ahead of (sending frame updates too frequently) nor falls behind RMVideo, both in Trial and Continuous modes.
Changes to support running RMVideo at higher refresh rates. When the RMVideo display is in a more demanding video mode like 2560x1440 @ 144Hz, it is much more likely that the occasional "duplicate frame" will occur, even for a relatively simple trial. Several changes in Maestro's operation were introduced to better handle these frame drops. (1) Maestro no longer stops trial sequencing when a trial aborts on an RMVideo frame drop. Instead, the data file is discarded and the trial is repeated (or not) IAW the rules of the current trial sequencer mode. (2) You can configure Maestro to "tolerate" as many as 3 duplicate frame events over the course of a trial without stopping it -- simply check the Allow RMVideo Repeat Frames item in the Options menu. Trials will run to completion unless a 4th duplicate frame occurs; timing information on any duplicate frames is saved in the trial data file's header record. That way, you can decide post-experiment whether or not the trial was meaningfully affected by any duplicate frames that occurred. (3) RMVideo's refresh rate is now stored in the header record in micro-Hz instead of milli-Hz. This preserves more significant digits of RMVideo's estimate of the refresh period.
Both JMWork and readcxdata() were updated to handle the aforementioned changes in the data file header record. Data file version = 22. If you use either of these utilities, be sure to update them when you install Maestro 4.0.5. NOTE: The readcxdata() output field key.d_framerate still reflects the RMVideo refresh rate in milli-Hz, even though the corresponding field in the data file's header, CXFILEHDR.d_framerate, stores the refresh rate in micro-Hz for file versions >= 22. However, since the key.d_framerate field is now a double-valued scalar instead of a 32-bit integer, the additional precision available in V>=22 data files is not lost when converting from micro-Hz to milli-Hz. It is important to have as precise a measure of the RMVideo refresh period as possible.
Minor changes to plexmon(), plexsecthist(). In more recent Matlab releases, invoking a MEX function without assigning its return value to an explicit left-hand side (LHS) variable means that Matlab invokes the MEX function with 0 as the number of LHS arguments; as a consequence, the checkfile() call in plexmon.m will always fail (the MEX function requires a single LHS arg). Modified plexmon.m to fix this issue. Removed references to the 'EraseMode' property in the plexsecthist.m script; that property is no longer supported as of Matlab R2014b.
Fixed regression bug in velocity stabilization feature: Failed to fold the bug fixes from V3.3.2 into the V4.0.0 codebase, so velocity stabilization failed to work properly.
Fixed regression bug in support for EyeLink tracker: Maestro would connect to the tracker and start recording upon entering Trial mode, but a trial would fail to start due to a tracker error. Maestro's EyeLink module was missing code that set the timer resolution to <= 1ms (removed during early, experimental stages of Maestro 4.0 development).
Version 4.0.1, released 04 Dec 2018
Added timestamp field to data file header. The 32-bit integer timestamp in CXFILEHDR.timestampMS is the elapsed time in milliseconds since Maestro (or, rather, its RTX64 partner process cxdriver) started. It marks the time at which the trial started (or a Continuous-mode recording began). The primary purpose for this timestamp is to measure the time interval between successive trials during a trial sequence. Please remember that this is a software timestamp; do not expect hardware-level precision! The timestamp is acquired immediately after starting the data acquisition sequence for the trial (or Continuous-mode recording) and just before delivering the "start" pulse via the Plexon interface module. NOTE: Data file version remains at V=21, since Maestro 4 has not yet been used extensively. The timestamp will be 0 in all data files recorded by prior releases of Maestro.
Both JMWork and the Matlab MEX function readcxdata() have been updated to handle this change to the data file format. If you use either of these utilities, be sure to update them when you update to Maestro 4.0.1.
Version 4.0.0, released 07 Nov 2018
Migrated Maestro to 64-bit Windows 10 and RTX64 Version 3.4. This update was needed because Windows 7 can no longer be installed on new workstations, and Microsoft's extended support for the OS will end in January 2020. The latest 32-bit RTX release, RTX2016, will not support Windows 10, so it was imperative to port Maestro to 64-bit Windows as well.
Legacy hardware support discontinued. Maestro 4 does not support these legacy hardware boards that were technically still supported by version 3.x: the ISA-based Listech event timer board, the M62-based event timer board implementation, the PCI-MIO-16E1 DAQ, the NI AT-TO-10 ISA analog output board, and the UEI PD2-AO8 analog output board. As of V4.0.0, Maestro requires the PCIe-6363 DAQ card from National Instruments, plus an RTX64-supported network adapter (such as the Intel Gigabit CT Desktop adapter) for communications with RMVideo.
XYScope target platform not supported. As of this release, all visual targets must be presented on the RMVideo display. To our knowledge, there are no viable XYScope displays remaining among the labs that use Maestro. Furthermore, the two hardware boards that drive the XYScope controller, the Detroit C6x and Dakar F5, are ancient PCI cards which cannot be installed in current workstations (PCI-Express has long replaced conventional PCI as a peripheral card interface). Therefore, while you can still define XYScope targets in Maestro 4, you will not be able to display them in experiments. The XYScope-related code base is being maintained in the event we find an alternative solution for implementing the XYScope display platform in the future.
Reward indicator beep uses Windows "system default sound". Testing with a subject uncovered a serious issue: playing the reward indicator beep sound on the system speaker caused trials to abort frequently on the "AI ISR latency too long" error. Further testing found that this was due to system bus hijacking that caused unacceptable delays in the RTX64 port IO read/write operations involving the system speaker port. For this reason, Maestro now plays the reward indicator beep using standard Windows audio (once upon a time we couldn't do this because audio had to be disabled to free up IRQs on the system). Be sure to attach the default system sound to a very short .WAV file, since rewards may be delivered 1-2 seconds apart in some experimental paradigms!
Fixed bug in "Import JMX doc..." feature: Floating-point numbers in the JMX document that included one or more zeros after the decimal point were incorrectly converted; e.g., "14.036" --> 14.36. This bug, of course, introduced sundry errors when importing the JSON form of a trial's segment table parameters.
Fixed bug in "Mid-Trial Reward" feature: A coding error in trial code generation, inadvertently introduced in the Maestro V3.3.0 release, had hobbled the mid-trial reward feature.
Relocated the per-user "shadow directory" for remote file operations. When the user elects to save data files across the network to a remote folder, they are first saved to a shadow directory on the local disk (because Maestro's RTX64 driver cannot access a remote file location). In prior releases, the shadow directory was located at $HOME\shadow\$USER\$DDMmmYYYY, where $HOME is the Maestro installation directory and $USER is the current user's username. As of Maestro 4, the shadow directory is at $LOCALAPPDATA\Maestro\shadow\$DDMmmYYYY, $LOCALAPPDATA is the current user's local application data folder, e.g., "C:\Users\username\AppData\Local".
Optional RMVideo "vertical sync flash". You can now configure a Maestro trial so that RMVideo will briefly flash a small spot in the top-left corner of the screen during the first video frame marking the start of any segment in the trial. Using a photodiode to detect the flash and deliver a TTL pulse back to one of Maestro's digital inputs, you will have a means of more precisely timing when a stimulus actually begins during the trial. The spot size and flash duration are document settings exposed on the Video Display dialog. To trigger the flash for any segment, set the new RMV Sync flag for that segment in the trial's segment table. This new feature, of course, required changes to RMVideo. When you migrate to Maestro 4.0.0, you will need to update RMVideo to version 8.
Updates to maestrodoc() utility. This Matlab utility lets you define a Maestro experiment document as a JSON-formatted file (.JMX extension), which can then be imported into Maestro. Both Maestro and maestrodoc() were updated so that you can define trials that utilize the new RMVideo vertical sync flash feature. In addition, maestrodoc() was (belatedly) updated to support defining RMVideo "image" targets, which were introduced in Maestro 3.3.1. See Scripting Experiments in Matlab for more information.
Minor data file format change. Added information fields in the data file header specifying the name of a trial's set and, if applicable, subset. Also included the spot size and flash duration parameters for the new RMVideo "vertical sync flash" feature. All of these fields are applicable to Trial-mode data files only. Data file version = 21, which also serves to distinguish Maestro 4.x- from 3.x-generated data files. Both JMWork and the Matlab MEX function readcxdata() have been updated to handle these minor file format changes. If you use either of these utilities, be sure to update them when you transition to Maestro 4.0.0.
A self-extracting installer is now provided. This installer handles the task of putting the program files in the directory you specify and updating the relevant registry entry that contains the installation directory path. It also better integrates Maestro with the Windows 10 Start menu, and you can even pin the application to the task bar. Furthermore, an uninstaller is included. To upgrade to a future Maestro 4.x release, simply uninstall the previous version and install the new one.
Other than the exceptions noted above, Maestro 4 has the same feature set as the final release of Maestro 3.x.