Protocol Settings and Data files
[Note: this page only applies if you are using Solo.]
Behavioral protocols that use Solo typically have two kinds of variables. First, a lot of GUI parameters that control how the protocol runs (e.g., one of these might be the duration of a white noise sound that will be played in response to an incorrect trial). Second, the protocol will also have a lot of variables that hold the data from a day's session, i.e., hold the outcome of running the protocol. We distinguish between these two, calling the first type of variables Settings and the second type of variables Data.
Settings files store, as you guessed it, all the settings variables, and are used to control the parameters for how individual rats are run. Data files are used to store the outcomes of sessions.
- Saving settings.
- If you've opened a protocol and you've set all the GUI variables to the values that you want for a subject, you can then save what is called a "Settings" file. You can do this by either (a) calling the function HandleParam/save_solouiparamvalues.m, which no one does; or (b) if your protocol uses the @saveload plugin, which every protocol in their right mind does, then you click the "save settings" button. This will create a file that holds the values of all GUIs in your protocol.
- The default filename and location for a settings file encodes the protocol, experimenter name, rat name, and date of the settings file. The default filename is:
- where yymmdd is the current day, and x is a letter that makes this alphabetically the latest file on the day. (For example, if there is no settings file for today yet, then x will be an 'a'. If there is already a file ending in 'a', then x will be a 'b'. And so on.)
- The file will be saved locally on your disk. In most setups, it will then also be automatically uploaded to the cvs repository for $RATTERDIR/SoloData, from which it will be automatically downloaded to an actual behavior rig when the corresponding rat is going to run. If you want the settings file used in a rig, you must make sure that it's been uploaded to the cvs repository.
- Loading settings.
- When you load a settings file, all the GUI parameters in your protocol get instantiated to the values in the saved file,
- On the rigs, once Runrats has determined the ExperimenterName/RatName combination that is scheduled to run in a particular timeslot, it will determine which is the most recent settings file with a date that is not in the future. Runrats will use the name of that file to determine which protocol to start up for that rat, and will then load the corresponding settings file. (Note that Runrats will run cvs update on the Settings directory for the ExperimenterName/Ratname combination (thus downloading the latest settings files that have been uploaded to the cvs server), before searching for the latest file with a date not in the future.)
- Example: suppose that for rat Carlos/C181 there are settings files 'settings_@Classical_Carlos_C181_111015a.mat', and 'settings_@DelayedOrientation_Carlos_C181_111016a.mat'. Then, for rat Carlos/C181, on the 15-Oct-2011, the @Classical protocol will be started, and the settings file ending in 15a.mat will be loaded for it before the protocol starts running. The next day, on the 16-Oct-2011, the @DelayedOrientation protocol will be started, and the settings file ending in 16a.mat will be loaded for it before the protocol starts running.
- Automated creation of settings files: At the end of each session, Runrats calls the protocol with the 'pre_saving_settings' action, and then saves a settings file. For example, suppose a session loaded settings ending in 111209a.mat. At the end of the session on 9-Dec-2011, a settings file ending in 111209b.mat will be saved by Runrats. This file will now be the most recent one, and will therefore be the settings file for the next day, on the 10-Dec-2011. But if you had yourself uploaded to the cvs repository a settings file for this rat ending in 111210a.mat, then on the 10-Dec-2011, the most recent file will be the 111210a.mat, and therefore your manually uploaded file will take precedence over the automatically generated 111209b.mat file. Thus, by uploading a settings file with the date you want, you can control whether the automatically generated files are used or not.
- SoloParamHandle callbacks when loading settings: When loading settings, for each GUI SoloParamHandle whose value changes as a result of loading settings, that SoloParamHandle's callback will get called. In addition, for each SoloParamHandle that had "callback_on_load" set to True, it calls the SoloParamHandle's callback (regardless of whether the SoloParamHandle is a GUI handle or not). The effect of this is that your protocol windows then look just as if you'd typed in all the GUI values by hand. For example, suppose that one GUI param whether a window is visible or not, and its callback controls opening and closing of the window. If you load a settings file that has a value of that param that corresponds to the window being closed, then the callback that closes the window will be called, so by the time loading of settings is done, the window will be closed.)
Data files work exactly as settings files, except (a) the files include the value of all SoloParamHandles, not just GUI ones; (b) the default file location is within the SoloData/Data directory tree. (c) Runrats automatically loads Settings files at the start of a protocol session, but never loads Data files. Need a bit more description here!