Version 4.1

Version 4.1.3, released 26 May 2020

  • New feature - Global reward pulse multiplier. This minor release adds an additional parameter on the Fix/Reward control panel: the Reward Multiplier scales the length of any reward pulse delivered by Maestro (whether in Continuous or Trial mode). It has an allowed range of [1..5]. Unlike other settings on the Fix/Reward panel, this parameter is not stored in an experiment document (.cxe) and always defaults to 1 at startup.

  • (11 May 2021) Released a new version of readcxdata() [v410b] that exposes the per-segment fixation target designations during a trial in the function's output structure. See fields trialInfo.fix1 and trialInfo.fix2. No changes to Maestro itself.

  • (07 Jun 2021) Released new versions of readcxdata()/editcxdata() [v410c] and JMWork [v1.9.1] to increase the number of distinct "sorted spike train" channels from 50 to 100. The channel number is now defined by the first 2 bytes in the data record: the original record tag ID 8..57 in byte 0, and a "bank" ID 0..3 in byte 1. With 4 banks of 50 channels each, one can store up to 200 distinct spike trains in the Maestro data file. Since these records are appended to the original data file by analysis software, Maestro itself is unaffected by this change.


Version 4.1.2, released 10 Feb 2020

Regression bug fix. This minor release addresses a bug introduced in the 4.1.1 release that prevented it from reading experiment documents (.CXE files) created by Maestro 3.x or earlier.


Version 4.1.1, released 10 Sep 2019 (rev 04 Nov)

    • Technical changes in Maestro and RMVideo to better handle large images. (1) While assessing RMVideo's ability to present a fullscreen image on a 2560x1440 display, we found that Maestro sometimes failed to successfully download large images to the RMVideo side; Maestro would "timeout" waiting for a reply after sending a chunk of the file to RMVideo. We addressed this issue by increasing the maximum time Maestro would wait on an RMVideo reply to the commands involved in a media file download. (2) When a trial presenting one or more large images started, it sometimes aborted immediately because RMVideo took too long to initially load the image targets. We resolved this by increasing the maximum wait time for the "load targets" command. (3) However, a long load time introduces a noticeable inter-trial interval (the "load targets" command is sent at the start of every trial). Since most of that long load time was spent reading the image source file, we could eliminate the problem by caching the images. RMVideo version 10 was updated to implement an in-memory image cache that is preloaded at startup with any existing images in the media store (up to a 300MB capacity). Release "10b" is compatible with Maestro 4.1.0 and 4.1.1. If you need to work with very large image targets, be sure to upgrade to Maestro 4.1.1 and RMVideo V10b.

    • (Revised 04 Nov 19 - RMVideo V10c) Technical changes in RMVideo to improve video playback performance. Testing demonstrated that Maestro 4.1.1/RMVideo V10b could not be used to present movie trials involving videos at resolutions of 1024x768 or higher: the success rate (trial completed without any duplicate frame errors) for a 5-second Maestro trial playing a 1024x768 video was roughly 33% when the playback rate was 120Hz, and still only 56% when the playback rate was 50Hz. To address this problem, I implemented and tested a number of different strategies to boost playback performance. Two strategies offered dramatic improvements: (1) a separate "worker" thread (running at normal rather than real-time thread priority) that handles the task of reading and buffering frames from the video file; (2) using a round-robin queue of OpenGL pixel buffer objects to increase throughput when uploading video frames from the CPU to the graphics card memory. After these modifications, RMVideo can now reliably playback a 1280x720 video @ 120Hz with no duplicate frame errors over 100 repeated reps of an 8-second trial. Furthermore, the success rate playing 1920x1080 (full HD) video @ 120Hz was 96%; for two simultaneous 1024x768 videos @ 120Hz, 86%. Note that results may vary depending on the specs of the RMVideo workstation; the test results described above were obtained on a system with a 4-core 3.6GHz machine with 8GB RAM and a GeForce GTX 1060 6GB video card driving a Dell S2417DG LCD high-performance gaming monitor. If you wish to present higher-resolution videos, you will need to upgrade to Maestro 4.1.1 and RMVideo V10c.

    • New registry setting can alter timing of "latched" digital output command. Sending a command to any of the "latched" devices sitting on the DIO event timer's 16-bit digital output port involves three steps -- (a) write the command on DO<15..0>, (b) set the active-low "DataReady" latching signal to 0; and (c) after a short interval, restore the "DataReady" signal to 1. Since Maestro 3.0, a software "busy wait" of ~2.5 µs was inserted after the second step to ensure the DataReady pulse was long enough to be detected in the external DIO interface. Implementation-wise, each of the three steps involves writing to a memory-mapped register on the PCIe-6363. Recent testing in the Joshua lab has demonstrated that a register write may be delayed on the hardware, so that it happens AFTER the software has finished the busy wait. Consequently, all 3 steps can happen in rapid succession, so that the DataReady pulse is only ~100-200 ns long. While this is apparently not an issue in the Lisberger lab's DIO interface, it may be a problem for other DIO interface designs. Indeed, the Joshua lab has experienced missing marker pulses at the start of a trial (including the "record start" pulse sent to the Plexon) since moving to Maestro 4.x. To address this issue without breaking working rigs, Maestro now gives the user some control over the duration of a software busy wait after EACH step (a)-(c). The busy wait times are persisted in a Windows registry entry that the application reads at startup; they default to 0.5, 2.5 and 0.5 µs, respectively.

    • Changes to the Maestro installer. (1) When updating Maestro to a newer release, it is no longer necessary to first uninstall the application. The installer will simply update the existing installation in place. However, if you need to change the installation directory or downgrade to an earlier release, uninstall the application first. (2) The installer includes a custom wizard page by which you can set the software busy wait times for the Maestro's latched DO command (see above).

    • Sundry minor changes: (1) The VStab sliding window length parameter on Trial Mode's Other Params tab is now persisted as an application setting in the Maestro experiment document (.CXE). (2) The JSON-formatted Maestro eXperiment document (.JMX) format was updated to include the VStab sliding window length setting, as well as the ability to set the VStab "Snap to Eye" flag on a per-target, per-segment basis in any trial. The Matlab utility maestrodoc() [version 1.1.2] has been updated accordingly. Go here for details.


Version 4.1.0, released 23 May 2019 (rev 05 Jun 2019)

    • Added flicker feature for RMVideo targets. To support apparent motion studies with Maestro, any RMVideo target can be configured to flicker on and off periodically. The RMVideo target definition was amended to include three flicker-related parameters: the duration of the flicker cycle's "on" and "off" cycles, as well as an initial delay preceding the first "on" phase. All parameters are specified as a set number of RMVideo frame periods. The feature is disabled if either the "on" or "off" duration is zero. The change in the target definition required a commensurate change in the target definition record in Maestro's data file. Data file version = 23.

    • Migrated RMVideo to OpenGL3.3 Core Profile. Adopted a recently developed implementation conforming to OpenGL 3.3 Core Profile. This eliminates RMVideo's dependence on OpenGL "immediate mode" legacy functionality, which has long been considered obsolete and may not be supported in OpenGL drivers in the future. While testing suggested that this implementation does not perform quite as well as the original OpenGL 1.1 implementation, the differences are not substantial and are only noticeable when animating 3+ fullscreen plaid/grating targets @ refresh rates of 120Hz or better. In fact, the slightly poorer performance of the OGL3.3 implementation is due to a different implementation for gratings -- rather than using a multi-texturing approach, the OGL3.3 implementation puts the grating calculations in the fragment shader, which is a more intuitive solution. I may revert to the multi-texturing strategy in a later release, if necessary. RMVideo version = 10.

    • Per-trial random reward withholding variable ratio (WHVR). To support a partial reinforcement schedule in behavioral experiments, the Maestro trial definition lets you specify a variable ratio N/D for each of the two reward pulses: for every D repetitions of the trial, the reward will be withhold in a randomly selected N reps. This gives you more control over reward withholding than the global WHVR setting in the Fix/Reward control panel (the global WHVR feature should be disabled when using per-trial WHVR).

    • Both JMWork and readcxdata() were updated to handle the aforementioned changes in the data file format. If you use either of these utilities, be sure to update them when you install Maestro 4.1.0.

    • Updated maestrodoc() utility [version 1.1.1] to support defining RMVideo targets with flicker and per-trial reward WHVR in a JSON-formatted Maestro experiment document (.jmx). See here for details.

    • (Revised 05 Jun) Addressed RMVideo issues: (1) For a Random-Dot Patch target with a non-rectangular aperature (and no Gaussian windowing), dots along the aperture edge sometimes had a different color than dots fully within the aperture. This was because we had changed the aperture implementation to use an alpha mask texture, as for the Spot and Grating/Plaid target types. Reverted to the original scheme, in which the alpha component is calculated on a per-dot basis on every frame. (2) Corrected the calculation of the second RGB color for the Random-Dot Patch target's two-color contrast mode; the G and B components were always set to 0, so that the second color was always a shade of red. Only RMVideo V10 was revised; no changes were needed on the Maestro end.