Right now SL is always case sensitive. We were having an issue with lock up and it turned out the RA was leaving caps lock down by accident. Also, if a subject accidentally hits it you get spoiled trials.
In the case of single key presses case sensitivity is rarely a good idea. So, if we could have an option to ignore it for single key responses (and that default was on) that would be a “good thing”.
I agree.
Meanwhile, a possible workaround is to take advantage of SuperLab 4.0’s ability to specify more than one correct response. So you’d create two responses, ‘a’ and ‘A’, and specify either one as a correct response in the Event Editor.
Is there any situation where case sensitivity in single-key would be desired? I’m having a hard time coming up with an idea that seems realistic. If I make it so that it’s never case sensitive, then people could still revert to string-input for case sensitivity. However, if I do this and there is someone depending on case sensitivity, it will break their experiments.
The one case I’ve seen of this is where there are normal responses made by subjects, but also “control” reponses made by the experimenter (usually via two keyboards/input devices). In that case, to reduce the chance of an accidental “experimenter” response by the subject, I’ve used upper case for the experimenter sometimes.
Control responses are things like marking experiment artifacts or verbal comments by the subject, or to go to the next trial after a programmed delay interval, things like that.
That said, at least on OS/X Tiger is possible (and should be mandatory, IMHO) to disable caps lock at the user preferences level.
Greg Shenaut
Greg,
It seems that your use of case sensitivity is really just you taking advantage of an implementation detail. If I were to completely disable case sensitivity, you could still do what you want to do by using OS X’s “Sticky Keys” feature (lock the option key instead of shift). Alternatively, you could use an MS Serial Mouse (depending on the number of different responses required). Yes, this actually works on OS X.
I never use caps lock, in fact, I usually disable it. Remember, we use VNC to monitor our SuperLab computers, so the kind of special event marking I’m talking about would generally come in that way. The use of shift keys for this is simply a stratagem so that the experiment control program can be configured to respond differently to a “q” than to a “Q”, and so we can spot them more easily in logfiles.
But yes, I’m sure we could live quite well without case sensitivity in single-key mode. In fact, since I am using an external switch-to-keyboard emulator, I routinely achieve case insensitivity by programming the switch inputs all to be digits.
Just to keep gnawing this bone, it seems to me that as much as possible, the “raw” keys should be responses in single-key mode. Therefore, alphabetics would be case-insensitive, but you would not be able to distinguish between a “5” and a “%” either, and a “shift” would be a response in and of itself. The setting of capslock and numlock, or of shift, ctrl, option, alt, fn, or any other modifier would not matter, except that each time one of those keys was pressed, it would be a response.
Obviously, in a dedicated machine, this is simple, but in a high-level OS, it can either be simple or basically impossible, depending on the API. But it seems to me that it would be the ideal method.