Current Status

Maestro is a mature application, but it is occasionally updated to introduce new features, fix reported bugs, or make the program compatible with newer releases of Windows and/or RTX. The application also has its fair share of idiosyncracies that -- while they may impact the user's experience somewhat -- are not serious enough to merit immediate attention. Below is a list of known bugs and limitations of the program. The other pages in this chapter offer a version history dating back to Maestro's first release in 2003, plus a separate version history for JMWork, a Java application that operates on Maestro-generated data files.

Known Bugs and Other Limitations

These are all minor issues that we have no plans to address at this time. In each case, the bug could not be reproduced, there's a simple workaround to fix the problem, or the issue can easily be avoided altogether.

    1. Regarding "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 email information about the problem, especially details on what you were doing when the debug assertion was raised. Thanks! As of Version 3.0.3, Maestro is distributed as a "release" build, so you will no longer see the "debug assertion" dialog.

    2. Currently, pressing the Enter key after typing a value into any standard edit control on Maestro's user interface has no effect. The user must change the focus to another control or other element on the user interface. This is not very intuitive, but it's a minor issue and we have no plans to address it any time soon.

    3. If the user exits Maestro while in Test mode, its RTX-based driver process, cxdriver, sometimes fails to stop. It also may fail to stop if the user exits Maestro by clicking on the "X" button decorating the top right corner of the application window. If this happens, Maestro may be able to detect and terminate the "orphaned" instance of cxdriver that's still running when the application first starts up. If not, you may be able to use the RTX utility rtsskill to terminate cxdriver; otherwise, shutdown and restart the workstation.

    4. Maestro's splash screen includes an embedded log window in which status messages are displayed during startup. Occasionally, this log window fails to appear at all, so the user does not see the startup messages as they are generated. This is not a serious issue, since it does not prevent the program from coming up and since all startup messages are copied to the Message Log window any way.

    5. Unsubstantiated bug: One user tried the Randomized sequencer in Trial mode on a trial set in which one trial had a weight of 5 and all the others had a weight of 1. He observed that the weight-5 trial was presented 5 times in a row. No other users have reported such a problem.

    6. At startup, the user interface layout is not restored to its appearance at the previous shutdown. Maestro places a number of important user interface elements in docking control bars, thereby allowing the user much flexibility in organizing the GUI layout to his/her liking. The program maintains a number of settings in the registry -- on a per-user basis -- so that the layout can be restored to the way it looked the last time the user ran Maestro. Most aspects of the layout -- such as the size/location of the main frame window, the show/hide state of the various docking bars, and their docking locations -- are usually restored correctly. However, when two docking bars are docked on the same edge of the main frame window, the relative sizes of the docking bars are either not persisted or not restored correctly. This problem manifests itself when one of the two docking bars is shown after being hidden at startup. The bar that was visible at startup gets more screen space than was accorded to it the last time the user had both bars visible.

    7. Maestro may crash if the user performs certain editing operations while a trial sequence or stimulus run is in progress. Since its first release, Maestro has always let the user edit trials, targets, or other data objects while a trial sequence is running in Trial mode, or a stimulus run is being presented in Continuous mode. Cntrlx permitted this as well, and many users find it an important feature. However, some editing operations can have disastrous effects and should not be allowed during an active operational state. For example, if the user changes the identity of one of the participating targets in a trial that's part of an ongoing trial sequence, Maestro may crash the next time it tries to run that trial. Other operations that don't make sense: moving, deleting, or adding to the set of trials currently being sequenced; adding or deleting a target from an active trial's participating target list. Workaround: Users are cautioned to avoid such editing operations.

    8. Certain so-called "modal loops" in Windows -- in particular, resizing the main frame window -- can interfere with Maestro's timely servicing of requests from its partner process cxdriver. This is not a serious problem, since users do not spend a lot of time resizing windows while they are running an experiment!