| www.cortex.salk.edu | September 06, 2008 |
|
:: Style
|
The Cortex Windows Suite is a collection of Windows-based programs which allow the researcher to process data files produced by the DOS program CORTEX.EXE.
The Cortex Windows Suite code and documentation was written by Robert Baumann for the Laboratory of Neuropsychology, National Institutes of Mental Health, National Institutes of Health (Aug 1996). The program is provided "as is". Questions and comments about the program and/or documentation can be directed via email to tnorden@salk.edu.
Minimum System Requirements
The Cortex Windows WorkBench
The WorkBench gives you your first, interactive, [hopefully] graphical look at your data. Given that the primary goal of this program is to let you look at your data from all sides, it includes specific tools which can only be invoked from within the WorkBench, and are not available from the Wizard or via any other tools. The Behavior Pivot BoxOne of the behavior tools is something called the Behavior Pivot. It allows you to view behavior parameters in various groupings:
You achieve the required grouping simply by dragging the column headings left and right. You can then look at detailed information or at summary information by expanding or contracting various parts of the outline. Here is one of many possible views of behavioral information. The Behavior Summary Screen Another tool is the Behavior Summary screen, which gives you the ability to graph various behavior-related factors in trial order. You may click on one of the The other aspects of this window share the attributes of the Timing Results screen (q.v.). This window is also built in response to File | Behavior Views. The WorkBench Preferences Screen The WorkBench Preferences Screen exists to allow you to set default values for various WorkBench features. The values in this screen are read each time that the WorkBench enters execution. These preferences apply only to the WorkBench. There is no corresponding facility for the Wizard. Changes made to this screen are not saved to disk unless you specifically click on the "OK" button. The WorkBench will find and obey these settings in subsequent runs. Additionally, changes made while in the WorkBench itself (and not the Wizard) apply immediately to that executing copy of the WorkBench, regardless of whether you save the settings to disk. The Grid Window When a Cortex data file is loaded into the WorkBench, the headers for all trials in the file are displayed in the grid window. This window allows the user to:
This window is accessed by un-minimizing the Grid: Trial Record Headers icon in the main WorkBench screen. It is possible to look at the details of an individual trial by double-clicking it, which produces, for example: The Analysis and Filter Setup Window This window is accessed by un-minimizing the Analysis and Filter Setup icon in the main WorkBench screen. This is the main control window for the WorkBench. It is from this window that the user conveys to the WorkBench all of the various actions which are to be performed. These actions fall into several categories:
Pre- and Post-Filter Setup Besides the filtering provided by the standard Analysis and Filter Setup window, the WorkBench (and the Wizard, for that matter) allows you to block out a range of trials based upon their sequence in the data file. You can say, in essence, "I want to look at the first 100 trials, and only give me the correct trials in that range", or "I want to look at the first half of the trials, and within that group I want conditions 23, 25, and 27, and of those I only want the last third."
This window is accessed via File | Pre- and Post-Filter Setup. Timing Results to the Screen
When an analysis algorithm produces timing output to the screen, it is usually in a graphical format as shown above. This is the crux of the user’s ability to analyze his data graphically. The The The The The The A Raster DisplayWith a graphical result window on the screen, the user can press the A JPSTH Display Window When a JPSTH analysis algorithm send the results to the screen, the output appears as shown above. Remember that a JPSTH analysis involves comparing two PSTH results, each of which occupies one axis. A traditional JPSTH is simply black & white. In other words, a pixel is set for every intersection of spikes in the two PSTHs, and all other pixels are turned off. The WorkBench JPSTH differs from this in that every pixel actually represents a count of such intersections. By use of the Count Cutoff slider, the user can specify a minimum count value for those pixels that he wants to see. The counts computed by the JPSTH algorithm range from 0 to 255. If any spike intersection occurs more than 255 times, then the count for that intersection’s pixel remains at 255, and the Overflows count is bumped by 1. In other words, the Overflows value tells you how many intersections are not accurately represented on the graph, because they occurred too many times. Because counts are kept for each and every pixel, the total number of 8-bit counts which must be maintained in memory is A * B, where A is the size of the Y axis in milliseconds, and B is the size of the X axis in milliseconds. JPSTH graphs can therefore take up lots of memory. A 1000 x 1000 millisecond display will require a megabyte of memory. The amount of memory used by the current graph is shown in the Memory box, and is shown so that if and when you run into a shortage of memory you can intelligently chose windows to close. You can adjust the size of individual pixels with the red up/down slider control at the upper left. This can drastically improve the readability of the graph. Lastly, the colors used in the graph are determined by the graphic image immediately below the Count Cutoff slider. This image is obtained from some graphics file that is specified as part of the WorkBench Preferences screen. In other words, you can use your own custom colors for the graph simply by causing a specific file to be loaded. NOTE: The Suite comes with sample JPSTH palettes in files named JPSTH*.BMP. You can use any one of these files for the graph display palette. You can also create your own using any graphics editor, so long as you save the result as a Windows .BMP file. The JPSTH graph uses the 16 pixels along the first line in the .BMP file for up to 16 colors, from 0 (a count of zero) to 15 (a count equal to the maximum value of all counts present). To display a 4-color palette, for example, make the 1st 4 pixels in your .BMP file the same color, and the 2nd group of 4 pixels, and the 3rd and the 4th. See the sample file JPSTH_04.BMP which does this very thing. The Cortex Windows WizardThis is a high-level interface to the Cortex Windows WorkBench. You tell this program what data files, conditions, etc to analyze, and tell it whether to produce results separately or combined. It then creates a "query" which can be saved to disk, reloaded from disk later, or submitted to the Cortex Windows WorkBench (at which point you can go to lunch as the WorkBench loads file after file and produces result after result). In short, the Wizard eliminates much of what is now repetitive pointing-and-clicking in the WorkBench. A sample session might proceed as follows:
The Cortex Windows Watcher
The Cortex Windows Setup
The Cortex Data Doctor This program exists solely to allow you to apply editing changes to Cortex data files. Such changes are necessary, for example, when you have legacy data files that were not created strictly according to the Cortex data file standard. You should change your Cortex timing files so that such custom editing is not required on files produced in the future. In other words, when designing new Cortex sessions please bear in mind the sort of analysis which the Cortex Windows Suite provides, and write your timing files with the analysis in mind. Then you will no longer need to pass data files through this program. Each of the various operations which may be performed by the Data Doctor has its own setup window, which allows you to specify parameters which are meaningful to that specific operation, to wit: Of particular interest here is the operator known as Bob’s Bumper. This operator simply bumps (increments by 1) every condition number within affected records. As you may be aware, CORTEX.EXE subtracts 1 from condition numbers as it writes trials to disk. With this simple, handy-dandy operator you may undo this pernicious behavior in all of your data files! From then on, of course, what you know as Condition 1 will really be Condition 1 and not Condition 0. Miscellaneous ConceptsSpecifying timing windowsWhen performing certain analyses it is desirable to limit the visibility of data to a certain timing window. This is a period of time relative to some trigger event. It is uniquely identified via: start - a number of milliseconds before (negative) or after (positive) the trigger event.duration - a number of milliseconds Online Help: QuickTipsOnline help is provided for most applications in the Suite via a floating QuickTips window: This window serves the purpose of a traditional Tips window as seen in Microsoft Word for Windows or Microsoft Excel. In addition, this window provides real-time context-sensitive help for whatever part of the screen the mouse is over. With many windows occupying various parts of the user’s screen during a typical analysis session, the QuickTips window may become obscured, may be minimized by the user, or might otherwise not be visible when online help is desired. For this reason, every Suite application which contains a QuickTips window also contains the menu item Help | Pointer Help which when selected will make the QuickTips window visible wherever it is. When the QuickTips window is displaying context-sensitive help, you can recall the latest Tip itself simply by moving the mouse pointer over the Next Tip button. The "horse’s mouth" for information about the operation of all Suite applications is whatever is displayed in that application’s QuickTips window. Where there is a discrepancy between this document and the text of that window, it is the QuickTips window which is correct, and not this document. Here's the latest release of the Cortex Windows SuiteThis is version 15C of the Cortex Windows Suite, as indicated by Help | About. Installing this release is the same as installing any Windows app that you get off the net:
As usual with any new release, you should spend a few hours trying out the various programs with dummy, expendable data files. This is especially true for the new Cortex Data Doctor, since it changes files in-place. Look closely to be sure that the programs produce sensible results. About listbox default text filesStandard Windows listboxes are used for many of the selection tasks throughout the Cortex Windows Suite. For your convenience, many of these listboxes are loaded at program startup with the contents of ASCII text files. By editing these text files, you can cause the program(s) to start execution with listbox contents customized to your situation. Location of these filesWhen you install the Cortex Windows Suite, dummy versions of these files are installed into the same directory as the rest of the Suite. When any of the Suite programs need to access these files, they look in that directory. Contents of these filesThe exact format and use of each file varies. There are some attributes, however, which are common to all:
CODES.TXT This file is the source for the Codes listbox in the Analysis and Filters screen. This file associates Cortex timing file code numbers with text descriptions. The format of each line is: blank* number blank textblank* optional leading blank(s) number - some code number that might appear in the Cortex data file blank - one or more blanks after the number text - text that is to be associated with number Here's a sample: 0 nocode1 spike1 2 spike2 3 reward 4 bar_up 5 bar_left 6 bar_right 7 bar_down 8 fixation_occurs 9 start_inter_trial 10 end_inter_trial 11 start_wait_fixation 12 end_wait_fixation 13 start_wait_lever 14 end_wait_lever 15 start_pre_trial 16 end_pre_trial 17 start_post_trial 18 end_post_trial 19 start_pause 20 end_pause 21 start_random_pause 22 end_random_pause 23 turn_sample_on 24 turn_sample_off 25 turn_test1_on 26 turn_test1_off 27 turn_test2_on 28 turn_test2_off 29 turn_test3_on 30 turn_test3_off 31 turn_test4_on 32 turn_test4_off 33 turn_test5_on 34 turn_test5_off 35 turn_fixspot_on 36 turn_fixspot_off 37 start_fixspot_dim 38 start_up_lever 39 end_up_lever 40 start_left_lever 41 end_left_lever 42 start_right_lever 43 end_right_lever 44 start_eye1 45 end_eye1 46 start_eye2 47 end_eye2 48 turn_test6_on 49 turn_test6_off 50 turn_test7_on 51 turn_test7_off 52 turn_test8_on 53 turn_test8_off 54 turn_test9_on 55 turn_test9_off 56 start_scroll_bitmap_sample 57 end_scroll_bitmap_sample 58 start_scroll_bitmap_test1 59 end_scroll_bitmap_test1 60 start_scroll_bitmap_test2 61 end_scroll_bitmap_test2 62 start_scroll_bitmap_test3 63 end_scroll_bitmap_test3 64 start_scroll_bitmap_test4 65 end_scroll_bitmap_test4 66 start_scroll_bitmap_test5 67 end_scroll_bitmap_test5 68 start_scroll_bitmap_test6 69 end_scroll_bitmap_test6 70 start_scroll_bitmap_test7 71 end_scroll_bitmap_test7 72 start_scroll_bitmap_test8 73 end_scroll_bitmap_test8 74 start_scroll_bitmap_test9 75 end_scroll_bitmap_test9 76 start_scroll_screen_sample 77 end_scroll_screen_sample 78 start_scroll_screen_test1 79 end_scroll_screen_test1 80 start_scroll_screen_test2 81 end_scroll_screen_test2 82 start_scroll_screen_test3 83 end_scroll_screen_test3 84 start_scroll_screen_test4 85 end_scroll_screen_test4 86 start_scroll_screen_test5 87 end_scroll_screen_test5 88 start_scroll_screen_test6 89 end_scroll_screen_test6 90 start_scroll_screen_test7 91 end_scroll_screen_test7 92 start_scroll_screen_test8 93 end_scroll_screen_test8 94 start_scroll_screen_test9 95 end_scroll_screen_test9 96 reward_given 97 start_extra_lever 98 end_extra_lever 99 bar_extra 1201 cindy spike1 1301 cindy spike2 1101 cindy spike3 1001 cindy spike4 1002 cindy spike5 BLOCKS.TXT This file is the source for the Blocks listbox in the Analysis and Filters screen. This file associates Cortex timing file block numbers with text descriptions. The format of each line is: blank* number blank text
Here's a sample: 0 Dummy Block 01 Dummy Block 1 2 Dummy Block 2 99 Dummy Block 99 199 Dummy Block 199 CONDISH.TXT This file is the source for the Conditions listbox in the Analysis and Filters screen. This file associates Cortex timing file condition numbers with text descriptions. The format of each line is: blank* number blank text
Here's a sample: 0 Condition 01 Condition 1 2 Condition 2 3 Condition 3 4 Condition 4 5 Condition 5 6 Condition 6 7 Condition 7 8 Condition 8 9 Condition 9 RESPERR.TXT This file is the source for the Response Error listbox in the Analysis and Filters screen. This file associates Cortex timing file response error numbers with text descriptions. The format of each line is: blank* number blank text
Here's a sample: 00 no_error01 no_response 02 late 03 break_fixation 04 no_fixation 05 early 06 not_expected 07 before_first_test 08 no_bar_down TRIGGERS.TXT This file is the source for the Triggers listbox in the Analysis and Filters screen. This file associates Cortex timing file code numbers with text descriptions. The format of each line is: blank* number blank text
Here's a sample: 25 turn_test1_on27 turn_test2_on 29 turn_test3_on 31 turn_test4_on 33 turn_test5_on SPIKES.TXT This file is the source for the What to count listbox in the Analysis and Filters screen. This file associates Cortex timing file code numbers with text descriptions. The format of each line is: blank* number blank text
Here's a sample: 1 Spike12 Spike2 Other default text filesBesides being used to initialize listboxes, there are ASCII text files which convey other custom information to the various programs. FILTERS.TXTWhen you use the Cortex Windows Suite File | Open dialog box (which, by the way, is different from the standard Windows one), you may specify what type of files are to be displayed in the list of files available to open. This is known as filtering the list. The drop-down list box of various filters is initialized from the ASCII text file FILTERS.TXT. The default filter that is displayed is the first one in the file. The format of each line is: pattern blank text
Here's a sample: *.* All Files*.0;*.1;*.2;*.3;*.4;*.5;*.6;*.7;*.8;*.9 Cortex data files *.flt Filtered Cortex files CINDY.* Cindy's CORTEX files DOC_OP2A.TXT This file defines the default list of Condition/code combinations which are presented for your selection when using the Cortex Disk Doctor operator #2 (Reynold's Replacement). The format of each line is: blank* cond blank code
Here's a sample: 0 231 24 2 25 DOC_OP3A.TXT This file defines the default list of Condition from/to combinations which are presented for your selection when using the Cortex Disk Doctor operator #3 (Condition Changer). The format of each line is: blank* old blank new
Here's a sample: 6 75 6 4 5 3 4 2 3 1 2 0 1 Notice that this list appears to be in reverse order. This is usually what you want. If these lines appeared in the opposite order, then all conditions from 0 to 6 would wind up being changed to 7. Can you figure out why? DOC_OP1Z.TXT DOC_OP2Z.TXT DOC_OP3Z.TXT DOC_OP4Z.TXT These files are part of the screen display for each possible operator that is supported in the Cortex Data Doctor. They are not meant to be edited by the user. Doing so will corrupt the Data Doctor. Frequently Asked Questions
Question: In my conditions file, I have 260 conditions numbered 1 to 260. Your program shows that the CORTEX.EXE output lists conditions 0 to 259. Apparently, CORTEX.EXE is subtracting a number, and GRAST61.EXE is adding it back. Question: Does condition 0 get translated to condition 1 when the data are output to xl? I had previously determined that cond 0 was cond 1 in our cortex parlance, but now I'm not so sure anymore. Answer: This is what is known as a "legacy software" problem. In other words, the "old" cortex support packages (your legacy from DOS days) assume that CORTEX.EXE subtracts 1 from condition codes, so they add it back in. This creates what is known as a dependency between those support programs and CORTEX.EXE. The more dependencies there are in your software base, the more complex is the software maintenance and development task. There's a new Windows version of Cortex coming down the pike. If we write it to subtract 1 from condition codes, then any and all Windows support programs must "remember" to add 1 back in. If we do not, then the old DOS support programs will be 1 off, because their [questionable] assumption is no longer valid. The Cortex Windows WorkBench shows exactly what's in the data file. It doesn't fake anything. This is invaluable when it comes to validating an input file, which is one of the most important uses for the WorkBench. Nobody has to say "Gee, I wonder if somebody added 1 to my condition codes...". What you see is what's in your data file. Become intimately familiar with it. As the guy who will inherit and have to maintain all of this software, I see no reason to keep unnecessary complications. Necessary complications make things hard enough. My vote would be to make the new Windows Cortex not subtract 1 from condition codes, since it doesn't do it for any other numbers. Then everything will be nice and simple, and what you see is what you get, and so on... In the meantime, I have developed the Cortex Data Doctor which - serendipity strikes! - will (among other transforms) add one to all condition numbers in your data files. You can then use these files with the various Suite programs with the conditions "correct".
Question: I seem to be having consistent problems whenever I try the "export to text file" or "export to clipboard" features. Answer: Analysis of your situation shows that you have so many records in your data file that the resulting text representation of your Grid is too large for Windows to handle in one "gulp".
Question: If I try to create a query with 6 files and 24 separate conditions files, I get a "out of string" space error, and the wizard quits. I looked at this a little further, and see that it's an interaction between the number of files, conditions, spikes, etc analyzed "separately". So the program quits when the query file gets "too big"? When I try to reproduce the crash, sometimes the program doesn't crash, it just doesn't do anything when you try to build a query. I would like to know what this limit is, and also mention that whatever it is, people are going to want to run analysis that will surpass it. Answer: You're right. It's the number of combinations of separate analyses which determines resource requirements. And it is very easy to generate a query with, say, 6 data files, 8 conditions, 2 response errors, 4 triggers, and 2 count items, which - if all are done separately - yields 6 x 8 x 2 x 4 x 2 = 768 analyses! If they were all combined, they would generate only one analysis. In the meantime, do things in smaller pieces. Instead of requesting combinations which call for, say, 128 analyses, you can always perform exactly the same action as two 64-analysis queries. Doing things this way should allow you to achieve your goals until I can address and solve the larger problem once and for all. NOTE: This has been fixed with Release 15A, in which the size of the query is essentially unlimited.
Question: While trying to run the analysis on several queries (I saved 12 queries for the 24 conditions I need to analyze), after running two queries, when I tried to run a third, I got a "out of memory" error and the program wouldn't run any more queries. I've attached the "watcher.sav" file to this document. Also, after this crash, I couldn't access the microsoft networking anymore until after I quit XL. Answer: This particular event is an instance of the "out of resources" problem, which occurs in many places and which I am addressing. Thank you for attaching the WATCHER.SAV file. It shows me exactly what happened on your system in this instance, which, in a nutshell, is as follows:
In order to keep Excel from gobbling up memory that may be needed to hold Cortex data files, I intentionally designed the WorkBench to not start Excel until all analysis was done, and then to start Excel and pass all results to it. Now that we have some hands-on experience, it seems fair to say that Windows resources are the scarce item here, not RAM. So I shall change the WorkBench to output each Result window to Excel as soon as it is calculated, and then to release that Result window (and all of its resources) back to Windows. In the meantime, do things in smaller pieces. Instead of requesting combinations which call for, say, 128 analyses, you can always perform exactly the same action as two 64-analysis queries. Doing things this way should allow you to achieve your goals until I can address and solve the larger problem once and for all.
|
buttons to see on the graph at right a distribution of Conditions, Blocks, or Response Errors. You may also select various combinations of Conditions, Blocks, or Response Errors in the list boxes, and then click on the Rebuild button to update the large graph with only the trials which match all selected listbox entries. 
boxes allow you to display rates as an average per trigger or as a raw count, and to scale counts as counts per second (i.e. - a firing rate) or as raw counts. 
buttons allow you to change the type of graph which is displayed. 
button (if enabled) allows you to view the Raster Display for this analysis. 
box enables you to select a bin size for the graph columns. 
box (which can be scrolled to see hidden text lines) describes all selection criteria which went into this analysis. This information follows the graph data if it is ever exported to a file, or to Excel. 
button exports the results to a text file, the 
button exports them to the Windows clipboard, and 
exports them to the Excel spreadsheet WRKBENCH.XLS
Questions or problems regarding this web site should be directed to CortexSite@salk.edu.