 |
| The fun, inspiring scientist and his serious, literary brother. |
• As a low latency audio device
• As a response ("button") box
• As a voice volume level triggering device
• As a stimulus device (using its five multicoloured LEDs)
By that time, you will also notice my newly recovered seriousness seriously faltering, as I end the whole ordeal by ending the reviewer in classic tech style: with a conclusion featuring "grades".
Background and experiment design
According to ideomotor theory, we represent actions by their perceived consequences. That is to say, I press various buttons on my keyboard, not using constant motor programming in a stimulus (see letter) – response (write next letter) kind of manner, but by the intention of having the word on my screen prompting the action. We learn this, or so the theory goes, that actions have specific consequences, and therefore associate at some point the action with its perceived effect. The upshot is that this allows intentionality: just thinking of the intended state of affairs ought to trigger the associated action. However, it could also mean that just perceiving an effect will likewise cause us to act out the normally effect-causing actions, even if that may be inappropriate (a much better explanation of learning and action-effects can be found here).
In the present experiment, then, we try to tackle this by first asking people to play the Chronos piano freely, with each note causing beautiful tones (the well-known Windows Critical Stop). This way, actions (pressing buttons) will bring about effects (tones and lights). In the next phase, we provide a little task for the participant: a number is shown as a cue to press buttons 1-6. Finally, we ask participants to do the same thing, but now the completely irrelevant tones are played slightly before they hit the buttons. If the bidirectional link has been forged, we would expect subjects to be primed by the effects. Thus, if they are asked to perform an incongruous action, they should be lower - despite the effects not being relevant in any part of the experiment.
The convenient part of the three phases of the experiment is that it allows me to explain three modes of using the Chronos – and in particular the LEDs:
1) Use it as an alternative Echo device. Remember, this is something we sometimes use if we want to allow a subject to view whatever they type; often with questionnaires and somewhat more open questions. What if you would like to tell your subject they have succeeded in the arduous task of pressing a button on the Chronos? Yes, we just use it as an Echo device in the FreePlay part of the experiment.
2) Use task events to drive the feedback. Instead of using our conventional first-this-then-that type of coding, E-Prime 2 allows one to add event handlers to particular moments of interest defined in the experiment – such as a button press, a stimulus being shown, and so on. Conveniently, this can now be done in the graphical interface, point and click so to speak, which I suppose is nice because it allows those who feel oppressed by the abstractness of code, to just go through various menu items instead. I will go through the various pros and cons in the Action-To-Effect part of the experiment.
3) Finally, there is good old code. As mentioned, there is a bit of a documentation gap, but getting the main parts of the Chronos: buttons, voice key and audio, to work is pretty easy. This took very little to put together, but might take a bit more time to explain.
Phase 1A: Experiment structure and making some Chronos noise
The structure of the experiment is shown to the far left in the figure below. You can quite clearly spot that there are three phases (defined in the blockList), each with a text display with instructions for the particular phase of the experiment, and a TrialList type of list. The first phase is particularly simple: create a text display as shown to the right, featuring some amazing ASCII art. It is, indeed, an ASCII-piano, designed by yours truly, with a single attribute call below it, which takes Num2Play from the list. Then create the trialList (shown in the lower middle), with nothing in the Num2Play – it is actually not doing much in this part of the experiment, but it keeps things consistent (and the piano in place).
Now, to use the Chronos, and given that you have already – at least it was mentioned – added the Chronos device (Experiment Properties), just add it in the same way you would add a keyboard or mouse to the TextDisplay’s properties. As allowable, type 123456, so all defaults are covered: both the keys of the Chronos (1 to 5) and the voice key (6).
 |
| Adding Chronos as a response device |
 |
| Slide state activated by response |
StimToEff.ActiveState = "State" &
keybrdFree.RESP ‘advanced code!
State 1 to 6 have a bit of extra ASCII art: I added two circles (OO) to show which “key” is pressed. Totally unnecessary but I like the effect. The more important part is that each state plays a different audio file, each having a slightly different pitch from the classic Windows Critical Stop (see also attached file). Here, for button 4 (State4), corresponding to the F-key (or fa, if you are French), has a sound sub-object which references file critstopp1.wav (for pitch+1 tone).Now everything should work in terms of piano playing. In order to play the audio at low latency through the Chronos, go to Edit>Experiment>Devices and see the properties of the Sound device. Changing its API to Chronos will cause the audio to come from the head phones minijack - audio out. If you experience problems, you could try to change the Chronos properties, and adjust the buffers. Try as I might, though, I keep getting stuttering audio, but then again this is not my lab PC and as it happens, MATLAB and a ton of other programs are running. If you also experience problems, do let PST know.
On stutter: I'm still talking with PST support about the issue, will update as soon as we made some progress.
July 2016: The stuttering was pretty bad, and more pervasive than I thought. First, I imagined it had something to do with the plethora of other running software (e.g. MATLAB crunching numbers), which obviously isn't recommended, but I soon replicated the issue on different computers. The stuttering seemed to have been an audible sort of buffer problems (small breaks in the sound) and the experiment sometimes crashed during playback. I received several suggestions from PST as to how to address the stuttering and here I summarize the results: lowering the sample rate / channels / bitrate of the samples did not do anything, but funnily, increasing the sample rate to 48 KHz removed the problem. Adding 1 s of silence after the sample: removed the problem. Finally, most amazingly: using an attribute to call the samples (i.e. Filename property: [thesample] ) rather than directly referencing them (Filename: sample.wav) removed the problem. Why? According to PST: "When you reference a sound file in an attribute reference, it ensures that E-Prime calls the Sound.Load command before the Sound.Play command, which is something that, when calling the sound file directly, does not always happen depending on your experiment design". Right, so we shan't use the browse button next to the Filename (see lower panel in Figure above) property anymore.
Phase 1B: Light up the LEDs of the Echo Display
 |
| Echoing Chronos |
Stutter or no (with the audio just running from the normal device under the slow but reliable DirectSound API), if you are still with me, you should be able to get play the piano at this point. But, you say, how to get that groovy disco going? This is why I liked the Echo device: it just works. In the critical stimulus (the previously shown piano without feedback), go to Advanced>Echo add the Chronos and a user interface appears:
Now, pressing the 3rd button, for example, will cause the 3rd LED light on the Chronos’ to blink green for as you set the duration of the feedback display. Job done!
Extra: multiple key-presses
There are three modes, and the manual informs us that the difference is mainly visible if both presses and releases are being collected:
• Normal: turns the LED on with presses and off with releases.
• Sticky: turns the LED on with presses but not off with releases.
• Toggle: turns the LED on, if it is off, and off if it is on, but only with presses.
For each scenario, “the Echo Client life cycle matches the Input Mask life cycle", in the words of the manual, which means that if, say, a single textdisplay, with a “press 1 to start” is encountered, with duration as infinite and end action as “none”, then under normal circumstances, no matter which mode you chose, the LED will go on, and stay on. The difference will only show up clearly if you change the TextDisplay’s properties via Duration>Advanced to have a maximum count higher than 1. If you do this, you will notice:
• Toggle will start to work, with lights turning on first time pressed, and off second time.
• Sticky: will turn the LEDs on with presses, but not off, as advertised
• Normal: will do the same as Sticky. What is that? No, not only do you need to change the Chronos properties (Edit > Experiment > Devices) to collect presses and releases, but you also need to make sure the releases are actually allowable keys, changing the Allowable property to 123456{-1}{-2}{-3}{-4}{-5}. I am not entirely sure whether {-6}, which would be the voice-key’s “release” state is a thing [PST tells me it is: it corresponds to the offset of a voice key - e.g. when the participant stops talking].
Return the Maximum count to 1 before continuing.
Phase 2: A real task requires task events
In the next phase, we want to give the subject a real task rather than just hammering those keys. See below for the instructions and structure in Phase 2:
 |
| Phase 2 structure, list, instructions and piano |
First, in the List, add numbers 1 to 6 as an attribute to Num2Play, which is now actually used. Every trial, the subject first sees a fixation type screen (the same as the piano to the right, but with a dot instead of [num2play], lasting 500 ms. They are then shown a number between 1 and 6 and the subject is to press the corresponding button or tap on the table (loud enough for the voicekey to register it). There should also be feedback, as shown in the instructions.
Use the same feedback display previously created but create a new copy (control+drag) of the Keyboard. I call it keybrdA2E, and it is more or less the same as the previous type, except that 1) it should have [Num2Play] as correct button, and 2) it should not have an echo device.
Between the keybrdA2E and the feedback, a similar bit of code to the previous single line can be found:
StimToEff.ActiveState = "State" & keybrdA2E.RESP ‘Same as prev phase
If keybrdA2E.ACC = 0 Then
StimToEff.Duration = 1000
Else
StimToEff.Duration = random(100,300)
End If
Thus, if the participant reacted inaccurately, the code changes the feedback to be longer (1000 ms). This could act as a deterrent for subjects who imagine that pressing random keys will get them faster out of the cubicle; also, it makes the negative feedback shown with the LEDs a bit more noticeable.
In order to use task events, go back to the keybrdA2E, and add some actions to events. We can read the figure below as, for left, ON the event that the Chronos device for keybrdA2E is correct, DO (change) LEDColor to [green, green, green, green, green]. And, for right: ON the event that the Chronos device for keybrdA2E is pressed, DO (set) LEDStatus to [11111]. Which is to say, change all five lights to green, and turn all lights on. As one might imagine, this means I have the omission and incorrect events doing the same as the Correct, but with different colours. If you try this yourself, you will notice that this means that the lights will stay on, so it means that somewhere in one of the other objects, you should add another TaskEvent. I will leave this, and the question of how to properly show the omission event, for the reader to figure out.
 |
| Using TaskEvents for Chronos' LED lights |
The benefit in these TaskEvents is that it shows nice dialog boxes and gives a point and click feel to the whole programming experience. I remain, however, less convinced: it is never quite clear what each event does (there are about two dozen to choose from), and the actions are not very clearly documented. I used the samples now as a guide, but you can expect I will have forgotten that LEDState has a String data type and LEDColor a ParameterList by the next time I am trying to work with a TaskEvent. Programmers can be very lazy: I mean, I do not see myself digging through all the documentation to find out the same information again and again. Furthermore, the TaskEvents do not provide a lot of transparency: if I have a very complex experiment, it will be very difficult to immediately see which objects have various TaskEvents and which don’t. In fact, over the course of working the above out, I noticed that various times I was completely oblivious to the fact that my various TaskEvents were cancelling one another. In other words: I kind of prefer the abstraction level to code, the fact that I can document what I did, why and how, even if I can well imagine that some people might like the kind of interface provided by the TaskEvents.
Phase 3: More options using E-Basic
The third phase is exactly the same as the previous one from the participant’s point of view, as suggested in the instructions:
“In this part, please do exactly as you did before. You will hear some tones, but they are irrelevant.”
The reason I specifically mention this to the participant is that they are indeed not to notice the tones – they have at no point in the experiment been of consequence. So the question is whether, if a tone is played first, they will still be primed to act congruently. This phase thus has the tone and the number independently manipulated: if, say, I hear the lowest tone, which was previously associated with the left-most key (1), but I am required to press the right-most key, this should be harder than the congruent situation.
 |
| Congruent and incongruent stimuli |
So, we have 6 tones and 6 keys, therefore 36 cells in our design in terms of “manifest variables” (as explained in the E-Primer). However, 6 of these are part of the “latent variable’s” congruent condition (C) and 30 of them incongruent (I). To fix this imbalance, I changed the weight of all congruent variables to 5.
Every trial, following the previously mentioned fixation, a number is shown [num2play], but now instead of basing the feedback screen on the participant’s response using inline, I add it to the ActiveState by typing “State[Tone2Play]”. Thus, where previously the tone was played based on the response (if RESP=3 then activestate = State3), it is now retrieved from the list, and concatenated to the word “State”.
Now to again add the feedback and even do something creative, I used the following code in the selected Inline. It looks a bit more than it is, mainly because of the heavy documentation:
Dim i As Integer 'just a counter variable
Dim nblinks As Integer 'this is the number of times blinking.
'if the subject pressed correctly
If EffToAction.ACC = 1 Then
If EffToAction.RT > 2000 Then
'but they are slow, they get punished with an ugly colour and 15 blinks!
Chronos.LED.SetColor 1, Color.Yellow, 2, Color.Yellow, 3, Color.Yellow, 4, Color.Yellow, 5,_
Color.Yellow
nblinks = 15
Else
'if they are not too slow, they get only a short number of blinks.
nblinks = 5
'we go by all 5 LED lights
For i = 1 To 5
'if the button pressed is the number counted
If EffToAction.RESP = i Then
'then we turn that light (RESP = lednum) on.
Chronos.LED.SetColor i, Color.Green
Else
'we turn all other lights off.
Chronos.LED.SetColor i, Color.Black
End If
Next i
'but if the subject used the voicekey, we turn all lights on.
If EffToAction.RESP = 6 Then Chronos.LED.SetColor 1, Color.White, 2, Color.White, 3, Color.White,_
4, Color.White, 5, Color.White
End If 'EffToAction.RT
Else 'EffToAction.ACC ~= 1
'with incorrect button pressed, we tell the subject off by using a red colour.
nblinks = 15
Chronos.LED.SetColor 1, Color.Red, 2, Color.Red, 3, Color.Red, 4, Color.Red, 5, Color.Red
End If
'now that the colour and number of blinks is defined, we actually turn stuff on
'nblinks being 5 for correct, 20 for incorrect
For i = 1 To nblinks
Chronos.LED.SetState True 'we turn the lights on
sleep 10 'and wait 10 ms (ish)
Chronos.LED.SetState False 'we turn the lights off
sleep 90 'and wait 90 ms (ish)
Next i
If you go quickly through it, notice that line:
[If EffToAction.ACC .. End if]: Changes the colour and length of blinking depending on the accuracy and RT. If slow or inaccurate 15 blinks of all LEDs in respectively yellow or red. I made it a bit special with the correct and accurate button presses, so that it flashes a bit shorter and only for the button pressed: in lines [For i = 1 To 5], the code goes through all five lights, and if the number counted matches the number pressed, it changes the colour to white, while the other LEDs are turned to black. This is quite similar to the use of the LEDs as echo displays.
Notice, however, that at this point the colours may have changed, but they are not actually showing anything. Only from
[For i = 1 to nblinks .. next i] do we actually see blinking. The code does a little loop (either 5 or 15 times), with the LEDs going on (Ln 39) for 10 ms (Ln 40), then off (Ln 42) again for 90 ms (Ln 43).
I hope this amount of code does not appear either frighteningly complex or terribly simple to the reader. This is about the level of programming we normally require from a student by the end of an E-Prime course, even though most students never wrote a single line of code in their "pre-prime" life. So if you think this looks like arcane magic, it might be a good idea to re-read The E-Primer, or enter in one of the courses organised by PST, ourselves, or others. If, on the other hand, you find this all much too simple, I hope you get my point: it is very easy and fun to make the Chronos light up like a Christmas tree; it can also be extremely precisely controlled. In other words, even if your interests are more theoretically interesting than my mundane demo, you will likely not be disappointed.
Conclusion
Traditionally, tech reviewers like to give scores to various gadgets, so why not?
Aesthetics: 80. Personally, I found the Chronos' looks a bit too “Super Nintendo” for my taste, with its white, gray and blue colour scheme, rounded corners and IO expander breakout box, though I will allow that some people might be charmed by such “retro” design. There are, however, some rough edges in the finishing, such as the IO expander’s cover and that auxiliary IO cable dangling in the air like a limp proboscis. Again, I am sure competing reviewers could praise the roughness as showing signs of being “hand crafted”, and the AUX in cable as a great means of providing limitless, tentacular customization.
Ease of use: 70. I have already ranted at the documentation which we can only hope is a work in progress. In general, PST seems to spend a lot of time providing support, so if you are stuck somewhere, I would urge you to contact them. You can also try the Forum, E-Prime list, or even mailing me (though I do not promise anything). On the plus side, PST pulled off a neat trick by making it possible for one to just treat the Chronos like it was an SRBOX, so all the keys, voicekey, and so on, work as they should, and you don’t even need to worry about the COM port anymore. Which means that the tutorials in the E-Primer should (if you read Chronos for every SRBOX) also still work.
Lasting appeal: 90. Because the LEDLights are plain awesome. There are also many add ons available if the present set of keys, LEDs, and so on, is not good enough. Want a rotary potentiometer (dial)? I do not know what it is either, but it sounds very steampunk! Anyway, such things, and more can be hooked to the Chronos using the expander and IO cable, and presumably a lot more. Personally, I am hoping for a somewhat more traditional use, such as connecting the Chronos to my bog standard EEG amplifier, and hopefully I will one day learn how to do this (currently I use the normal parallel cable). Again, if only the documentation gave me a few more clues.
Timing: 100. Naturally, best in class. Furthermore, PST provides several tests on their website to show how it performs under several conditions. You can also do your own by using the photo sensor, which has its own special input on the back of the Chronos (although I have not as of yet tested this!).
Total: 85. Good timing, high quality, lots of features and multi-coloured LEDS make the Chronos a solid choice for the serious chronometrician. It should be noted that it is competitively priced, being not even that much more expensive than its aging predecessor, the SRBOX, especially if we correct for inflation related devaluation. All in all, a wonderful device that should grace every psychology laboratory out there and that will definitely make the perfect gift for your reaction timing peers and/or department.
Note: Experiment full source code and WindowsCriticalStop samples attached. See also here for a rather similar experiment by a fellow E-Prime author (great minds think alike, Rinus!).
No comments:
Post a Comment