No more "debug assertions"! Since it was first released, Maestro was built in a "debug" configuration to help catch bugs as "debug assertions". When such as assertion is detected, a popup dialog indicates the problem and asks the user to "Abort", "Retry", or "Ignore". Starting with this version, Maestro is now delivered in a "release" configuration. The executable is faster and about one-third the size, and you'll no longer see those "debug assertion" dialogs.
Bug fixed: I've received a number of complaints about a "debug assertion" occurring when you try to open a file in the "most recently used" (MRU) list under the File menu. I've only experienced this issue when opening an MRU file hosted on a mapped network drive; it may be caused by intermittent failures in accessing volume information for that network drive. Now that Maestro is built in the "release" configuration, the debug assertion won't happen, although the underlying problem remains. If the first attempt at opening an MRU file fails, Maestro tries once more before giving up. If you keep the Messages window open, you'll see a warning message: "Failed to open file; trying again..." If the second attempt also fails, a dialog is raised to inform the user. In this case, try to open the file via File|Open...
Bug fixed: Maestro can easily crash if you try to open a new experiment document (.cxe file) while in any operational mode other than Idle. For this reason, file operations were disabled except in Idle mode. However, the most recently used (MRU) files listed at the bottom of the File menu were still enabled, and as a result a number of users were crashing the program when they selected one of these MRU files while in Trial or Continuous mode. Now the MRU file items are disabled when not in Idle.
Changes in terminal behavior when a trial stops prematurely on a runtime error or a user-initiated abort: (1) The animal is no longer rewarded. (2) The data file is never saved (it was saved in the case of a runtime error, such as an RMVideo frame drop, if the failsafe segment was reached). (3) When trial stops due to an RMVideo error -- most likely a frame drop --, the error information in the Messages window will indicate how many RMVideo errors have occurred since startup.
The duration of a single trial segment can be as high as 32000ms instead of 9999. Keep in mind, however, that overall trial duration cannot exceed 32760ms, due to a constraint in how Maestro communicates a trial's definition to its RTX driver process. Maestro will stop a trial sequence upon detecting a trial that is too long.
[09 Sep 2013] Revised readcxdata() and editcxdata() to support 50 distinct "sorted-spike train" data channels in the Maestro data file. Prior to this change, only 13 such data channels were supported. These channels can be appended to the data file in JMWork, or in your own Matlab analysis code via editcxdata(). The main motivation for this change was to make it possible to store spike trains from all of the different neural units recorded on the Plexon during an experiment. When recording with several electrodes, it is possible to monitor more than 13 different units simultaneously. Maestro itself is unaffected by this change.
Bug Fixed: A debug assertion occurs when using the "file edit control" (the edit control with a browse button that raises a file chooser dialog) in the Trial Mode control panel. Even if you "Ignore" the problem, Maestro no longer works and you have to restart the computer to get things working again. This is due to an internal error in the new file dialog introduced in Windows Vista and carried over to Win 7. The wise folks at MS have not fixed it. To work-around the problem, I've disabled the Vista-style file dialog so that Maestro uses the older style. It looks old, but at least it works.
Bug Fixed: Trial using RMVideo targets aborted on a "fixation break" just before the start of a segment in which the fixation target jumped suddenly in position. This "regression" bug was introduced when I modified Trial Mode so that target trajectories are computed on the fly during trial runtime rather than being precomputed before the trial starts. Because Maestro sends RMVideo the update for video frame N+2 at the start of frame N, I had to keep track of each RMVideo target's current "displayed" position, and its position for the next two frames. Due to a logic error in this buffering mechanism, the current "displayed" position was actually the position during the preceding frame. Thus, in the particular situation that exposed the issue, Maestro "thought" the fixation target jumped during the last frame of the preceding segment, when the eye was supposed to fixate the target at its original position -- and so a fixation break was erroneously detected.
Bug NOT Fixed: Occasionally, when you open an experiment document by selecting an entry in the "most recent files" list in the File menu, you'll get a "debug assertion" in line 1003 of docmgr.cpp. Unfortunately, the problem lies inside the MS doc-view framework on which Maestro's GUI depends, and I have been unable to engineer a fix. However, it seems to arise only when opening a file on a mapped network drive -- so you may never see it. Also, you can safely "Ignore" the assertion, and Maestro continues to work properly, although the file you tried to open will no longer appear in the recent files list. To open it, use the File|Open command instead.
More on "debug assertions" in Maestro. Since its inception, Maestro has been released as a "debug" build to help catch coding errors. When one of these occurs, Windows raises a popup dialog that describes the issue and asks you to Abort, Retry, or Ignore. When this happens, please write down the details of the problem (or take a screen snapshot of the alert dialog), then choose the Ignore option. Some of the assertions are benign, and Maestro will continue to work despite them. However, if you have uncovered a more serious bug, Windows may be unable to recover from the error. In either case, please send me information about the problem, especially details on what you were doing when the debug assertion was raised. Thanks!
Bug Fixed: Computed fixation target velocity (not position) was very "jumpy" in the initial 3.0.0 release for RMVideo targets. Users must keep in mind that RMVideo targets are only updated once per display frame, NOT every millisecond. Thus, computed target trajectories -- particularly, a velocity trajectory -- will have a sample-and-hold appearance because velocity is constant over a single display frame, which is on the order of 12 milliseconds or less. Also, because the RMVideo display frame is not generally a multiple of 1ms (the analog scan interval in Trial mode), expect some variation in the displayed RMVideo target position and velocity trajectories over repeated presentations of the same trial. This is because the RMVideo frame updates do not occur exactly on scan interval boundaries.
Migrated Maestro to Windows 7 and RTX 2011.
Implemented AI, AO, and DIO event timer device functionality on a single physical device -- the PCIe-6363 from National Instruments. While Maestro 3 still technically supports various legacy hardware used in Maestro 2, these have not been thoroughly tested. Labs interested in adopting Maestro 3 are strongly encouraged to purchase new workstations (Windows 7 32-bit OS, RTX 2011, Intel quad-core or better motherboard) and employ the recommended hardware configuration: the PCIe-6363 and the Intel Gigabit CT network adapter for communications with RMVideo. If support for the XYScope display platform is required, be sure the workstation has at least one PCI slot and use the Detroit C6x DSP card.
Support for the following is discontinued: optic-bench targets (Fiber1, Fiber2, REDLED1, REDLED2); the fixed-length reward pulse delivery module (which also controlled the shutters for the fiber-optic bench targets).
Bug fix: During testing of Maestro 3, identified a coding error that prevented the detection and reporting of an RMVideo frame-drop or duplicate-frame error during a trial. The bug is fixed in this initial version, but there was some concern that missed frames would invalidate data collected in trials by past versions of Maestro. It is highly unlikely that such errors were routinely occurring; for one thing, the animal's behavior would have been affected. The error was found only because the RMVideo machine on which I was testing was not properly configured to ensure timely network performance and so exhibited excessively long network delays. When testing the bug fix with an RMVideo workstation from one of the Lisberger lab rigs, no frame errors occurred over a trial sequence lasting more than an hour.
In the process of fixing the above bug, we made some changes to the RTX-specific priorities assigned to various threads in Maestro's hardware interface controller process, cxdriver.rtss, and the RTX TCP-IP stack. The main worker thread in cxdriver.rtss now runs at priority level 50, while the file writer thread runs at 45. The AI interrupt handler runs at maximum priority = 127, while the timer handlers for suspend management and the speaker beep run at 126. The timer, interrupt and receive thread priorities for the RTX TCP-IP stack are now set for 66, 64, and 63, respectively. The most important point is that the TCP-IP thread priorities should be greater than that of cxdriver's main worker thread, and that the TCP-IP interrupt thread be prioritized over the receive thread.
Minor changes to maestrodoc() utility: Documentation updates IAW changes introduced in Maestro 3, such as the elimination of the optic bench targets and the Predefined target set. The maestrodoc('chancfg',...) operation now recognizes generic AI channel IDs like 'ai0' in addition to the use-specific IDs like 'hgpos'.
Update to readcxdata: Now supports emulation of RMVideo-based noisy-dots targets in addition to XYScope noisy-dots targets (but not both in the same trial, which is impossible). Relevant output fields are still named xynoisy and xynoisytimes to avoid breaking existing analysis scripts, but xynoisy now includes two additional fields, x and y, that hold the (X,Y) position trajectories of every target dot for RMVideo targets only (it is not possible nor practical to reproduce per-dot position trajectories for XYScope noisy-dots targets).