We are wrestling with a complex design of a lexical decision priming experiment that must be counterbalanced between subgroups of subjects and within subjects between blocks. The stimuli are text strings. We use shell scripts to create several counterbalancing stimulus sets and split each one into a prime list (with several prime types) and a parallel target list (with several target types). It is straightforward to import these lists into SuperLab events, but as near as we can tell, the stimulus codes have to be selected by hand for each item in each prime list and each target list from within SuperLab. Just in our preliminary testing, we have seen several data entry errors, and this doesn’t surprise me given the number of things that have to be done to load in the stimuli for each permutation of the counterbalancing scheme.
It seems to me that there are two ways that this problem could be solved, one easy, and one hard in terms of development.
The hard way would be to use applescript. That is, for SL to grow a set of scripting functions that would allow us to automate experiment setup. The even harder way would be to use UI scripting; as far as I know, this could be done with no change to SL, but it would be fragile and vulnerable to changes in the SL user interface. I’m speaking here as someone with virtually no applescript experience, so anything with applescript in it is “hard” by definition.
The easy way would be to specify the .sl4 file format. This could be done directly, by specifying each bit, record, and field in the file, or it could be done indirectly, by providing a utility that could compile unicode text into .sl4 files. In the second case, all that would need to be specified would be the format of the unicode text file.
Personally, I prefer the sl4 compiler approach so much that if I had a copy of a detailed specification of the sl4 file format, I would probably write one myself, so in that sense, the two “easy” options are equivalent.