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, 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.
- 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 the file 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.
- 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, Runrats automatically loads the settings for you, using the default file. The default file is the one with the most recent date that is not in the future.
- 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!