From Susie.Williams at Vanderbilt.Edu Thu Oct 2 16:48:24 2003 From: Susie.Williams at Vanderbilt.Edu (Susan Williams) Date: Thu, 2 Oct 2003 11:48:24 -0500 Subject: feedback object Message-ID: Hello, I'm hoping to program for an image to be displayed (800ms) and an immediate wait time (2200ms) between stims while collecting particpant responses. I'm also hopeful that a feedback object will respond to partcipant responses (in essence, to get the feedback object to respond to 2 different objects) and for the experiment to continue. Have any suggestions? Thanks, Susan Susan M. Williams susie.williams at vanderbilt.edu Vanderbilt-Kennedy Center Peabody Box 40 Vanderbilt University Nashville, TN 37203-5701 615) 322-1324 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstieben at yorku.ca Tue Oct 7 21:30:33 2003 From: jstieben at yorku.ca (Jim Stieben) Date: Tue, 7 Oct 2003 17:30:33 -0400 Subject: Looking for a Flanker task Message-ID: We are looking for a version of the flanker using faces. If anyone would be willing to share this, we would be most appreciative. Thanks Jim Stieben University of Toronto -------------- next part -------------- An HTML attachment was scrubbed... URL: From mconroy at ucsd.edu Wed Oct 8 21:43:16 2003 From: mconroy at ucsd.edu (Matt Conroy) Date: Wed, 8 Oct 2003 14:43:16 -0700 Subject: Pausing and Resuming during a procedure Message-ID: I am creating an experiment that requires subjects to orally identify visual stimuli, which are presented sequentially. I want to make a subject input that can pause the stimulus presentation (during which the current stimulus remains on the screen indefinitely) and a second input that causes the stimulus presentation to resume normally. It is important to record the time of these inputs, or the stimulus during which they occurred. Thank you for any advice. Matt Conroy Graduate Student UC San Diego Psychology Dept mconroy at ucsd.edu From anthony.zuccolotto at pstnet.com Thu Oct 9 12:37:13 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Thu, 9 Oct 2003 08:37:13 -0400 Subject: Pausing and Resuming during a procedure Message-ID: Matt, I would recommend trying something like setting your stimulus duration to 0 and then running a Wait object immediately after the object. The Wait object will not alter the display when it runs but can collect an input. You should then probably write some script to examine the Wait.RESP property to determine if the input that came in is your pause/resume key. If so, you can then run another Wait object, or possibly use the goto command with a Label placed above the Wait object to rerun the current object. Note though that if you use Goto statements and labels to jump execution around in the trial procedure you should take care to make sure all the relevant attributes you need to log to the data file are updated to current values (e.g. call c.SetAttrib "name", "value" as needed to update attributes in the context) and then call c.Log sometime prior to the goto. The c.Log call will cause a new row to be generated in the data file with all the current attributes. Normally you don't have to do this because a c.Log call happens automatically at the end of the trial procedure, but if you start jumping around then you typically must make some calls yourself to assure all the data you are interested in gets logged. Another approach to consider would be to use two different input masks on the same stimulus presentation object. For example you could create a keyboard mask and set 1 and 2 as allowable response keys for the stimulus, but then create another keyboard input mask on the same object with P (for pause) as the only allowable key. The first input mask can be set to terminate, and the second one can be set to Jump to a specific label. You then put script after the label to do whatever special processing is required to implement a pause/resume feature. Hope that gives you some ideas to try out. You might need a few lines of script to accomplish what you want, but you should definitely be able to implement this in E-Prime. Thanks, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Matt Conroy [mailto:mconroy at ucsd.edu] > Sent: Wednesday, October 08, 2003 4:43 PM > To: eprime at mail.talkbank.org > Subject: Pausing and Resuming during a procedure > > I am creating an experiment that requires subjects to orally identify > visual stimuli, which are presented sequentially. > I want to make a subject input that can pause the stimulus presentation > (during which the current stimulus remains on the screen indefinitely) and > a > second input that causes the stimulus presentation to resume normally. > It is important to record the time of these inputs, or the stimulus > during > which they occurred. > > Thank you for any advice. > > Matt Conroy > Graduate Student > UC San Diego Psychology Dept > mconroy at ucsd.edu > > From bmb at buffalo.edu Sun Oct 12 20:07:41 2003 From: bmb at buffalo.edu (Breton M Bienvenue) Date: Sun, 12 Oct 2003 16:07:41 -0400 Subject: e-prime and eyelink? Message-ID: Greetings, I'm wondering if anybody has managed to interface e-prime and the SMI eyelink headmounted eyetracker? I know there used to be plugins for the psyscope system to interface with the eyelink. Is anybody doing anyhing like this? Thanks. -------------------------------------------------------------------------- Breton Bienvenue e-mail: bmb at acsu.buffalo.edu Psycholinguistics Lab phone: (716) 645-3650 X377 Department of Psychology fax: (716) 645-3801 SUNY at Buffalo lab webpage: http://psychling.buffalo.edu Buffalo, NY 14260 personal webpage: http://www.buffalo.edu/~bmb -------------------------------------------------------------------------- From myanagi at vapop.ucsd.edu Mon Oct 13 18:47:43 2003 From: myanagi at vapop.ucsd.edu (Matt Yanagi) Date: Mon, 13 Oct 2003 11:47:43 -0700 Subject: E-Prime and fORP Message-ID: I was hoping someone might be able to point me in the right direction with a problem I'm having with the fORP and E-Prime. Here's the scenario in a nutshell... On a simple Text Display page, I'm collecting a response (via the fORP), recording the RT and the selection. However, when a repsonse is made using the fORP, the page terminates to the next. Whereas with the KEYBOARD input option (allowing me to set the time limit to "same as duration"), the page doesn't move on until the predetermined time out duration. I'm shooting for the latter, but using the fORP. When selecting PORT (I'm using CKUBED) as the input device, there's no options like that of the keyboard. Any suggestions? Thanks, Matt Yanagi From ndpm at email.unc.edu Tue Oct 14 13:10:28 2003 From: ndpm at email.unc.edu (Nicole Pukay-Martin) Date: Tue, 14 Oct 2003 09:10:28 -0400 Subject: flicker Message-ID: I am creating a program that has two very quick (about 33ms) presentations, each one containing nine bitmap images. In the original program, the timing was not correct due to the large amount of information that had to be loaded. I then tried to preload the images by loading the files for both presentations and then having two SlideObject.Draw commmands at the very end of the script. This appears to fix the timing problem, but now there is a quick flicker at the beginning of each trial. We can only see the flicker when the two presentations are set to appear for a longer amount of time (999ms each). The flicker goes by so quickly that we can't tell what exactly it is; however, we suspect that it may be presenting some of the bitmap files while it is loading the images. Has anyone else encountered this kind of problem? Any ideas for how to fix it? Thanks! Nicole Pukay-Martin Research Assistant UNC Cognitive Aging Lab From ftornay at ugr.es Tue Oct 14 15:15:20 2003 From: ftornay at ugr.es (ftornay at ugr.es) Date: Tue, 14 Oct 2003 17:15:20 +0200 Subject: flicker In-Reply-To: <1066137028.3f8bf5c4b4b23@webmail8.isis.unc.edu> Message-ID: Flickering is a common problem when one tries to program animation or present brief images, no matter which software is used. It may appear every time only one part of the screen is updated. The general solution is to copy a large portion of the screen or even the whole screen. First try waiting for a vertical display and clearing the wole screen before drawing the second presentation: display.waitforverticalblank presentation1.draw sleep 33 display.waitforverticalblank display.canvas.clear display.waitforverticalblank presentation2.draw sleep 33 display.waitforverticalblank display.canvas.clear With this code you may skip a refresh cycle for every presentation. You may be better off shortening the sleep times to, say, 30 ms if your refresh rate is about 60, as is usually the case. The real presentation time would be about two refresh cycles, so 33 ms, more or less. Take into account that erasing the screen between presentations would take an extra refresh cycle. There are ways of recording the actual presentation times. If this doesn't work you should consider using canvas, rather than display objects, which I think is the best method for presenting very brief images. In either case, I could help you with the details of the code if you let me know more about your procedure. Hope this helps, Francisco J. Tornay Universidad de Granada From morrct at andrew.cmu.edu Wed Oct 15 13:22:27 2003 From: morrct at andrew.cmu.edu (Mark G Orr) Date: Wed, 15 Oct 2003 09:22:27 -0400 Subject: Script too large to compile Message-ID: Hello, i searched the archives, but could not find how to solve the following problem. THe error message was: "Complile Error (Line 3118, Col 42) 76: Script is too large to be compiled" Any ideas? -Mark Orr ________________________________ Mark G. Orr Postdoctoral Research Fellow Dept. of Psychology, RM 330 Baker Carnegie Mellon University Pittsburgh, PA 15213 phone: 412.268.4237 fax: 412.268.2798 email: morrct at andrew.cmu.edu From anthony.zuccolotto at pstnet.com Wed Oct 15 13:29:46 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Wed, 15 Oct 2003 09:29:46 -0400 Subject: Script too large to compile Message-ID: Mark, This typically results from exceeding the maximum constant/string space allowed by the E-Basic compiler. Most often this happens when you used a very large number of objects in your experiment, e.g. by declaring a unique procedure to present each stimulus rather than declaring the stimuli on Lists and using one procedure with a single stimulus presentation object whose content is set to be pulled from an attribute on the List. Also, E-Prime 1.1 (as opposed to E-Prime 1.0) modifies the way it writes out it's script to initialize objects to help with this problem. If you by chance haven't yet upgraded to 1.1 and the latest service pack you should do so. Hope this helps, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Mark G Orr [mailto:morrct at andrew.cmu.edu] > Sent: Wednesday, October 15, 2003 8:22 AM > To: eprime list > Subject: Script too large to compile > > Hello, i searched the archives, but could not find how to solve the > following problem. THe error message was: > > "Complile Error (Line 3118, Col 42) > 76: Script is too large to be compiled" > > Any ideas? > > > -Mark Orr > > > > > > > ________________________________ > Mark G. Orr > Postdoctoral Research Fellow > Dept. of Psychology, RM 330 Baker > Carnegie Mellon University > Pittsburgh, PA 15213 > > phone: 412.268.4237 > fax: 412.268.2798 > email: morrct at andrew.cmu.edu From devo0023 at tc.umn.edu Wed Oct 15 14:01:25 2003 From: devo0023 at tc.umn.edu (Cynthia J DeVore) Date: Wed, 15 Oct 2003 09:01:25 -0500 Subject: Script too large to compile In-Reply-To: Message-ID: Mark, I've still had problems with this, even running 1.1. You can solve this in one of two ways (or a combination of the two): 1) Streamline Experiment * Have you mistakenly created copies of identical display objects (Slide2 = Slide1) instead of reusing objects? * Are some display objects more similar than different? Can you possibly add an attribute to a list to then reuse a display object? * Can your lists be made into embedded files? It's really easier to maintain that way and you have access to Spell Check. 2) Break the Experiment into pieces * You can call a second E-Prime experiment from a first experiment with a simple call. You can even pass through the same startup information. What follows is a package I wrote to do just this. It might need some tweaking as I hurriedly culled it from a larger package. Cynthia [Header] PackageName="ExperimentNavigation" Description="Move from Experiment to Experiment" VersionMajor=1 VersionMinor=0 VersionInternal=0 VersionRevision=0 [Global] [InitPackages] ' *** Package initialization [UnInitPackages] ' *** Package cleanup [Desc_ExperimentNavigation_GoToNextProgram] Overview: This inline code calls an E-Prime program, supplying selected session attributes. Requirements: * The StartUp Info Parameters for the called program must match those in the package call for order. * Subject number MUST be the first parameter in the called program * In the called program, turn OFF the "display of the summary to confirm the values". * E-Run.exe must be located in c:\My Programs\PST\E-Prime\Program\ Parameters: c = Context (required) ProgramName = Name of the program, without the extension (required) DisplayCall = True/False: If true, a messagebox will show the call. This is helpful when debugging. Path = Path to the program (optional: default is same path as current program) InfoParameter, InfoParameter, ... = StartUp Info Parameters needed by the called program. All parameters must be in the order in which they will be prompted by the called program. The Subject number is automatically generated based upon the current subject number. All other parameters are optional. Remarks: [Info_ExperimentNavigation_GoToNextProgram] DefaultParameters="c,\"Replace with called program name without extension\",False" [PreSub_ExperimentNavigation_GoToNextProgram] [Sub_ExperimentNavigation_GoToNextProgram] Public Sub ExperimentNavigation_GoToNextProgram(c as context, _ CalledProgramName as String, _ DisplayCall as Boolean, _ Optional CalledProgramPath as Variant, _ Optional Parm1 as Variant, _ Optional Parm2 as Variant, _ Optional Parm3 as Variant, _ Optional Parm4 as Variant, _ Optional Parm5 as Variant, _ Optional Parm6 as Variant, _ Optional Parm7 as Variant, _ Optional Parm8 as Variant) Dim Subject as Integer Dim Parm as String Dim ebQuote as String Dim ebSlash as String Dim TempFileName as string Dim ParmList (1 to 8) as String Dim ParmCount as Integer Dim ParmIndex as Integer Dim tempparm as String Dim ProgramPath as String Dim id as variant Dim CalledProgramPart1 as string Dim CalledProgramPart2 as string Dim MessageToDisplay as string ebQuote = Chr(34) ebSlash = Chr(92) CalledProgramPart1 = ebquote & "c:" & ebSlash & "program files" & _ ebSlash & "pst" & ebSlash & "e-prime" & ebSlash & "program" & _ ebSlash & "e-run.exe" & ebquote & space(1) & ebquote & "/a" & _ ebquote & space(1) & ebQuote & "/m" & ebquote & space(1) & ebquote ' Get the standard parameter Subject = c.getattrib("Subject") ' Get the path If ismissing(calledProgramPath) Then tempparm = c.datafile.filename ProgramPath = FileParse$(tempparm,2) Else ProgramPath = CalledProgramPath End If ' Fill the ParmList with the optional parameters If Not IsMissing(Parm1) Then ParmList(1) = Parm1 MessageToDisplay = "\n" & ParmList(1) ParmCount = 1 End If If Not IsMissing(Parm2) Then ParmList(2) = Parm2 MessageToDisplay = "\n" & ParmList(2) ParmCount = 2 End If If Not IsMissing(Parm3) Then ParmList(3) = Parm3 MessageToDisplay = "\n" & ParmList(3) ParmCount = 3 End If If Not IsMissing(Parm4) Then ParmList(4) = Parm4 MessageToDisplay = "\n" & ParmList(4) ParmCount = 4 End If If Not IsMissing(Parm5) Then ParmList(5) = Parm5 MessageToDisplay = "\n" & ParmList(5) ParmCount = 5 End If If Not IsMissing(Parm6) Then ParmList(6) = Parm6 MessageToDisplay = "\n" & ParmList(6) ParmCount = 6 End If If Not IsMissing(Parm7) Then ParmList(7) = Parm7 MessageToDisplay = "\n" & ParmList(7) ParmCount = 7 End If If Not IsMissing(Parm8) Then ParmList(8) = Parm8 MessageToDisplay = "\n" & ParmList(8) ParmCount = 8 End If tempparm = ProgramPath & ebSlash & CalledProgramName & ".ebs" CalledProgramPart2 = CalledProgramPart1 & tempparm & ebquote ' Display the call if requested If DisplayCall Then Msgbox "This program, generating data file " & c.datafile.filename & " is calling " & _ tempparm & " with the following " & _ format$(ParmCount,"0") & " parameters: " & MessageToDisplay & "\n" & _ "The following string will be sent to the shell: " & CalledProgramPart2 End If If FileExists(tempparm) Then id = Shell (CalledProgramPart2, ebNormalFocus) SendKeys Subject, True SendKeys "{ENTER}", True For ParmIndex = 1 to ParmCount tempparm = c.getattrib(ParmList(ParmIndex)) SendKeys tempparm, True SendKeys "{ENTER}", True Next ParmIndex Else MsgBox "Program " & tempparm & " does not exist." End If End Sub [PostSub_ExperimentNavigation_GoToNextProgram] ' *** no script needed At 08:22 AM 10/15/2003, Mark G Orr wrote: >Hello, i searched the archives, but could not find how to solve the >following problem. THe error message was: > >"Complile Error (Line 3118, Col 42) >76: Script is too large to be compiled" > >Any ideas? > > >-Mark Orr > > > > > > >________________________________ >Mark G. Orr >Postdoctoral Research Fellow >Dept. of Psychology, RM 330 Baker >Carnegie Mellon University >Pittsburgh, PA 15213 > >phone: 412.268.4237 >fax: 412.268.2798 >email: morrct at andrew.cmu.edu Cynthia J. DeVore Graduate Student University of Minnesota - Industrial/Organizational Psychology devo0023 at tc.umn.edu 612-624-3601 Office hours for E-Prime Consultant: http://online.psych.umn.edu/IS/Elliott160/Calendar/200310.htm E-Prime @ U of MN http://online.psych.umn.edu/IS/Eprime/index.htm From gtrafton at osf1.gmu.edu Thu Oct 16 19:33:51 2003 From: gtrafton at osf1.gmu.edu (Greg Trafton) Date: Thu, 16 Oct 2003 15:33:51 -0400 Subject: data analysis Message-ID: Hi, All. I used eprime for a study several months ago. alas, I no longer have access to the data analysis programs and am a bit confused by the data. part of it is below. I understand Graph.RESP (the answer the subject gave me). however, Graph.RT and Graph.RTTime seem to be "odd" -- I haven't checked every file, but on average, this participant is taking about 10000 RT (I assume it's in ms), which is *much* longer than I would have expected. so my questions are: 1) is Graph.RT really ms? if not, how do I convert it to ms? 2) what is the diff between RT and RTTime (if I subtract Graph.RTTime2 from Graph.RTTime1 (consecutive subtractions), I get a number that's close Graph.RT number (but always slightly bigger) 3) how do I figure out how long it took to enter each answer? thanks! greg Subject filename Graph.RESP Graph.RT Graph.RTTime 1 example.line.ro.890.1.bmp NULL NULL NULL 1 example.line.ro.305.4.bmp NULL NULL NULL 1 example.log.ro.227.6.12.100.200.0.5.bmp NULL NULL NULL 1 example.log.ro.733.11.400.700.1.bmp NULL NULL NULL 1 example.sin.far.193.6.45.0.37.bmp NULL NULL NULL 1 example.sin.far.187.4.25.0.33.bmp NULL NULL NULL 1 demo.line.far.430.1.bmp 440 24568 7620724 1 demo.line.ro.282.5.4.bmp 285 39914 7672700 1 demo.sin.ro.160.2.25.0.33.bmp 125 45722 7719915 1 demo.sin.near.105.45.0.37.bmp 137 12438 7733609 1 demo.log.far.948.2.11.750.900.1.bmp 945 23141 7757950 1 demo.log.near.482.5.12.150.450.0.5.bmp 481 24069 7782678 1 h.line.ro.433.3.1.5.bmp 432 21175 7838177 1 a.sin.far.150.1.40.0.26.bmp 159 10950 7850569 1 c.line.ro.339.2.2.4.bmp 340 16038 7867188 1 b.line.near.321.7.1.2.bmp 308 17652 7885414 1 i.line.far.390.3.bmp 372 8526 7894983 1 e.log.near.310.2.3.750.300.1.bmp 309 13958 7909581 1 b.sin.far.180.5.20.0.32.bmp 198 11486 7921707 1 j.log.far.315.2.3.100.300.2.bmp 312 15252 7937496 1 b.line.near.405.2.bmp 400 7705 7945835 1 j.line.ro.329.1.2.2.bmp 339 15416 7962080 1 j.sin.near.273.5.50.0.29.bmp 230 13780 7977150 1 k.line.far.543.3.1.2.bmp 500 29025 8007250 1 f.sin.near.166.8.40.0.38.bmp 170 5070 8012737 1 b.log.far.137.2.8.5.550.100.1.bmp 140 9421 8022649 From jeff.larsen at ttu.edu Fri Oct 17 18:46:17 2003 From: jeff.larsen at ttu.edu (Larsen, Jeff) Date: Fri, 17 Oct 2003 13:46:17 -0500 Subject: IAT in Eprime Message-ID: Dear Eprime users: Has anyone implemented Greenwald's Implicit Association Task (IAT) in Eprime? If so, I would greatly appreciate a copy of the EBS file. Thanks, Jeff *************************************************** Jeff T. Larsen, PhD Department of Psychology Texas Tech University phone: 806-742-3711 x234 fax: 806-742-0818 email: jeff.larsen at ttu.edu web: http://webpages.acs.ttu.edu/jelarsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From macw at cmu.edu Fri Oct 17 20:15:26 2003 From: macw at cmu.edu (Brian MacWhinney) Date: Fri, 17 Oct 2003 16:15:26 -0400 Subject: IAT in Eprime In-Reply-To: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD03846836@BRONTES.net.ttu.edu> Message-ID: Dear Eprime Users, Jeff's message raises a slightly more general issue. We have constructed a collection of nearly 100 Eprime scripts implementing classic experiments at step.psy.cmu.edu. We would very much like to be able to add to this collection. So, if you have implemented a classic or commonly-used paradigm in Eprime, we would much appreciate receiving both the EBS file, related stim files, and a pointer to the published article that the experiment is replicating or implementing. We will happily cite each contributor as the source of the contribution. Perhaps you can even add this to your CV. --Brian MacWhinney, CMU > On 10/17/03 2:46 PM, "Larsen, Jeff" wrote: > Dear Eprime users: > > Has anyone implemented Greenwald's Implicit Association Task (IAT) in > Eprime? If so, I would greatly appreciate a copy of the EBS file. > From odenthal at soz.psychologie.uni-konstanz.de Mon Oct 20 13:42:25 2003 From: odenthal at soz.psychologie.uni-konstanz.de (Georg Odenthal) Date: Mon, 20 Oct 2003 15:42:25 +0200 Subject: flicker Message-ID: I've recently tried to create subliminal priming experiment with E-Prime and also found out about the screen flicker. So I had to abandon this project using E-Prime and went back to MEL2 where you can avoid this screen flicker by using double buffering or a color switching trick (explained later). It's strange that PST didn't include the double buffering feature from MEL2 in E-Prime since it is such a useful technique for subliminal priming studies. Double buffering refers to the possibility to store two different screens in two different screen banks in the memory. Modern graphics cards hold several frame buffers in their 64MB or 128MB of frame buffer. Switching between one buffer and another can be done with a few commands in virtually no time. Unfortunately this feature doesn't seem to be included in E-Prime. I wasn't able to find any information on creating and switching between frame buffers in the E-Prime Reference guide. On page 97 of the Reference Guide there is the method "DisplayDevice.RestoreVideoBuffers (method)" listed, but neither in the manual nor in the E-Basic help seems to be any more information on that. When a Display Object is painted using the DisplayObject.draw method a software creates the screen display or copies a preloaded image from the memory to the screen. This can take a lot of time depending on the screen size and the color depth. I've written a small program to demonstrate how much time this Draw command can take. I'm including the E-Basic InlineObject with this email. Besides that you need to create two TextDisplays called Black and White (one with Black background and one with White background, both are opaque. Make sure to set the Default Duration to 0) Create another TextDisplay called CollectResp, set the Duration to 0, EndAction to "(none)", TimeLimit to 10000 (for 10 seconds) and add a Keyboard input collecting any key response. Insert the CollectResp object as first item into SessionProc and the Inline Script as second. Enter the following commands into the Inline Script: 'Repeat loop until a keyboard response was made While CollectResp.InputMasks.IsPending() 'Wait for frameflyback display.waitforverticalblank 'Display black background Black.draw 'Wait for frameflyback display.waitforverticalblank 'Display white background White.draw 'Give the computer some time to collect a keyboard response sleep 1 wend When you run this script your screen will present you a very quick black and white flicker. But usually you will also see that a part on top of the screen looks somewhat displaced. This displacement is a measurement of the time the draw method takes to paint the black or white background on the screen. This time is dependent on the speed of the computer, on the refresh frequency of the screen (e.g. 60 Hz, 75Hz, ...) and on the screen resolution as well as on the color depth of the screen. In most cases you cannot change the speed of the computer (unless your lab computers have a faster processor than your E-Prime development computer). The refresh cycle of the screen is dependent on the manufacturer and model of the screen and usually cannot be changed as well. What you can do is change the screen resolution and color depth. To do that double click on the Experiment Object, go to the Devices tab, double click on the Display item. A window with the name "Edit DisplayDevice Properties" should pop up. There you can change the screen resolution and color depth of the program. The default values are 640 * 480 with 16 bits color depth. Try for example to switch the resolution to 1024 * 768 with 24 bits color depth. When you run the program the displacement on top of the screen will be a lot larger, because it takes a lot more time to fill a screen with 1024 * 768 pixels with 24 bit color depth. If you change to 640 * 480 with 8 bits color depth the displacement gets a lot smaller. Why is that so? A screen resolution of 640 * 480 means that there are 640 points in each horizontal line on the screen and there are a total of 480 lines per screen. That is 640 * 480 pixels = 307200 pixels. The color depth 16 means that you can display one of 65536 colors in each pixel. A byte takes up 8 bits, that is 16 bits means each pixel has two bytes on the screen. So the 307200 pixels need two bytes each that is the screen memory is 307200 * 2 = 614400. In kilobytes that is 614400 / 1024 = 600 kb per screen. This is not very much memory compared to the main memory of modern computers and graphics cards. Copying 600 kb from the memory to the screen doesn't take up too much calculation time. Now how much memory does the computer need to copy from the memory to the screen in the 1024 * 768 example. Pixels per screen: 1024 * 768 = 786432 pixels Color depth 24 bits: 3 bytes per pixel Memory taken: 786432 pixels * 3 bytes/ pixels = 2359296 bytes in Kilobytes: 2359296 / 1024 = 2304 (equals 2.25 mb). Copying 2.25 mb to the screen takes a lot more time since it's almost four times as much memory as the 640 * 480 resolution. I've also tried to display images that were pre-loaded into the memory, but I've received exactly the same effect. The displacement line showed up at virtually the same place as in the TextDisplay example above. This displacement line shows the position where the routine that copies the screen display from the memory to the video ram in the graphics card overtakes the video beam that displays the pixels in the video ram on the screen. That is on top of the displacement line you still see the previous frame whereas below the displacement line the new frame is being painted. This results in a partial display of two different images. If you want to display subliminal stimuli on the screen this displacement line can become a huge problem if is within the stimulus you want to display. In this case the subjects would only see the bottom part of the stimulus on one frame and then the top part of the stimulus and the bottom part of the mask in the next. (And then the top part of the mask in the screen after that). This can probably render your subliminal priming useless or at least make your discussion difficult since you have to argue in the discussion that presenting stimuli that are split in half still have the same effect than stimuli that are presented as a whole. We wanted to create study where words are presented subliminally in the parafoveal field. But since E-Prime couldn't guarantee that the words are always presented as whole we switched back to MEL2 to create this study in MSDOS. Unless there is a method in E-Prime to flip between two different screen buffers in the video RAM of the graphics card I won't try to create subliminal priming studies with E-Prime again. The danger of loosing the data of a study with a hundred or more subjects due to this displacement bug is too costly for our lab. For displaying simple stimuli there is a different method than copying pre-loaded images on the screen: the color switching trick. This color switching trick is only possible in a 256 (8-bit) color mode. With it you can present up to 8 different stimuli in a short succession without running into the problems above. In this trick you create stimuli with a program that supports an XOR (or also called EOR) overlay mode for painting text on the screen (e.g. MEL2 is capable of doing that with the SET_RASTEROP_MODE command.) E-Prime doesn't offer an XOR overlay mode, it has only ebROPModeCopy or ebROPModeMerge though. XOR is short for eXclusiveOR. If you paint something on the screen, the bits of each pixel will only be painted unaltered if the background bit is 0. Else the bit will flip it's value (e.g. 1 and 0 or 0 and 1 will become 1 and 1 and 1 will become 0). If you paint two words in different colors over one another the result will look like an abstract painting. But by redefining specific colors you can make either one or the other word visible. (it also with 3 up to 8 words.) We used this method in MEL2 a lot since the double buffering was only available in very weird screen modes (e.g. 640 x 350) in which text looked very deformed. The trick with this method is to know which colors you need to redefine. But there's a simple solution: A byte contains of 8 bits, e.g. 10010001 (this is also called binary notation). The leftmost bit is the MSB (most significant bit) and has a value of 2 to the power of 7 = 128, the rightmost bit is the LSB (least significant bit) and has a value of 2 to the power of 0 = 1. The bits in between have the values 64, 32, 16, 8, 4 and 2 respectively. If you overlay text in the XOR mode in any of these 8 values, you will have a distinct color bit for each of the 8 different stimuli. That is if you paint a prime in color 2 (as byte: 00000010) on the screen and overlay it with a target in color 8 (as byte: 00001000). The color where both text overlap with one another will be 8 + 2 = 10 (00001010). So if you want to display the prime you need to set the RGB values of the color 8 to the RGB values of the background color and set the values of both, color 2 and color 10 to the foreground RGB values. For the target you need to set the color 2 to the background color and colors 8 and 10 to the foreground color. If you want to display 3 different words in quick succession you can for example select the colors 1, 2 and 4. If you want to display the first word set: 1, 3, 5 and 7 to foreground and 2, 4 and 6 to background for the second word set: 2, 3, 6, and 7 to foreground and 1, 4 and 5 to background for the third word set: 4, 5, 6 and 7 to foreground and 1, 2 and 3 to background With every additional stimulus you add to this scheme the numbers of colors you have to redefine doubles. So if you want to display 5 different stimuli you need to redifine 31 colors for each word with 8 stimuli you need to redefine all 255 colors for each word. Switching colors is in E-Prime a lot faster than copying complete screens to the video ram. You can use the DisplayDevice.Palette method to set all 256 of a 8 bit color mode. I've written a small program that does just that. I will just include a part of the InlineScript since it is too large to be copied into this email as a whole: Dim thePal As Palette Dim i as Integer Dim factor as Integer Set thePal = Display.Palette Dim arrEntries(255) As PaletteEntry Dim prime(255) As PaletteEntry Dim mask(255) As PaletteEntry thePal.GetEntries 0, 256, arrEntries [... 'Color redefinition is done in this omitted part] 'Wait for frameflyback display.waitforverticalblank 'Set the palette thePal.SetEntries 0, 256, arrEntries 'Repeat loop until a keyboard response was made While CollectResp.InputMasks.IsPending() 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, prime sleep 1 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, mask sleep 1 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, arrEntries sleep 1 wend If you're interested in the program, I can send you the whole program including the test screen with the two stimuli as a ZIP archive. The drawbacks of this color switching trick are besides the increasing number of colors you need to redefine are also, that you are limited to 8 colors and that your text cannot use anti-aliasing (smoothing) of the font, since this adds several colors (usually gray nuances) to the image. But as long as E-Prime cannot perform real frame buffer switching this seems to be the only method available to ensure a quick and complete display of subliminal stimuli. If you have any questions or are interested in the programs discussed in this email you can write to the address below. Best regards, Georg Odenthal ========================================================================= Georg Odenthal (Dipl.-Psych.) University of Konstanz +49 (0)7531 88-2872 Department of Psychology odenthal at soz.psychologie.uni-konstanz.de Social Psychology and Motivation http://www.socpsych.uni-konstanz.de 78457 Konstanz, Germany ========================================================================= From jpettib at siue.edu Mon Oct 20 15:22:29 2003 From: jpettib at siue.edu (Jonathan Pettibone) Date: Mon, 20 Oct 2003 10:22:29 -0500 Subject: Cleartype problems In-Reply-To: <476593089.20031020154225@soz.psychologie.uni-konstanz.de> Message-ID: Has anyone else noticed that having cleartype enables creates display problems in E-Prime? Using a 640 x 480 screen and the slide procedure, a text box containing a variable read from a list was always cut in half, or sometimes more, so that you could only see a portion of the text. I've got a bunch of similar text boxes on the screen, but that only happened to one of them. I don't know if this is a known problem or not, but it drove me so nuts trying to figure out what was wrong that I wanted to share this with the list. Jonathan Pettibone Jonathan Pettibone Assistant Professor Dept. of Psychology Southern Illinois University Edwardsville Edwardsville, IL 62026 From ftornay at ugr.es Tue Oct 21 12:34:53 2003 From: ftornay at ugr.es (ftornay at ugr.es) Date: Tue, 21 Oct 2003 14:34:53 +0200 Subject: flicker and double buffering In-Reply-To: <476593089.20031020154225@soz.psychologie.uni-konstanz.de> Message-ID: The issues brought about by Georg Odenthal are very interesting and I would greatly appreciate it, Georg, if you could send me your programs. However, the flickering problem can be solved just by copying large portions of the screen from a offscreen canvas object, no matter how long the copying process takes. For instance '*** Code in the script user tab 'declare variable for offscreen buffer dim offscreen as canvas '*** Inline object at the beginning of the experiment 'create offscreen canvas set offscreen = display.createcanvas 'and, for instance, load a file, it would also be possible to combine different 'images by copying several canvas objects to the offscreen object offscreen.loadimage "bluecar.bmp" '*** Inline object on every trial 'Wait for vertical blank display.WaitForVerticalBlank 'copy offscreen to actual screen display.canvas.copy offscreen The main thing is to copy all or most of the offscreen buffer to the screen, that should take care of the flickering. That implements a software double buffering system. A complete separate question is how long it takes for the image to be copied. In that sense the ideas presented by Georg about hardware double buffering as implemented by MEL2 (only for very low-resolution modes) are relevant. I have tried a little experiment by using an experiment I wrote in response to Nicole's original question. I just copied such an offscreen buffer using a 640 * 480, 16-bit screen mode. Immediately after the inline I used a wait object without vertical blank synchrony. According to the data file, the onsetdelay variable for that object is 17 ms. If the program waits until the image is copied before presenting the wait object, this time should equal (or maybe be larger than) the time required for copying the whole screen. Do you think that is correct? How reliable is it? If you think I can trust the data, I could also see what happens in higher-resolution display modes. If it were correct, it would mean that the delay equals one refresh cycle (my refresh rate is about 60). You can't go below that and still be sure the whole screen is presented to the subject. This would make discussion about quicker copying methods rather accademic, unless one is very interested in using very high-resolution modes. At any rate, MEL2 would never be better than E-prime: if you can use a resolution low enough for MEL then you can also present the information in E- prime as quick as possible for your hardware. You could even do it with much better resolution modes: MEL2 can't handle the mode I've used and much less if you want to use hardware double buffering methods which are only possible for EGA modes, at least if you want two whole-sized screen buffers. Please if I'm wrong or I'm missing something, please let me know. From anthony.zuccolotto at pstnet.com Tue Oct 21 13:17:43 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Tue, 21 Oct 2003 09:17:43 -0400 Subject: flicker Message-ID: Georg, I will try to create a more in depth response later this week, but you essentially should be able to do what you want in E-Prime and eliminate the flicker. You are correct that the hardware based page flipping that was directly supported in MEL is not there in the exact same form in E-Prime. Support for multiple offscreen buffers/canvases however is there and is more powerful than what was offered in MEL. Without going into a lot of detail, it was not possible for us to implement the hardware based page flipping feature and have it coexist with the other operations of all the other objects in E-Prime. For example, since E-Prime always runs in graphics rather than text mode, we had to provide support for echoing back responses over top of images better than was done in MEL. Features like these were basically incompatible with the E-Prime model without sacrificing the general performance of the system. Further, when we initially attempted it, the performance of the hardware page flipping vs Canvas.Copy was not significantly better on most video cards (e.g. both were sub-millisecond). I expect though, that the actual problem you are running into is that the Windows drivers for many video cards perform bitmap fills/transfers from the bottom up, thus rather than the copying of the image data starting at the top of the screen and filling down (while staying ahead of the refresh), the image data starts at the bottom and fills towards the top at which point the image fill and the refresh cross each other and you may get something like you describing. E-Prime 1.1 included advanced features that allow you to instruct the system to automatically split these bitmaps up into smaller portions which are drawn starting at the portion at the top of the screen. Checkout the E-Prime Knowledge Base article http://www.pstnet.com/e-prime/support/kb.asp?TopicID=1274 and/or DisplayDevice.SegmentCopyHeight, DisplayDevice.SegmentCopyVerticalOffset in the E-Basic help (E-Prime 1.1). In all instances I have been aware of where this problem was observed, these commands could be used to minimize or eliminate the visual problem at the top of the screen. Thanks, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Georg Odenthal [mailto:odenthal at soz.psychologie.uni-konstanz.de] > Sent: Monday, October 20, 2003 8:42 AM > To: eprime at mail.talkbank.org > Subject: Re: flicker > > I've recently tried to create subliminal priming experiment with > E-Prime and also found out about the screen flicker. So I had to > abandon this project using E-Prime and went back to MEL2 where you can > avoid this screen flicker by using double buffering or a color > switching trick (explained later). > > It's strange that PST didn't include the double buffering feature from > MEL2 in E-Prime since it is such a useful technique for subliminal > priming studies. > > Double buffering refers to the possibility to store two different > screens in two different screen banks in the memory. Modern graphics > cards hold several frame buffers in their 64MB or 128MB of frame > buffer. Switching between one buffer and another can be done with a > few commands in virtually no time. > > Unfortunately this feature doesn't seem to be included in E-Prime. > I wasn't able to find any information on creating and switching > between frame buffers in the E-Prime Reference guide. On page 97 of > the Reference Guide there is the method > "DisplayDevice.RestoreVideoBuffers (method)" listed, but neither in > the manual nor in the E-Basic help seems to be any more information on > that. > > When a Display Object is painted using the DisplayObject.draw method > a software creates the screen display or copies a preloaded image from > the memory to the screen. This can take a lot of time depending on the > screen size and the color depth. > > I've written a small program to demonstrate how much time this Draw > command can take. I'm including the E-Basic InlineObject with this > email. Besides that you need to create two TextDisplays called Black > and White (one with Black background and one with White background, > both are opaque. Make sure to set the Default Duration to 0) > > Create another TextDisplay called CollectResp, set the Duration to 0, > EndAction to "(none)", TimeLimit to 10000 (for 10 seconds) and add a > Keyboard input collecting any key response. > > Insert the CollectResp object as first item into SessionProc and the > Inline Script as second. > > Enter the following commands into the Inline Script: > > 'Repeat loop until a keyboard response was made > While CollectResp.InputMasks.IsPending() > > 'Wait for frameflyback > display.waitforverticalblank > 'Display black background > Black.draw > 'Wait for frameflyback > display.waitforverticalblank > 'Display white background > White.draw > 'Give the computer some time to collect a keyboard response > sleep 1 > wend > > When you run this script your screen will present you a very quick > black and white flicker. But usually you will also see that a part on > top of the screen looks somewhat displaced. This displacement is a > measurement of the time the draw method takes to paint the black or > white background on the screen. This time is dependent on the speed of > the computer, on the refresh frequency of the screen (e.g. 60 Hz, > 75Hz, ...) and on the screen resolution as well as on the color depth > of the screen. > > In most cases you cannot change the speed of the computer (unless your > lab computers have a faster processor than your E-Prime development > computer). The refresh cycle of the screen is dependent on the > manufacturer and model of the screen and usually cannot be changed as > well. > > What you can do is change the screen resolution and color depth. To do > that double click on the Experiment Object, go to the Devices tab, > double click on the Display item. A window with the name "Edit > DisplayDevice Properties" should pop up. > > There you can change the screen resolution and color depth of the > program. The default values are 640 * 480 with 16 bits color depth. > Try for example to switch the resolution to 1024 * 768 with 24 bits > color depth. When you run the program the displacement on top of the > screen will be a lot larger, because it takes a lot more time to fill > a screen with 1024 * 768 pixels with 24 bit color depth. > > If you change to 640 * 480 with 8 bits color depth the displacement > gets a lot smaller. > > Why is that so? > > A screen resolution of 640 * 480 means that there are 640 points in > each horizontal line on the screen and there are a total of 480 lines > per screen. That is 640 * 480 pixels = 307200 pixels. > > The color depth 16 means that you can display one of 65536 colors in > each pixel. A byte takes up 8 bits, that is 16 bits means each pixel > has two bytes on the screen. So the 307200 pixels need two bytes each > that is the screen memory is 307200 * 2 = 614400. In kilobytes that is > 614400 / 1024 = 600 kb per screen. This is not very much memory > compared to the main memory of modern computers and graphics cards. > Copying 600 kb from the memory to the screen doesn't take up too much > calculation time. > > Now how much memory does the computer need to copy from the memory to > the screen in the 1024 * 768 example. > Pixels per screen: 1024 * 768 = 786432 pixels > Color depth 24 bits: 3 bytes per pixel > Memory taken: 786432 pixels * 3 bytes/ pixels = 2359296 bytes > in Kilobytes: 2359296 / 1024 = 2304 (equals 2.25 mb). > > Copying 2.25 mb to the screen takes a lot more time since it's almost > four times as much memory as the 640 * 480 resolution. > > I've also tried to display images that were pre-loaded into the > memory, but I've received exactly the same effect. The displacement > line showed up at virtually the same place as in the TextDisplay > example above. > > This displacement line shows the position where the routine that > copies the screen display from the memory to the video ram in the > graphics card overtakes the video beam that displays the pixels in the > video ram on the screen. That is on top of the displacement line you > still see the previous frame whereas below the displacement line the > new frame is being painted. This results in a partial display of two > different images. > > If you want to display subliminal stimuli on the screen this > displacement line can become a huge problem if is within the stimulus > you want to display. In this case the subjects would only see the > bottom part of the stimulus on one frame and then the top part of the > stimulus and the bottom part of the mask in the next. (And then the > top part of the mask in the screen after that). > > This can probably render your subliminal priming useless or at least > make your discussion difficult since you have to argue in the > discussion that presenting stimuli that are split in half still have > the same effect than stimuli that are presented as a whole. > > We wanted to create study where words are presented subliminally in > the parafoveal field. But since E-Prime couldn't guarantee that the > words are always presented as whole we switched back to MEL2 to create > this study in MSDOS. > > Unless there is a method in E-Prime to flip between two different > screen buffers in the video RAM of the graphics card I won't try to > create subliminal priming studies with E-Prime again. The danger of > loosing the data of a study with a hundred or more subjects due to this > displacement bug is too costly for our lab. > > > For displaying simple stimuli there is a different method than copying > pre-loaded images on the screen: the color switching trick. > > This color switching trick is only possible in a 256 (8-bit) color > mode. With it you can present up to 8 different stimuli in a short > succession without running into the problems above. > > In this trick you create stimuli with a program that supports an XOR > (or also called EOR) overlay mode for painting text on the screen > (e.g. MEL2 is capable of doing that with the SET_RASTEROP_MODE > command.) E-Prime doesn't offer an XOR overlay mode, it has only > ebROPModeCopy or ebROPModeMerge though. > > XOR is short for eXclusiveOR. If you paint something on the screen, > the bits of each pixel will only be painted unaltered if the > background bit is 0. Else the bit will flip it's value (e.g. 1 and 0 > or 0 and 1 will become 1 and 1 and 1 will become 0). If you paint > two words in different colors over one another the result will look > like an abstract painting. But by redefining specific colors you can > make either one or the other word visible. (it also with 3 up to 8 > words.) > > We used this method in MEL2 a lot since the double buffering was only > available in very weird screen modes (e.g. 640 x 350) in which text > looked very deformed. > > The trick with this method is to know which colors you need to > redefine. But there's a simple solution: > > A byte contains of 8 bits, e.g. 10010001 (this is also called binary > notation). The leftmost bit is the MSB (most significant bit) and has > a value of 2 to the power of 7 = 128, the rightmost bit is the LSB > (least significant bit) and has a value of 2 to the power of 0 = 1. > The bits in between have the values 64, 32, 16, 8, 4 and 2 > respectively. > > If you overlay text in the XOR mode in any of these 8 values, you will > have a distinct color bit for each of the 8 different stimuli. That is > if you paint a prime in color 2 (as byte: 00000010) on the screen and > overlay it with a target in color 8 (as byte: 00001000). The color > where both text overlap with one another will be 8 + 2 = 10 > (00001010). > So if you want to display the prime you need to set the RGB values of > the color 8 to the RGB values of the background color and set the > values of both, color 2 and color 10 to the foreground RGB values. > > For the target you need to set the color 2 to the background color and > colors 8 and 10 to the foreground color. > > > If you want to display 3 different words in quick succession you can > for example select the colors 1, 2 and 4. If you want to display the > first word set: > 1, 3, 5 and 7 to foreground and 2, 4 and 6 to background > > for the second word set: > > 2, 3, 6, and 7 to foreground and 1, 4 and 5 to background > > for the third word set: > > 4, 5, 6 and 7 to foreground and 1, 2 and 3 to background > > With every additional stimulus you add to this scheme the numbers of > colors you have to redefine doubles. So if you want to display 5 > different stimuli you need to redifine 31 colors for each word with 8 > stimuli you need to redefine all 255 colors for each word. > > Switching colors is in E-Prime a lot faster than copying complete > screens to the video ram. You can use the DisplayDevice.Palette method > to set all 256 of a 8 bit color mode. I've written a small program > that does just that. I will just include a part of the InlineScript > since it is too large to be copied into this email as a whole: > > Dim thePal As Palette > Dim i as Integer > Dim factor as Integer > Set thePal = Display.Palette > > Dim arrEntries(255) As PaletteEntry > Dim prime(255) As PaletteEntry > Dim mask(255) As PaletteEntry > thePal.GetEntries 0, 256, arrEntries > > [... 'Color redefinition is done in this omitted part] > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette > thePal.SetEntries 0, 256, arrEntries > > 'Repeat loop until a keyboard response was made > While CollectResp.InputMasks.IsPending() > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, prime > sleep 1 > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, mask > sleep 1 > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, arrEntries > sleep 1 > wend > > > If you're interested in the program, I can send you the whole program > including the test screen with the two stimuli as a ZIP archive. > > The drawbacks of this color switching trick are besides the > increasing number of colors you need to redefine are also, that you > are limited to 8 colors and that your text cannot use anti-aliasing > (smoothing) of the font, since this adds several colors (usually gray > nuances) to the image. > > But as long as E-Prime cannot perform real frame buffer switching this > seems to be the only method available to ensure a quick and complete > display of subliminal stimuli. > > > If you have any questions or are interested in the programs discussed > in this email you can write to the address below. > > Best regards, > Georg Odenthal > > > ======================================================================== == > > Georg Odenthal (Dipl.-Psych.) University of Konstanz > +49 (0)7531 88-2872 Department of Psychology > odenthal at soz.psychologie.uni-konstanz.de Social Psychology and Motivation > http://www.socpsych.uni-konstanz.de 78457 Konstanz, Germany > > ======================================================================== == > > From eliana_quintero at yahoo.es Tue Oct 21 18:35:42 2003 From: eliana_quintero at yahoo.es (=?iso-8859-1?q?eliana=20quintero?=) Date: Tue, 21 Oct 2003 20:35:42 +0200 Subject: shifting and divided atention Message-ID: Hi everybody... just would like to know if somebody has an experiment about shifting attention and divided attention that could share with me in order to assess the attention process in a clinical sample. thanks a lot. regards, eliana. -- Eliana Alexey Quintero-Gallego. Neuropsychologist Doctoral Student. Seville University, Psychobiology Department. Address: C/ Torneo 77, 3Der. 41002, Seville-Spain. --------------------------------- Yahoo! Messenger Nueva versión: Super Webcam, voz, caritas animadas, y más #161;Gratis! -------------- next part -------------- An HTML attachment was scrubbed... URL: From anh2bf at mizzou.edu Sat Oct 25 00:11:21 2003 From: anh2bf at mizzou.edu (Hismjatullina, Anna Nikolaevna (UMC-Student)) Date: Fri, 24 Oct 2003 19:11:21 -0500 Subject: animation Message-ID: Dear eprime users, I wish to include an animation as a contingency for successful trials in my developmental experiment. I am looking for bitmap images that will create a smooth movement. Does anybody have a good animation little children might enjoy? Thank you. Anna From baranan at post.tau.ac.il Mon Oct 27 09:49:31 2003 From: baranan at post.tau.ac.il (baranan at post.tau.ac.il) Date: Mon, 27 Oct 2003 11:49:31 +0200 Subject: equiluminant colors Message-ID: Hi Can anyone offer me a simple way to generate equiluminant colors for our epxeriments? Thanks, Yoav ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kcrando at netscape.net Wed Oct 29 15:09:18 2003 From: kcrando at netscape.net (Kenneth Rando) Date: Wed, 29 Oct 2003 10:09:18 -0500 Subject: Clock.Read or other timing method Message-ID: I need to create a 3000ms trial, in which the first part is a stimulus of fixed length 500ms. and the remainder of the trial is a 2500ms mask. User input needs to be enabled for the entire 3000 ms or until a keyboard reponse has been made. Sound feedback is given upon response, and then the mask must be redisplayed (no further input allowed) until the trial is over. I have been able to accomplish my goal when the user inputs a valid response, but not when the user fails to input a valid response within 2500 ms. I have accomplished the first goal using a Do Until...Loop. I would like to incorporate the second terminating condition in that loop as well, but I can't figure out a method. Page 91 of the e-Prime User's Guide refers to the Clock.Read method in E-Basic Online Help. I can't find the specific reference, where I was hoping to find a code example on which I could build. Does anybody have this example or a similar one? Thanks much! Ken Rando __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From Susie.Williams at Vanderbilt.Edu Thu Oct 2 16:48:24 2003 From: Susie.Williams at Vanderbilt.Edu (Susan Williams) Date: Thu, 2 Oct 2003 11:48:24 -0500 Subject: feedback object Message-ID: Hello, I'm hoping to program for an image to be displayed (800ms) and an immediate wait time (2200ms) between stims while collecting particpant responses. I'm also hopeful that a feedback object will respond to partcipant responses (in essence, to get the feedback object to respond to 2 different objects) and for the experiment to continue. Have any suggestions? Thanks, Susan Susan M. Williams susie.williams at vanderbilt.edu Vanderbilt-Kennedy Center Peabody Box 40 Vanderbilt University Nashville, TN 37203-5701 615) 322-1324 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstieben at yorku.ca Tue Oct 7 21:30:33 2003 From: jstieben at yorku.ca (Jim Stieben) Date: Tue, 7 Oct 2003 17:30:33 -0400 Subject: Looking for a Flanker task Message-ID: We are looking for a version of the flanker using faces. If anyone would be willing to share this, we would be most appreciative. Thanks Jim Stieben University of Toronto -------------- next part -------------- An HTML attachment was scrubbed... URL: From mconroy at ucsd.edu Wed Oct 8 21:43:16 2003 From: mconroy at ucsd.edu (Matt Conroy) Date: Wed, 8 Oct 2003 14:43:16 -0700 Subject: Pausing and Resuming during a procedure Message-ID: I am creating an experiment that requires subjects to orally identify visual stimuli, which are presented sequentially. I want to make a subject input that can pause the stimulus presentation (during which the current stimulus remains on the screen indefinitely) and a second input that causes the stimulus presentation to resume normally. It is important to record the time of these inputs, or the stimulus during which they occurred. Thank you for any advice. Matt Conroy Graduate Student UC San Diego Psychology Dept mconroy at ucsd.edu From anthony.zuccolotto at pstnet.com Thu Oct 9 12:37:13 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Thu, 9 Oct 2003 08:37:13 -0400 Subject: Pausing and Resuming during a procedure Message-ID: Matt, I would recommend trying something like setting your stimulus duration to 0 and then running a Wait object immediately after the object. The Wait object will not alter the display when it runs but can collect an input. You should then probably write some script to examine the Wait.RESP property to determine if the input that came in is your pause/resume key. If so, you can then run another Wait object, or possibly use the goto command with a Label placed above the Wait object to rerun the current object. Note though that if you use Goto statements and labels to jump execution around in the trial procedure you should take care to make sure all the relevant attributes you need to log to the data file are updated to current values (e.g. call c.SetAttrib "name", "value" as needed to update attributes in the context) and then call c.Log sometime prior to the goto. The c.Log call will cause a new row to be generated in the data file with all the current attributes. Normally you don't have to do this because a c.Log call happens automatically at the end of the trial procedure, but if you start jumping around then you typically must make some calls yourself to assure all the data you are interested in gets logged. Another approach to consider would be to use two different input masks on the same stimulus presentation object. For example you could create a keyboard mask and set 1 and 2 as allowable response keys for the stimulus, but then create another keyboard input mask on the same object with P (for pause) as the only allowable key. The first input mask can be set to terminate, and the second one can be set to Jump to a specific label. You then put script after the label to do whatever special processing is required to implement a pause/resume feature. Hope that gives you some ideas to try out. You might need a few lines of script to accomplish what you want, but you should definitely be able to implement this in E-Prime. Thanks, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Matt Conroy [mailto:mconroy at ucsd.edu] > Sent: Wednesday, October 08, 2003 4:43 PM > To: eprime at mail.talkbank.org > Subject: Pausing and Resuming during a procedure > > I am creating an experiment that requires subjects to orally identify > visual stimuli, which are presented sequentially. > I want to make a subject input that can pause the stimulus presentation > (during which the current stimulus remains on the screen indefinitely) and > a > second input that causes the stimulus presentation to resume normally. > It is important to record the time of these inputs, or the stimulus > during > which they occurred. > > Thank you for any advice. > > Matt Conroy > Graduate Student > UC San Diego Psychology Dept > mconroy at ucsd.edu > > From bmb at buffalo.edu Sun Oct 12 20:07:41 2003 From: bmb at buffalo.edu (Breton M Bienvenue) Date: Sun, 12 Oct 2003 16:07:41 -0400 Subject: e-prime and eyelink? Message-ID: Greetings, I'm wondering if anybody has managed to interface e-prime and the SMI eyelink headmounted eyetracker? I know there used to be plugins for the psyscope system to interface with the eyelink. Is anybody doing anyhing like this? Thanks. -------------------------------------------------------------------------- Breton Bienvenue e-mail: bmb at acsu.buffalo.edu Psycholinguistics Lab phone: (716) 645-3650 X377 Department of Psychology fax: (716) 645-3801 SUNY at Buffalo lab webpage: http://psychling.buffalo.edu Buffalo, NY 14260 personal webpage: http://www.buffalo.edu/~bmb -------------------------------------------------------------------------- From myanagi at vapop.ucsd.edu Mon Oct 13 18:47:43 2003 From: myanagi at vapop.ucsd.edu (Matt Yanagi) Date: Mon, 13 Oct 2003 11:47:43 -0700 Subject: E-Prime and fORP Message-ID: I was hoping someone might be able to point me in the right direction with a problem I'm having with the fORP and E-Prime. Here's the scenario in a nutshell... On a simple Text Display page, I'm collecting a response (via the fORP), recording the RT and the selection. However, when a repsonse is made using the fORP, the page terminates to the next. Whereas with the KEYBOARD input option (allowing me to set the time limit to "same as duration"), the page doesn't move on until the predetermined time out duration. I'm shooting for the latter, but using the fORP. When selecting PORT (I'm using CKUBED) as the input device, there's no options like that of the keyboard. Any suggestions? Thanks, Matt Yanagi From ndpm at email.unc.edu Tue Oct 14 13:10:28 2003 From: ndpm at email.unc.edu (Nicole Pukay-Martin) Date: Tue, 14 Oct 2003 09:10:28 -0400 Subject: flicker Message-ID: I am creating a program that has two very quick (about 33ms) presentations, each one containing nine bitmap images. In the original program, the timing was not correct due to the large amount of information that had to be loaded. I then tried to preload the images by loading the files for both presentations and then having two SlideObject.Draw commmands at the very end of the script. This appears to fix the timing problem, but now there is a quick flicker at the beginning of each trial. We can only see the flicker when the two presentations are set to appear for a longer amount of time (999ms each). The flicker goes by so quickly that we can't tell what exactly it is; however, we suspect that it may be presenting some of the bitmap files while it is loading the images. Has anyone else encountered this kind of problem? Any ideas for how to fix it? Thanks! Nicole Pukay-Martin Research Assistant UNC Cognitive Aging Lab From ftornay at ugr.es Tue Oct 14 15:15:20 2003 From: ftornay at ugr.es (ftornay at ugr.es) Date: Tue, 14 Oct 2003 17:15:20 +0200 Subject: flicker In-Reply-To: <1066137028.3f8bf5c4b4b23@webmail8.isis.unc.edu> Message-ID: Flickering is a common problem when one tries to program animation or present brief images, no matter which software is used. It may appear every time only one part of the screen is updated. The general solution is to copy a large portion of the screen or even the whole screen. First try waiting for a vertical display and clearing the wole screen before drawing the second presentation: display.waitforverticalblank presentation1.draw sleep 33 display.waitforverticalblank display.canvas.clear display.waitforverticalblank presentation2.draw sleep 33 display.waitforverticalblank display.canvas.clear With this code you may skip a refresh cycle for every presentation. You may be better off shortening the sleep times to, say, 30 ms if your refresh rate is about 60, as is usually the case. The real presentation time would be about two refresh cycles, so 33 ms, more or less. Take into account that erasing the screen between presentations would take an extra refresh cycle. There are ways of recording the actual presentation times. If this doesn't work you should consider using canvas, rather than display objects, which I think is the best method for presenting very brief images. In either case, I could help you with the details of the code if you let me know more about your procedure. Hope this helps, Francisco J. Tornay Universidad de Granada From morrct at andrew.cmu.edu Wed Oct 15 13:22:27 2003 From: morrct at andrew.cmu.edu (Mark G Orr) Date: Wed, 15 Oct 2003 09:22:27 -0400 Subject: Script too large to compile Message-ID: Hello, i searched the archives, but could not find how to solve the following problem. THe error message was: "Complile Error (Line 3118, Col 42) 76: Script is too large to be compiled" Any ideas? -Mark Orr ________________________________ Mark G. Orr Postdoctoral Research Fellow Dept. of Psychology, RM 330 Baker Carnegie Mellon University Pittsburgh, PA 15213 phone: 412.268.4237 fax: 412.268.2798 email: morrct at andrew.cmu.edu From anthony.zuccolotto at pstnet.com Wed Oct 15 13:29:46 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Wed, 15 Oct 2003 09:29:46 -0400 Subject: Script too large to compile Message-ID: Mark, This typically results from exceeding the maximum constant/string space allowed by the E-Basic compiler. Most often this happens when you used a very large number of objects in your experiment, e.g. by declaring a unique procedure to present each stimulus rather than declaring the stimuli on Lists and using one procedure with a single stimulus presentation object whose content is set to be pulled from an attribute on the List. Also, E-Prime 1.1 (as opposed to E-Prime 1.0) modifies the way it writes out it's script to initialize objects to help with this problem. If you by chance haven't yet upgraded to 1.1 and the latest service pack you should do so. Hope this helps, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Mark G Orr [mailto:morrct at andrew.cmu.edu] > Sent: Wednesday, October 15, 2003 8:22 AM > To: eprime list > Subject: Script too large to compile > > Hello, i searched the archives, but could not find how to solve the > following problem. THe error message was: > > "Complile Error (Line 3118, Col 42) > 76: Script is too large to be compiled" > > Any ideas? > > > -Mark Orr > > > > > > > ________________________________ > Mark G. Orr > Postdoctoral Research Fellow > Dept. of Psychology, RM 330 Baker > Carnegie Mellon University > Pittsburgh, PA 15213 > > phone: 412.268.4237 > fax: 412.268.2798 > email: morrct at andrew.cmu.edu From devo0023 at tc.umn.edu Wed Oct 15 14:01:25 2003 From: devo0023 at tc.umn.edu (Cynthia J DeVore) Date: Wed, 15 Oct 2003 09:01:25 -0500 Subject: Script too large to compile In-Reply-To: Message-ID: Mark, I've still had problems with this, even running 1.1. You can solve this in one of two ways (or a combination of the two): 1) Streamline Experiment * Have you mistakenly created copies of identical display objects (Slide2 = Slide1) instead of reusing objects? * Are some display objects more similar than different? Can you possibly add an attribute to a list to then reuse a display object? * Can your lists be made into embedded files? It's really easier to maintain that way and you have access to Spell Check. 2) Break the Experiment into pieces * You can call a second E-Prime experiment from a first experiment with a simple call. You can even pass through the same startup information. What follows is a package I wrote to do just this. It might need some tweaking as I hurriedly culled it from a larger package. Cynthia [Header] PackageName="ExperimentNavigation" Description="Move from Experiment to Experiment" VersionMajor=1 VersionMinor=0 VersionInternal=0 VersionRevision=0 [Global] [InitPackages] ' *** Package initialization [UnInitPackages] ' *** Package cleanup [Desc_ExperimentNavigation_GoToNextProgram] Overview: This inline code calls an E-Prime program, supplying selected session attributes. Requirements: * The StartUp Info Parameters for the called program must match those in the package call for order. * Subject number MUST be the first parameter in the called program * In the called program, turn OFF the "display of the summary to confirm the values". * E-Run.exe must be located in c:\My Programs\PST\E-Prime\Program\ Parameters: c = Context (required) ProgramName = Name of the program, without the extension (required) DisplayCall = True/False: If true, a messagebox will show the call. This is helpful when debugging. Path = Path to the program (optional: default is same path as current program) InfoParameter, InfoParameter, ... = StartUp Info Parameters needed by the called program. All parameters must be in the order in which they will be prompted by the called program. The Subject number is automatically generated based upon the current subject number. All other parameters are optional. Remarks: [Info_ExperimentNavigation_GoToNextProgram] DefaultParameters="c,\"Replace with called program name without extension\",False" [PreSub_ExperimentNavigation_GoToNextProgram] [Sub_ExperimentNavigation_GoToNextProgram] Public Sub ExperimentNavigation_GoToNextProgram(c as context, _ CalledProgramName as String, _ DisplayCall as Boolean, _ Optional CalledProgramPath as Variant, _ Optional Parm1 as Variant, _ Optional Parm2 as Variant, _ Optional Parm3 as Variant, _ Optional Parm4 as Variant, _ Optional Parm5 as Variant, _ Optional Parm6 as Variant, _ Optional Parm7 as Variant, _ Optional Parm8 as Variant) Dim Subject as Integer Dim Parm as String Dim ebQuote as String Dim ebSlash as String Dim TempFileName as string Dim ParmList (1 to 8) as String Dim ParmCount as Integer Dim ParmIndex as Integer Dim tempparm as String Dim ProgramPath as String Dim id as variant Dim CalledProgramPart1 as string Dim CalledProgramPart2 as string Dim MessageToDisplay as string ebQuote = Chr(34) ebSlash = Chr(92) CalledProgramPart1 = ebquote & "c:" & ebSlash & "program files" & _ ebSlash & "pst" & ebSlash & "e-prime" & ebSlash & "program" & _ ebSlash & "e-run.exe" & ebquote & space(1) & ebquote & "/a" & _ ebquote & space(1) & ebQuote & "/m" & ebquote & space(1) & ebquote ' Get the standard parameter Subject = c.getattrib("Subject") ' Get the path If ismissing(calledProgramPath) Then tempparm = c.datafile.filename ProgramPath = FileParse$(tempparm,2) Else ProgramPath = CalledProgramPath End If ' Fill the ParmList with the optional parameters If Not IsMissing(Parm1) Then ParmList(1) = Parm1 MessageToDisplay = "\n" & ParmList(1) ParmCount = 1 End If If Not IsMissing(Parm2) Then ParmList(2) = Parm2 MessageToDisplay = "\n" & ParmList(2) ParmCount = 2 End If If Not IsMissing(Parm3) Then ParmList(3) = Parm3 MessageToDisplay = "\n" & ParmList(3) ParmCount = 3 End If If Not IsMissing(Parm4) Then ParmList(4) = Parm4 MessageToDisplay = "\n" & ParmList(4) ParmCount = 4 End If If Not IsMissing(Parm5) Then ParmList(5) = Parm5 MessageToDisplay = "\n" & ParmList(5) ParmCount = 5 End If If Not IsMissing(Parm6) Then ParmList(6) = Parm6 MessageToDisplay = "\n" & ParmList(6) ParmCount = 6 End If If Not IsMissing(Parm7) Then ParmList(7) = Parm7 MessageToDisplay = "\n" & ParmList(7) ParmCount = 7 End If If Not IsMissing(Parm8) Then ParmList(8) = Parm8 MessageToDisplay = "\n" & ParmList(8) ParmCount = 8 End If tempparm = ProgramPath & ebSlash & CalledProgramName & ".ebs" CalledProgramPart2 = CalledProgramPart1 & tempparm & ebquote ' Display the call if requested If DisplayCall Then Msgbox "This program, generating data file " & c.datafile.filename & " is calling " & _ tempparm & " with the following " & _ format$(ParmCount,"0") & " parameters: " & MessageToDisplay & "\n" & _ "The following string will be sent to the shell: " & CalledProgramPart2 End If If FileExists(tempparm) Then id = Shell (CalledProgramPart2, ebNormalFocus) SendKeys Subject, True SendKeys "{ENTER}", True For ParmIndex = 1 to ParmCount tempparm = c.getattrib(ParmList(ParmIndex)) SendKeys tempparm, True SendKeys "{ENTER}", True Next ParmIndex Else MsgBox "Program " & tempparm & " does not exist." End If End Sub [PostSub_ExperimentNavigation_GoToNextProgram] ' *** no script needed At 08:22 AM 10/15/2003, Mark G Orr wrote: >Hello, i searched the archives, but could not find how to solve the >following problem. THe error message was: > >"Complile Error (Line 3118, Col 42) >76: Script is too large to be compiled" > >Any ideas? > > >-Mark Orr > > > > > > >________________________________ >Mark G. Orr >Postdoctoral Research Fellow >Dept. of Psychology, RM 330 Baker >Carnegie Mellon University >Pittsburgh, PA 15213 > >phone: 412.268.4237 >fax: 412.268.2798 >email: morrct at andrew.cmu.edu Cynthia J. DeVore Graduate Student University of Minnesota - Industrial/Organizational Psychology devo0023 at tc.umn.edu 612-624-3601 Office hours for E-Prime Consultant: http://online.psych.umn.edu/IS/Elliott160/Calendar/200310.htm E-Prime @ U of MN http://online.psych.umn.edu/IS/Eprime/index.htm From gtrafton at osf1.gmu.edu Thu Oct 16 19:33:51 2003 From: gtrafton at osf1.gmu.edu (Greg Trafton) Date: Thu, 16 Oct 2003 15:33:51 -0400 Subject: data analysis Message-ID: Hi, All. I used eprime for a study several months ago. alas, I no longer have access to the data analysis programs and am a bit confused by the data. part of it is below. I understand Graph.RESP (the answer the subject gave me). however, Graph.RT and Graph.RTTime seem to be "odd" -- I haven't checked every file, but on average, this participant is taking about 10000 RT (I assume it's in ms), which is *much* longer than I would have expected. so my questions are: 1) is Graph.RT really ms? if not, how do I convert it to ms? 2) what is the diff between RT and RTTime (if I subtract Graph.RTTime2 from Graph.RTTime1 (consecutive subtractions), I get a number that's close Graph.RT number (but always slightly bigger) 3) how do I figure out how long it took to enter each answer? thanks! greg Subject filename Graph.RESP Graph.RT Graph.RTTime 1 example.line.ro.890.1.bmp NULL NULL NULL 1 example.line.ro.305.4.bmp NULL NULL NULL 1 example.log.ro.227.6.12.100.200.0.5.bmp NULL NULL NULL 1 example.log.ro.733.11.400.700.1.bmp NULL NULL NULL 1 example.sin.far.193.6.45.0.37.bmp NULL NULL NULL 1 example.sin.far.187.4.25.0.33.bmp NULL NULL NULL 1 demo.line.far.430.1.bmp 440 24568 7620724 1 demo.line.ro.282.5.4.bmp 285 39914 7672700 1 demo.sin.ro.160.2.25.0.33.bmp 125 45722 7719915 1 demo.sin.near.105.45.0.37.bmp 137 12438 7733609 1 demo.log.far.948.2.11.750.900.1.bmp 945 23141 7757950 1 demo.log.near.482.5.12.150.450.0.5.bmp 481 24069 7782678 1 h.line.ro.433.3.1.5.bmp 432 21175 7838177 1 a.sin.far.150.1.40.0.26.bmp 159 10950 7850569 1 c.line.ro.339.2.2.4.bmp 340 16038 7867188 1 b.line.near.321.7.1.2.bmp 308 17652 7885414 1 i.line.far.390.3.bmp 372 8526 7894983 1 e.log.near.310.2.3.750.300.1.bmp 309 13958 7909581 1 b.sin.far.180.5.20.0.32.bmp 198 11486 7921707 1 j.log.far.315.2.3.100.300.2.bmp 312 15252 7937496 1 b.line.near.405.2.bmp 400 7705 7945835 1 j.line.ro.329.1.2.2.bmp 339 15416 7962080 1 j.sin.near.273.5.50.0.29.bmp 230 13780 7977150 1 k.line.far.543.3.1.2.bmp 500 29025 8007250 1 f.sin.near.166.8.40.0.38.bmp 170 5070 8012737 1 b.log.far.137.2.8.5.550.100.1.bmp 140 9421 8022649 From jeff.larsen at ttu.edu Fri Oct 17 18:46:17 2003 From: jeff.larsen at ttu.edu (Larsen, Jeff) Date: Fri, 17 Oct 2003 13:46:17 -0500 Subject: IAT in Eprime Message-ID: Dear Eprime users: Has anyone implemented Greenwald's Implicit Association Task (IAT) in Eprime? If so, I would greatly appreciate a copy of the EBS file. Thanks, Jeff *************************************************** Jeff T. Larsen, PhD Department of Psychology Texas Tech University phone: 806-742-3711 x234 fax: 806-742-0818 email: jeff.larsen at ttu.edu web: http://webpages.acs.ttu.edu/jelarsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From macw at cmu.edu Fri Oct 17 20:15:26 2003 From: macw at cmu.edu (Brian MacWhinney) Date: Fri, 17 Oct 2003 16:15:26 -0400 Subject: IAT in Eprime In-Reply-To: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD03846836@BRONTES.net.ttu.edu> Message-ID: Dear Eprime Users, Jeff's message raises a slightly more general issue. We have constructed a collection of nearly 100 Eprime scripts implementing classic experiments at step.psy.cmu.edu. We would very much like to be able to add to this collection. So, if you have implemented a classic or commonly-used paradigm in Eprime, we would much appreciate receiving both the EBS file, related stim files, and a pointer to the published article that the experiment is replicating or implementing. We will happily cite each contributor as the source of the contribution. Perhaps you can even add this to your CV. --Brian MacWhinney, CMU > On 10/17/03 2:46 PM, "Larsen, Jeff" wrote: > Dear Eprime users: > > Has anyone implemented Greenwald's Implicit Association Task (IAT) in > Eprime? If so, I would greatly appreciate a copy of the EBS file. > From odenthal at soz.psychologie.uni-konstanz.de Mon Oct 20 13:42:25 2003 From: odenthal at soz.psychologie.uni-konstanz.de (Georg Odenthal) Date: Mon, 20 Oct 2003 15:42:25 +0200 Subject: flicker Message-ID: I've recently tried to create subliminal priming experiment with E-Prime and also found out about the screen flicker. So I had to abandon this project using E-Prime and went back to MEL2 where you can avoid this screen flicker by using double buffering or a color switching trick (explained later). It's strange that PST didn't include the double buffering feature from MEL2 in E-Prime since it is such a useful technique for subliminal priming studies. Double buffering refers to the possibility to store two different screens in two different screen banks in the memory. Modern graphics cards hold several frame buffers in their 64MB or 128MB of frame buffer. Switching between one buffer and another can be done with a few commands in virtually no time. Unfortunately this feature doesn't seem to be included in E-Prime. I wasn't able to find any information on creating and switching between frame buffers in the E-Prime Reference guide. On page 97 of the Reference Guide there is the method "DisplayDevice.RestoreVideoBuffers (method)" listed, but neither in the manual nor in the E-Basic help seems to be any more information on that. When a Display Object is painted using the DisplayObject.draw method a software creates the screen display or copies a preloaded image from the memory to the screen. This can take a lot of time depending on the screen size and the color depth. I've written a small program to demonstrate how much time this Draw command can take. I'm including the E-Basic InlineObject with this email. Besides that you need to create two TextDisplays called Black and White (one with Black background and one with White background, both are opaque. Make sure to set the Default Duration to 0) Create another TextDisplay called CollectResp, set the Duration to 0, EndAction to "(none)", TimeLimit to 10000 (for 10 seconds) and add a Keyboard input collecting any key response. Insert the CollectResp object as first item into SessionProc and the Inline Script as second. Enter the following commands into the Inline Script: 'Repeat loop until a keyboard response was made While CollectResp.InputMasks.IsPending() 'Wait for frameflyback display.waitforverticalblank 'Display black background Black.draw 'Wait for frameflyback display.waitforverticalblank 'Display white background White.draw 'Give the computer some time to collect a keyboard response sleep 1 wend When you run this script your screen will present you a very quick black and white flicker. But usually you will also see that a part on top of the screen looks somewhat displaced. This displacement is a measurement of the time the draw method takes to paint the black or white background on the screen. This time is dependent on the speed of the computer, on the refresh frequency of the screen (e.g. 60 Hz, 75Hz, ...) and on the screen resolution as well as on the color depth of the screen. In most cases you cannot change the speed of the computer (unless your lab computers have a faster processor than your E-Prime development computer). The refresh cycle of the screen is dependent on the manufacturer and model of the screen and usually cannot be changed as well. What you can do is change the screen resolution and color depth. To do that double click on the Experiment Object, go to the Devices tab, double click on the Display item. A window with the name "Edit DisplayDevice Properties" should pop up. There you can change the screen resolution and color depth of the program. The default values are 640 * 480 with 16 bits color depth. Try for example to switch the resolution to 1024 * 768 with 24 bits color depth. When you run the program the displacement on top of the screen will be a lot larger, because it takes a lot more time to fill a screen with 1024 * 768 pixels with 24 bit color depth. If you change to 640 * 480 with 8 bits color depth the displacement gets a lot smaller. Why is that so? A screen resolution of 640 * 480 means that there are 640 points in each horizontal line on the screen and there are a total of 480 lines per screen. That is 640 * 480 pixels = 307200 pixels. The color depth 16 means that you can display one of 65536 colors in each pixel. A byte takes up 8 bits, that is 16 bits means each pixel has two bytes on the screen. So the 307200 pixels need two bytes each that is the screen memory is 307200 * 2 = 614400. In kilobytes that is 614400 / 1024 = 600 kb per screen. This is not very much memory compared to the main memory of modern computers and graphics cards. Copying 600 kb from the memory to the screen doesn't take up too much calculation time. Now how much memory does the computer need to copy from the memory to the screen in the 1024 * 768 example. Pixels per screen: 1024 * 768 = 786432 pixels Color depth 24 bits: 3 bytes per pixel Memory taken: 786432 pixels * 3 bytes/ pixels = 2359296 bytes in Kilobytes: 2359296 / 1024 = 2304 (equals 2.25 mb). Copying 2.25 mb to the screen takes a lot more time since it's almost four times as much memory as the 640 * 480 resolution. I've also tried to display images that were pre-loaded into the memory, but I've received exactly the same effect. The displacement line showed up at virtually the same place as in the TextDisplay example above. This displacement line shows the position where the routine that copies the screen display from the memory to the video ram in the graphics card overtakes the video beam that displays the pixels in the video ram on the screen. That is on top of the displacement line you still see the previous frame whereas below the displacement line the new frame is being painted. This results in a partial display of two different images. If you want to display subliminal stimuli on the screen this displacement line can become a huge problem if is within the stimulus you want to display. In this case the subjects would only see the bottom part of the stimulus on one frame and then the top part of the stimulus and the bottom part of the mask in the next. (And then the top part of the mask in the screen after that). This can probably render your subliminal priming useless or at least make your discussion difficult since you have to argue in the discussion that presenting stimuli that are split in half still have the same effect than stimuli that are presented as a whole. We wanted to create study where words are presented subliminally in the parafoveal field. But since E-Prime couldn't guarantee that the words are always presented as whole we switched back to MEL2 to create this study in MSDOS. Unless there is a method in E-Prime to flip between two different screen buffers in the video RAM of the graphics card I won't try to create subliminal priming studies with E-Prime again. The danger of loosing the data of a study with a hundred or more subjects due to this displacement bug is too costly for our lab. For displaying simple stimuli there is a different method than copying pre-loaded images on the screen: the color switching trick. This color switching trick is only possible in a 256 (8-bit) color mode. With it you can present up to 8 different stimuli in a short succession without running into the problems above. In this trick you create stimuli with a program that supports an XOR (or also called EOR) overlay mode for painting text on the screen (e.g. MEL2 is capable of doing that with the SET_RASTEROP_MODE command.) E-Prime doesn't offer an XOR overlay mode, it has only ebROPModeCopy or ebROPModeMerge though. XOR is short for eXclusiveOR. If you paint something on the screen, the bits of each pixel will only be painted unaltered if the background bit is 0. Else the bit will flip it's value (e.g. 1 and 0 or 0 and 1 will become 1 and 1 and 1 will become 0). If you paint two words in different colors over one another the result will look like an abstract painting. But by redefining specific colors you can make either one or the other word visible. (it also with 3 up to 8 words.) We used this method in MEL2 a lot since the double buffering was only available in very weird screen modes (e.g. 640 x 350) in which text looked very deformed. The trick with this method is to know which colors you need to redefine. But there's a simple solution: A byte contains of 8 bits, e.g. 10010001 (this is also called binary notation). The leftmost bit is the MSB (most significant bit) and has a value of 2 to the power of 7 = 128, the rightmost bit is the LSB (least significant bit) and has a value of 2 to the power of 0 = 1. The bits in between have the values 64, 32, 16, 8, 4 and 2 respectively. If you overlay text in the XOR mode in any of these 8 values, you will have a distinct color bit for each of the 8 different stimuli. That is if you paint a prime in color 2 (as byte: 00000010) on the screen and overlay it with a target in color 8 (as byte: 00001000). The color where both text overlap with one another will be 8 + 2 = 10 (00001010). So if you want to display the prime you need to set the RGB values of the color 8 to the RGB values of the background color and set the values of both, color 2 and color 10 to the foreground RGB values. For the target you need to set the color 2 to the background color and colors 8 and 10 to the foreground color. If you want to display 3 different words in quick succession you can for example select the colors 1, 2 and 4. If you want to display the first word set: 1, 3, 5 and 7 to foreground and 2, 4 and 6 to background for the second word set: 2, 3, 6, and 7 to foreground and 1, 4 and 5 to background for the third word set: 4, 5, 6 and 7 to foreground and 1, 2 and 3 to background With every additional stimulus you add to this scheme the numbers of colors you have to redefine doubles. So if you want to display 5 different stimuli you need to redifine 31 colors for each word with 8 stimuli you need to redefine all 255 colors for each word. Switching colors is in E-Prime a lot faster than copying complete screens to the video ram. You can use the DisplayDevice.Palette method to set all 256 of a 8 bit color mode. I've written a small program that does just that. I will just include a part of the InlineScript since it is too large to be copied into this email as a whole: Dim thePal As Palette Dim i as Integer Dim factor as Integer Set thePal = Display.Palette Dim arrEntries(255) As PaletteEntry Dim prime(255) As PaletteEntry Dim mask(255) As PaletteEntry thePal.GetEntries 0, 256, arrEntries [... 'Color redefinition is done in this omitted part] 'Wait for frameflyback display.waitforverticalblank 'Set the palette thePal.SetEntries 0, 256, arrEntries 'Repeat loop until a keyboard response was made While CollectResp.InputMasks.IsPending() 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, prime sleep 1 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, mask sleep 1 'Wait for frameflyback display.waitforverticalblank 'Set the palette and wait for keypress thePal.SetEntries 0, 256, arrEntries sleep 1 wend If you're interested in the program, I can send you the whole program including the test screen with the two stimuli as a ZIP archive. The drawbacks of this color switching trick are besides the increasing number of colors you need to redefine are also, that you are limited to 8 colors and that your text cannot use anti-aliasing (smoothing) of the font, since this adds several colors (usually gray nuances) to the image. But as long as E-Prime cannot perform real frame buffer switching this seems to be the only method available to ensure a quick and complete display of subliminal stimuli. If you have any questions or are interested in the programs discussed in this email you can write to the address below. Best regards, Georg Odenthal ========================================================================= Georg Odenthal (Dipl.-Psych.) University of Konstanz +49 (0)7531 88-2872 Department of Psychology odenthal at soz.psychologie.uni-konstanz.de Social Psychology and Motivation http://www.socpsych.uni-konstanz.de 78457 Konstanz, Germany ========================================================================= From jpettib at siue.edu Mon Oct 20 15:22:29 2003 From: jpettib at siue.edu (Jonathan Pettibone) Date: Mon, 20 Oct 2003 10:22:29 -0500 Subject: Cleartype problems In-Reply-To: <476593089.20031020154225@soz.psychologie.uni-konstanz.de> Message-ID: Has anyone else noticed that having cleartype enables creates display problems in E-Prime? Using a 640 x 480 screen and the slide procedure, a text box containing a variable read from a list was always cut in half, or sometimes more, so that you could only see a portion of the text. I've got a bunch of similar text boxes on the screen, but that only happened to one of them. I don't know if this is a known problem or not, but it drove me so nuts trying to figure out what was wrong that I wanted to share this with the list. Jonathan Pettibone Jonathan Pettibone Assistant Professor Dept. of Psychology Southern Illinois University Edwardsville Edwardsville, IL 62026 From ftornay at ugr.es Tue Oct 21 12:34:53 2003 From: ftornay at ugr.es (ftornay at ugr.es) Date: Tue, 21 Oct 2003 14:34:53 +0200 Subject: flicker and double buffering In-Reply-To: <476593089.20031020154225@soz.psychologie.uni-konstanz.de> Message-ID: The issues brought about by Georg Odenthal are very interesting and I would greatly appreciate it, Georg, if you could send me your programs. However, the flickering problem can be solved just by copying large portions of the screen from a offscreen canvas object, no matter how long the copying process takes. For instance '*** Code in the script user tab 'declare variable for offscreen buffer dim offscreen as canvas '*** Inline object at the beginning of the experiment 'create offscreen canvas set offscreen = display.createcanvas 'and, for instance, load a file, it would also be possible to combine different 'images by copying several canvas objects to the offscreen object offscreen.loadimage "bluecar.bmp" '*** Inline object on every trial 'Wait for vertical blank display.WaitForVerticalBlank 'copy offscreen to actual screen display.canvas.copy offscreen The main thing is to copy all or most of the offscreen buffer to the screen, that should take care of the flickering. That implements a software double buffering system. A complete separate question is how long it takes for the image to be copied. In that sense the ideas presented by Georg about hardware double buffering as implemented by MEL2 (only for very low-resolution modes) are relevant. I have tried a little experiment by using an experiment I wrote in response to Nicole's original question. I just copied such an offscreen buffer using a 640 * 480, 16-bit screen mode. Immediately after the inline I used a wait object without vertical blank synchrony. According to the data file, the onsetdelay variable for that object is 17 ms. If the program waits until the image is copied before presenting the wait object, this time should equal (or maybe be larger than) the time required for copying the whole screen. Do you think that is correct? How reliable is it? If you think I can trust the data, I could also see what happens in higher-resolution display modes. If it were correct, it would mean that the delay equals one refresh cycle (my refresh rate is about 60). You can't go below that and still be sure the whole screen is presented to the subject. This would make discussion about quicker copying methods rather accademic, unless one is very interested in using very high-resolution modes. At any rate, MEL2 would never be better than E-prime: if you can use a resolution low enough for MEL then you can also present the information in E- prime as quick as possible for your hardware. You could even do it with much better resolution modes: MEL2 can't handle the mode I've used and much less if you want to use hardware double buffering methods which are only possible for EGA modes, at least if you want two whole-sized screen buffers. Please if I'm wrong or I'm missing something, please let me know. From anthony.zuccolotto at pstnet.com Tue Oct 21 13:17:43 2003 From: anthony.zuccolotto at pstnet.com (Tony Zuccolotto) Date: Tue, 21 Oct 2003 09:17:43 -0400 Subject: flicker Message-ID: Georg, I will try to create a more in depth response later this week, but you essentially should be able to do what you want in E-Prime and eliminate the flicker. You are correct that the hardware based page flipping that was directly supported in MEL is not there in the exact same form in E-Prime. Support for multiple offscreen buffers/canvases however is there and is more powerful than what was offered in MEL. Without going into a lot of detail, it was not possible for us to implement the hardware based page flipping feature and have it coexist with the other operations of all the other objects in E-Prime. For example, since E-Prime always runs in graphics rather than text mode, we had to provide support for echoing back responses over top of images better than was done in MEL. Features like these were basically incompatible with the E-Prime model without sacrificing the general performance of the system. Further, when we initially attempted it, the performance of the hardware page flipping vs Canvas.Copy was not significantly better on most video cards (e.g. both were sub-millisecond). I expect though, that the actual problem you are running into is that the Windows drivers for many video cards perform bitmap fills/transfers from the bottom up, thus rather than the copying of the image data starting at the top of the screen and filling down (while staying ahead of the refresh), the image data starts at the bottom and fills towards the top at which point the image fill and the refresh cross each other and you may get something like you describing. E-Prime 1.1 included advanced features that allow you to instruct the system to automatically split these bitmaps up into smaller portions which are drawn starting at the portion at the top of the screen. Checkout the E-Prime Knowledge Base article http://www.pstnet.com/e-prime/support/kb.asp?TopicID=1274 and/or DisplayDevice.SegmentCopyHeight, DisplayDevice.SegmentCopyVerticalOffset in the E-Basic help (E-Prime 1.1). In all instances I have been aware of where this problem was observed, these commands could be used to minimize or eliminate the visual problem at the top of the screen. Thanks, Tony *** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS *** Anthony P. Zuccolotto Vice President Psychology Software Tools, Inc. 2050 Ardmore Boulevard Suite 200 Pittsburgh, PA 15221-4610 Phone 412-271-5040 FAX 412-271-7077 Email anthony.zuccolotto at pstnet.com Internet http://www.pstnet.com > -----Original Message----- > From: Georg Odenthal [mailto:odenthal at soz.psychologie.uni-konstanz.de] > Sent: Monday, October 20, 2003 8:42 AM > To: eprime at mail.talkbank.org > Subject: Re: flicker > > I've recently tried to create subliminal priming experiment with > E-Prime and also found out about the screen flicker. So I had to > abandon this project using E-Prime and went back to MEL2 where you can > avoid this screen flicker by using double buffering or a color > switching trick (explained later). > > It's strange that PST didn't include the double buffering feature from > MEL2 in E-Prime since it is such a useful technique for subliminal > priming studies. > > Double buffering refers to the possibility to store two different > screens in two different screen banks in the memory. Modern graphics > cards hold several frame buffers in their 64MB or 128MB of frame > buffer. Switching between one buffer and another can be done with a > few commands in virtually no time. > > Unfortunately this feature doesn't seem to be included in E-Prime. > I wasn't able to find any information on creating and switching > between frame buffers in the E-Prime Reference guide. On page 97 of > the Reference Guide there is the method > "DisplayDevice.RestoreVideoBuffers (method)" listed, but neither in > the manual nor in the E-Basic help seems to be any more information on > that. > > When a Display Object is painted using the DisplayObject.draw method > a software creates the screen display or copies a preloaded image from > the memory to the screen. This can take a lot of time depending on the > screen size and the color depth. > > I've written a small program to demonstrate how much time this Draw > command can take. I'm including the E-Basic InlineObject with this > email. Besides that you need to create two TextDisplays called Black > and White (one with Black background and one with White background, > both are opaque. Make sure to set the Default Duration to 0) > > Create another TextDisplay called CollectResp, set the Duration to 0, > EndAction to "(none)", TimeLimit to 10000 (for 10 seconds) and add a > Keyboard input collecting any key response. > > Insert the CollectResp object as first item into SessionProc and the > Inline Script as second. > > Enter the following commands into the Inline Script: > > 'Repeat loop until a keyboard response was made > While CollectResp.InputMasks.IsPending() > > 'Wait for frameflyback > display.waitforverticalblank > 'Display black background > Black.draw > 'Wait for frameflyback > display.waitforverticalblank > 'Display white background > White.draw > 'Give the computer some time to collect a keyboard response > sleep 1 > wend > > When you run this script your screen will present you a very quick > black and white flicker. But usually you will also see that a part on > top of the screen looks somewhat displaced. This displacement is a > measurement of the time the draw method takes to paint the black or > white background on the screen. This time is dependent on the speed of > the computer, on the refresh frequency of the screen (e.g. 60 Hz, > 75Hz, ...) and on the screen resolution as well as on the color depth > of the screen. > > In most cases you cannot change the speed of the computer (unless your > lab computers have a faster processor than your E-Prime development > computer). The refresh cycle of the screen is dependent on the > manufacturer and model of the screen and usually cannot be changed as > well. > > What you can do is change the screen resolution and color depth. To do > that double click on the Experiment Object, go to the Devices tab, > double click on the Display item. A window with the name "Edit > DisplayDevice Properties" should pop up. > > There you can change the screen resolution and color depth of the > program. The default values are 640 * 480 with 16 bits color depth. > Try for example to switch the resolution to 1024 * 768 with 24 bits > color depth. When you run the program the displacement on top of the > screen will be a lot larger, because it takes a lot more time to fill > a screen with 1024 * 768 pixels with 24 bit color depth. > > If you change to 640 * 480 with 8 bits color depth the displacement > gets a lot smaller. > > Why is that so? > > A screen resolution of 640 * 480 means that there are 640 points in > each horizontal line on the screen and there are a total of 480 lines > per screen. That is 640 * 480 pixels = 307200 pixels. > > The color depth 16 means that you can display one of 65536 colors in > each pixel. A byte takes up 8 bits, that is 16 bits means each pixel > has two bytes on the screen. So the 307200 pixels need two bytes each > that is the screen memory is 307200 * 2 = 614400. In kilobytes that is > 614400 / 1024 = 600 kb per screen. This is not very much memory > compared to the main memory of modern computers and graphics cards. > Copying 600 kb from the memory to the screen doesn't take up too much > calculation time. > > Now how much memory does the computer need to copy from the memory to > the screen in the 1024 * 768 example. > Pixels per screen: 1024 * 768 = 786432 pixels > Color depth 24 bits: 3 bytes per pixel > Memory taken: 786432 pixels * 3 bytes/ pixels = 2359296 bytes > in Kilobytes: 2359296 / 1024 = 2304 (equals 2.25 mb). > > Copying 2.25 mb to the screen takes a lot more time since it's almost > four times as much memory as the 640 * 480 resolution. > > I've also tried to display images that were pre-loaded into the > memory, but I've received exactly the same effect. The displacement > line showed up at virtually the same place as in the TextDisplay > example above. > > This displacement line shows the position where the routine that > copies the screen display from the memory to the video ram in the > graphics card overtakes the video beam that displays the pixels in the > video ram on the screen. That is on top of the displacement line you > still see the previous frame whereas below the displacement line the > new frame is being painted. This results in a partial display of two > different images. > > If you want to display subliminal stimuli on the screen this > displacement line can become a huge problem if is within the stimulus > you want to display. In this case the subjects would only see the > bottom part of the stimulus on one frame and then the top part of the > stimulus and the bottom part of the mask in the next. (And then the > top part of the mask in the screen after that). > > This can probably render your subliminal priming useless or at least > make your discussion difficult since you have to argue in the > discussion that presenting stimuli that are split in half still have > the same effect than stimuli that are presented as a whole. > > We wanted to create study where words are presented subliminally in > the parafoveal field. But since E-Prime couldn't guarantee that the > words are always presented as whole we switched back to MEL2 to create > this study in MSDOS. > > Unless there is a method in E-Prime to flip between two different > screen buffers in the video RAM of the graphics card I won't try to > create subliminal priming studies with E-Prime again. The danger of > loosing the data of a study with a hundred or more subjects due to this > displacement bug is too costly for our lab. > > > For displaying simple stimuli there is a different method than copying > pre-loaded images on the screen: the color switching trick. > > This color switching trick is only possible in a 256 (8-bit) color > mode. With it you can present up to 8 different stimuli in a short > succession without running into the problems above. > > In this trick you create stimuli with a program that supports an XOR > (or also called EOR) overlay mode for painting text on the screen > (e.g. MEL2 is capable of doing that with the SET_RASTEROP_MODE > command.) E-Prime doesn't offer an XOR overlay mode, it has only > ebROPModeCopy or ebROPModeMerge though. > > XOR is short for eXclusiveOR. If you paint something on the screen, > the bits of each pixel will only be painted unaltered if the > background bit is 0. Else the bit will flip it's value (e.g. 1 and 0 > or 0 and 1 will become 1 and 1 and 1 will become 0). If you paint > two words in different colors over one another the result will look > like an abstract painting. But by redefining specific colors you can > make either one or the other word visible. (it also with 3 up to 8 > words.) > > We used this method in MEL2 a lot since the double buffering was only > available in very weird screen modes (e.g. 640 x 350) in which text > looked very deformed. > > The trick with this method is to know which colors you need to > redefine. But there's a simple solution: > > A byte contains of 8 bits, e.g. 10010001 (this is also called binary > notation). The leftmost bit is the MSB (most significant bit) and has > a value of 2 to the power of 7 = 128, the rightmost bit is the LSB > (least significant bit) and has a value of 2 to the power of 0 = 1. > The bits in between have the values 64, 32, 16, 8, 4 and 2 > respectively. > > If you overlay text in the XOR mode in any of these 8 values, you will > have a distinct color bit for each of the 8 different stimuli. That is > if you paint a prime in color 2 (as byte: 00000010) on the screen and > overlay it with a target in color 8 (as byte: 00001000). The color > where both text overlap with one another will be 8 + 2 = 10 > (00001010). > So if you want to display the prime you need to set the RGB values of > the color 8 to the RGB values of the background color and set the > values of both, color 2 and color 10 to the foreground RGB values. > > For the target you need to set the color 2 to the background color and > colors 8 and 10 to the foreground color. > > > If you want to display 3 different words in quick succession you can > for example select the colors 1, 2 and 4. If you want to display the > first word set: > 1, 3, 5 and 7 to foreground and 2, 4 and 6 to background > > for the second word set: > > 2, 3, 6, and 7 to foreground and 1, 4 and 5 to background > > for the third word set: > > 4, 5, 6 and 7 to foreground and 1, 2 and 3 to background > > With every additional stimulus you add to this scheme the numbers of > colors you have to redefine doubles. So if you want to display 5 > different stimuli you need to redifine 31 colors for each word with 8 > stimuli you need to redefine all 255 colors for each word. > > Switching colors is in E-Prime a lot faster than copying complete > screens to the video ram. You can use the DisplayDevice.Palette method > to set all 256 of a 8 bit color mode. I've written a small program > that does just that. I will just include a part of the InlineScript > since it is too large to be copied into this email as a whole: > > Dim thePal As Palette > Dim i as Integer > Dim factor as Integer > Set thePal = Display.Palette > > Dim arrEntries(255) As PaletteEntry > Dim prime(255) As PaletteEntry > Dim mask(255) As PaletteEntry > thePal.GetEntries 0, 256, arrEntries > > [... 'Color redefinition is done in this omitted part] > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette > thePal.SetEntries 0, 256, arrEntries > > 'Repeat loop until a keyboard response was made > While CollectResp.InputMasks.IsPending() > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, prime > sleep 1 > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, mask > sleep 1 > > 'Wait for frameflyback > display.waitforverticalblank > > 'Set the palette and wait for keypress > thePal.SetEntries 0, 256, arrEntries > sleep 1 > wend > > > If you're interested in the program, I can send you the whole program > including the test screen with the two stimuli as a ZIP archive. > > The drawbacks of this color switching trick are besides the > increasing number of colors you need to redefine are also, that you > are limited to 8 colors and that your text cannot use anti-aliasing > (smoothing) of the font, since this adds several colors (usually gray > nuances) to the image. > > But as long as E-Prime cannot perform real frame buffer switching this > seems to be the only method available to ensure a quick and complete > display of subliminal stimuli. > > > If you have any questions or are interested in the programs discussed > in this email you can write to the address below. > > Best regards, > Georg Odenthal > > > ======================================================================== == > > Georg Odenthal (Dipl.-Psych.) University of Konstanz > +49 (0)7531 88-2872 Department of Psychology > odenthal at soz.psychologie.uni-konstanz.de Social Psychology and Motivation > http://www.socpsych.uni-konstanz.de 78457 Konstanz, Germany > > ======================================================================== == > > From eliana_quintero at yahoo.es Tue Oct 21 18:35:42 2003 From: eliana_quintero at yahoo.es (=?iso-8859-1?q?eliana=20quintero?=) Date: Tue, 21 Oct 2003 20:35:42 +0200 Subject: shifting and divided atention Message-ID: Hi everybody... just would like to know if somebody has an experiment about shifting attention and divided attention that could share with me in order to assess the attention process in a clinical sample. thanks a lot. regards, eliana. -- Eliana Alexey Quintero-Gallego. Neuropsychologist Doctoral Student. Seville University, Psychobiology Department. Address: C/ Torneo 77, 3Der. 41002, Seville-Spain. --------------------------------- Yahoo! Messenger Nueva versión: Super Webcam, voz, caritas animadas, y más #161;Gratis! -------------- next part -------------- An HTML attachment was scrubbed... URL: From anh2bf at mizzou.edu Sat Oct 25 00:11:21 2003 From: anh2bf at mizzou.edu (Hismjatullina, Anna Nikolaevna (UMC-Student)) Date: Fri, 24 Oct 2003 19:11:21 -0500 Subject: animation Message-ID: Dear eprime users, I wish to include an animation as a contingency for successful trials in my developmental experiment. I am looking for bitmap images that will create a smooth movement. Does anybody have a good animation little children might enjoy? Thank you. Anna From baranan at post.tau.ac.il Mon Oct 27 09:49:31 2003 From: baranan at post.tau.ac.il (baranan at post.tau.ac.il) Date: Mon, 27 Oct 2003 11:49:31 +0200 Subject: equiluminant colors Message-ID: Hi Can anyone offer me a simple way to generate equiluminant colors for our epxeriments? Thanks, Yoav ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kcrando at netscape.net Wed Oct 29 15:09:18 2003 From: kcrando at netscape.net (Kenneth Rando) Date: Wed, 29 Oct 2003 10:09:18 -0500 Subject: Clock.Read or other timing method Message-ID: I need to create a 3000ms trial, in which the first part is a stimulus of fixed length 500ms. and the remainder of the trial is a 2500ms mask. User input needs to be enabled for the entire 3000 ms or until a keyboard reponse has been made. Sound feedback is given upon response, and then the mask must be redisplayed (no further input allowed) until the trial is over. I have been able to accomplish my goal when the user inputs a valid response, but not when the user fails to input a valid response within 2500 ms. I have accomplished the first goal using a Do Until...Loop. I would like to incorporate the second terminating condition in that loop as well, but I can't figure out a method. Page 91 of the e-Prime User's Guide refers to the Clock.Read method in E-Basic Online Help. I can't find the specific reference, where I was hoping to find a code example on which I could build. Does anybody have this example or a similar one? Thanks much! Ken Rando __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455