Scripting SL or compiling .sl4

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.

Greg Shenaut

Dear Greg,

There are two features planned for version 5.0, either of which would address your dilemna. Unfortunately I cannot reveal much more at this point except to say that your email/feedback has altered a little bit the way one of these two features will be implemented.

Hisham.

MS Excel Macro

I did use excel macro to a similar task for a large number of experiments running on 1.75. Now our lab got version 4 for PC and I need to run a large number of experiments created on 1.75 for Mac. I thought I will open a dummy experiment created on version 4 as an excel file. Compare it with my exist experiments created on version 1.75 and see whether I can write a macro for such conversion. However when I try to open an experiment created on version 4 as an excel file I only get garbled characters.

Hisham, do you have any suggestion?

Best wishes,

Shafi

SuperLab 4 experiments are no longer stored as a plain text file, and thus cannot be opened with Excel.

Hi Hisham,

Please advice me how to open the SuperLab files to enter the parameters as we used to do in the earlier version using excel. Using experiment editor window will be extremely time-comsuming and will make my earlier experimental archive completely unusable. I have around 1000+ experiment files created in the earlier version.

Thanks

Shafi

Hi Shafi,

Please see my reply here:

http://community.cedrus.com/showthread.php?p=1102&posted=1#post1102

Using the stimulus list feature could really save you a lot of time.

Hisham.

Not being able to use text-file for editing experiments is a major set back for us. Are you planning to implement something similar in your future version, or something more sophistiated like the one used in e-prime?

Best wishes,

Shafi

We are planning on implementing text import for stimulus lists only in SuperLab 4.5.

Scripting capabilities

I think some sort of scripting language in general for experiment that are to complex for the feature set of SL. Something akin to E-prime. Though nothing else should be akin to e-prime, please :slight_smile: