Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

[open] Using OpenSesame for M.O.T. task

edited January 2013 in OpenSesame

Hi there!

I am looking for a tool to build a M.O.T. experiment for my BSc Thesis in Psychology and Health at Tilburg University, and I was wandering if OpenSesame could do the job for me.

Basically, the idea is that subjects have to track a number of stimuli (e.g. blocks or dots) which are moving in a random pattern. The stimuli are highlighted at the beginning of the experiment. At the end of the experiment, the subjects have to point out the specific stimuli they were instructed to track (i.e. by clicking at them). The more correctly clicked stimuli, the better the tracking abilities of the subject.

I was wandering if this can be programmed in OpenSesame and if so, if there are some example templates or syntax files of similar experiments. This would help me a lot, since I am kind of a newby with OpenSesame L-)

Cheers & Thanks,
Thijs

edit: I am using the Mac OS version of OpenSesame, build 0.26

Comments

  • edited December 2012

    Hi Thijs,

    Welcome to the forum!

    Yes, you can certainly create your experiment by using OpenSesame.

    If I understand correctly, your trial sequence is as follows:

    • Firstly, a still frame is presented containing a number of stimuli. Which of the stimuli are the targets is briefly indicated by them having a different color (for example).
    • Next, the stimuli (which look identical now) move across the screen randomly and participants have to keep track of the targets.
    • When the animation stops, participants have to indicate the targets by clicking on them.
    • Finally, at the end of every trial you will need to log all its relevant variables.

    For the display presentation (the first two steps), you will need some Python inline code. In order to achieve this, you simply append an inline_code item to your trial sequence and put the appropriate code (see below) in the 'Run phase' tab.

    To implement the third step (i.e. the response collection), there are two possibilities:

    • You could either append as many mouse_response items as there are targets to your trial sequence. (Because every mouse_response item collects only one click you will need several of these if there is more than one target.)
    • Alternatively, you could do the response collection in your inline script as well. Again, you will have to create a mouse object as many times as there are targets. This method is used in the example below.

    Finally, to log all your variables, simply append a logger item to your trial sequence.

    The following Python inline code should give you an idea of how to implement the first three steps. Of course, this is just an illustration and you will probably have to adapt the script to the specific properties of your experiment.

    [pastebin:2XefFAiR]

    For more information about display presentation with Python inline code, see:

    I hope this will get you started! Don't hesitate to ask any further questions!

    Best,

    Lotje

  • edited January 2013

    Dear Lotje,

    First of all, best wishes for the new year, and thanks for your quick reply!

    Due to the holidays and a brief vacation, I was unable to reply to your post any sooner, so my apologies for that =)

    I managed to implement the Python inline code you mentioned above, but I'm struggling with the fourth step (i.e. data logging). I added a logger to the trial sequence, but the log file only shows 0's or NA as output (see image below).

    My guess is that this has something to do with declaring the variables, since the xStim, yStim and xMouseClick, yMouseclick variables (which are all set with the exp.set command) don't show up in the log file. Am I doing something wrong or am I missing something really obvious here?

    Thanks!

    Thijs

    Logfile

  • edited 2:46AM

    Hi Thijs,

    A happy new year to you too!

    Glad to hear that the experiment is almost working.

    With regard to your log file, could it be that you placed the logger item somewhere else than at the end of your trial sequence? For example before rather than after the inline_script item, or somewhere 'higher up' in the experimental hierarchy? Typically, the overview of your experiment should look something like this:

    image

    I think it's highly unlikely that the problem is caused by the way the variables are set in the inline script. After setting a variable like so:

    exp.set("my_var", "some_value")

    'my_var' will be logged (provided that the "Automatically detect and log all variables" box in the logger item is ticked).

    If your logger item is placed correctly and the problem remains, could you perhaps provide us with some more information about your experiment? For example by giving a screenshot of your overview area or by uploading the experiment? Then I'm sure we can figure it out!

    For more information about logging variables, see also here:

    Best wishes,

    Lotje

  • edited January 2013

    Hi Lotje,

    Okay I feel somewhat stupid now... Instead of placing the logger at the end of the experiment, I placed it at the beginning! I remember trying to change the order of the items in the command line but I must have forgotten to press the apply button afterwards...

    Thanks again for the quick reply, if I have any problems in the future, I'll let you know!

    Thijs

  • edited January 2013

    Hi there!

    Using the Python inline code mentioned above as a basis, I managed to create a basic multiple object tracking experiment in OpenSesame.

    In addition to basic M.O.T. task variables such as speed, rotation and number of targets/distractors, I wish to implement another variable.

    The idea is that subjects have to move a box (including the moving targets and distractors) across all four corners of the screen, while keeping track of the targets inside the same box. Subjects control or initiate these movements preferably by clicking a corresponding corner of the screen.

    These self-initiated 'box-movements' have to be stored in some way and initiated autonomously during the second part of the experiment. This way, I will be able to compare both the effects on tracking accuracy of self-initiated changes in perspective and autonomously-initiated changes in perspective.

    The video below shows a (rough) idea of what I'm planning to build.

    http://www.youtube.com/embed/6IRp6U2CXG8

    I was wandering if this is possible to program in OpenSesame?

    Cheers & thanks!

    Thijs

  • edited 2:46AM

    Hi Thijs,

    That should be possible, but perhaps you could specify in a bit more detail what you want to do.

    The idea is that subjects have to move a box (including the moving targets and distractors) across all four corners of the screen, while keeping track of the targets inside the same box. Subjects control or initiate these movements preferably by clicking a corresponding corner of the screen.

    Do you want the participant to see a mouse cursor, and when they click on some part of the screen, the box with the moving stimuli moves smoothly to that location? Or should the box jump in one go? Or should the box be tied to the mouse position, so that it moves along whenever you make move the mouse cursor (no click needed, and no cursor visible)? (Personally, I like the last option best, but it depends on your question of course.)

    Cheers!
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited February 2013

    Hi Sebastiaan,

    Thanks for your quick reply! Preferably, the box should be moving smoothly in a straight path towards one of the four edges of the screen whenever the subject clicks on a corresponding edge (i.e. top, left, bottom, right).

    The reason why I wish to restrict this movement, is to ensure the experiment is more or less standardized. If the box-movement is directly linked to any movement of the cursor, it can be quite difficult to compare inter-individual test results, since the actual amount of self-initiated box-movement might vary from subject to subject. Therefore, the subjects are all given the same instructions in which they are asked to initiate a series of specific box-movements.

    Below is the code I have so far (once again, thanks to Lotje for helping me out here!).

    http://pastebin.com/embed_iframe.php?i=g7XGBLG5

    I used two reference variables (i.e. xref and yref) to create a 'virtual' box surrounding the stimuli. The canvas size is set to 1024x768 pixels and the stimuli are drawn in a box of 480 by 360 pixels. By setting xref=272 and yref=204, I managed to align the box to the center of the canvas. In order to initiate a box movement, these two variables should be mouse-cursor-dependent, but unfortunately I'm not quite sure how to implement this. In addition, I would like to change the color of the box (or draw some sort of bounding box surrounding the stimuli), to see if subjects perform better on a more scene based tracking task.

    Cheers & thanks!

    Thijs

  • edited 2:46AM

    Hi Thijs,

    This is starting to become a fairly complex script! But it should work. Essentially, the script either plays back a previously remember trajectory, or records the current trajectory. It assumes that there is a variable called replay, which is either 0 or 1 and indicates whether a specific trial is a replay or a record trial. To move the window, you click on a screen edge.

    Of course, there quite a lot of things you may to change in this script, such as where the participants need to click to trigger a movement, etc. If you read carefully through the code and the comments, and play around with it for a bit, you will probably come a long way.

    Also, at the start of your experiment (so just once, not at the start of every trial), you should declare a global empty list to store all the trajectories in:

    global trajectories trajectories = []

    Good luck!

    Cheers!
    Sebastiaan

    [pastebin:maNZvNE6]

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited February 2013

    Hi Sebastiaan,

    Once again, thanks for the quick reply, I really appreciate all the time and effort you're putting into answering my questions!

    I am eager to run the new script you posted above, but unfortunately I keep getting a tuple error message in line 7 (see image below). Could it be that this has something to do with me using the Mac OS version of OpenSesame? Or are there any comma's or indents missing in the code?

    Cheers & thanks,
    Thijs

    image

  • edited 2:46AM

    Ah right, it's this line:

    w, h = exp.resolution()

    resolution used to be a variable (a tuple to be exact), but since 0.27 it's a method.

    Perhaps it's best to specify a resolution directly, to avoid trouble when switching between 0.26 and 0.27.

    w, h = 1024, 768 # This should match the resolution specified in the experiment!

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • I just want to add that if you don't want your code to be specific to only one screen resolution, you could also use the built-in variables exp.width and exp.height, like so:

    w, h = exp.width, exp.height
  • edited February 2013

    Hi there!

    It took some effort and a lot of very frustrating error messages, but I finally managed to implement your code! I think the majority of error messages (mostly missing or even 'invisible' indents, or strange syntax errors such as 'import random' that is somehow read as 'mport random') are caused by the mac osx version of opensesame, since I experienced less error messages on a windows pc.

    I've added a couple of empty global lists and used loop elements to create different sequences of just movement or just replay, or a combination of those two. The result can be viewed here. The experiment is still in 'beta', since I will probably make some alterations in speed, diameter etc. I will also try to fine-tune the output a bit, since the response and target stimuli have to be linked manually (which takes a lot of time).

    Once again, thanks a lot for helping me out here, I honestly couldn't have done it without your help!

    Cheers
    Thijs

  • edited February 2013

    Hi there!

    As I mentioned in my previous post, I'm currently trying to fine-tune the output of my experiment in order to make the data a little less 'labor intensive' to process. Unfortunately, I keep getting a lot of error messages similar to those I mentioned above so I'm not able to save nor run my new script. Tomorrow I'll give it another try on a windows pc to see if the problem still persists.

    What I'm trying to do here is not only to set a fixed number of targets, but also a fixed set of targets. Since the script now randomly picks 2 targets amongst all stimuli, the identity of the targets changes: sometimes stim1 and stim4 are labeled as targets, while in another run stim3 and stim2 are labeled as targets.

    Preferably, stim1 and stim2 should always be labeled as targets. This way, I can limit the logger file to 8 output variables (xmouseclick1, xstim1, ymouseclick1, ystim1, xmouseclick2, xstim2 etc.) which makes it much easier to determine whether the targets are tracked correctly or not.

    My Idea was to set a rule with the exp.set command which separates targets from distractors:

    image

    Should this fail, my plan B was to create a second list of stimuli (i.e. the targets), which are moving simultaneously with the stimuli from the original set of stimuli (i.e. the distractors).

    Is any of these approaches going to work or is there perhaps a much easier way to achieve the same result?

    Cheers & thanks!
    Thijs

  • edited 2:46AM

    Unfortunately, I keep getting a lot of error messages similar to those I mentioned above so I'm not able to save nor run my new script. Tomorrow I'll give it another try on a windows pc to see if the problem still persists.

    That's probably a good idea, yes.

    Preferably, stim1 and stim2 should always be labeled as targets. This way, I can limit the logger file to 8 output variables (xmouseclick1, xstim1, ymouseclick1, ystim1, xmouseclick2, xstim2 etc.) which makes it much easier to determine whether the targets are tracked correctly or not.

    Perhaps I misunderstand, but that's already the case! The relevant bit of the script is this:

    # Highlight the targets on the first frame
    if i < NTarget and j == 0:
        color = targetColor
    else:
        color = normalColor       
    

    So the first NTarget stimuli are targets. You could therefore restrict logging to the first Ntarget stimuli. I would generally recommend logging everything though, because you never know what you might be interested in later.

    Cheers!

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited February 2013

    Hi Sebastiaan,

    As always, thanks for the quick reply! I guess I must have mismatched the targets and mouse clicks in the output because I repeated the script several times with very small targets (making them easier to track and separate) and in fact, you are right: Stim1 and Stim2 are indeed always the targets (which of course makes perfect sense since for both targets i < NTarget is the case)

    However, it is stilll very hard to determine from the output if a target is correctly tracked or not. I ran several test trials and there seems to be a rather strange and inconsistent flaw in the output (which probably caused my earlier mismatches).

    The image below shows the output of a series of trials (which can be viewed here) in which the subject tracks 2, 1, none and 2 targets correctly. After dividing the coordinates from the stimuli by 10^6 (I'm not sure why this is necessary, but I guess this has something to do with the variable "stimProperties" being stored in "micropixels" rather than pixels.. this will probably sound stupid to you but then again, I'm still an opensesame newby so... xD) one would conclude that during the 2nd trial, none of the targets were tracked successfully, since the y-coordinates recorded from both mouse-clicks don't match with those from any of the two targets. The subject did however track one target correctly (i.e. stim1), as can be seen in the screencast.

    The same goes for the 3rd trial, except here the subject 'successfully' tracks two distractors, whereas only 1 distractor can be verified based on the data.

    image

    edit: I ran a couple more trials and managed to reproduce the error in the output of both x and y coordinates of the stimuli

    Do you have any idea what the cause of this problem can be?

    Cheers & thanks
    Thijs

  • edited February 2013

    Hi Thijs,

    I'm fairly sure that the stimulus positions and mouse clicks are stored accurately. I'm not sure what went wrong here. The fact that you have divided the coordinates by 1 million is worrying, because that is certainly not necessary! The coordinates are simply in displays pixels.

    What comes to mind is that the columns got mixed up during the analysis. Could that be it? Also, as a debugging tool you can insert a feedback item to the end of the trial sequence and use this to show some variables, such as [xMouseClick1], [xStim1], etc. That might help you figure out exactly what goes wrong here.

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited February 2013

    Hi Sebastiaan,

    According to the feedback item, there should be nothing wrong with the output at all. After importing the .csv file in excel however, the 'punctuation' of the data somehow gets messed up; 10.7645 for instance, is displayed as 107.645. The .csv file looks fine though when viewed in a web browser or mac osx' quick look option, so it's definitely not an opensesame problem. Of course I should have checked this first before writing my previous post, sorry about that =)

    Cheers, Thijs

  • edited February 2013

    Okay, so finally I've got my experiment up and running and approved by my professor, only a few small details are still missing...

    I'm currently working on the first three sequences, which will function as test-trials. After the third test trial, the subject has to confirm he or she understood the instructions by clicking on either a confirmation button, or a 'disagree' button which restarts the test-trial sequence. The button widget from the forms plugin should do the trick, but I can't find a way to install it on my mac (which is running .26). Is this plug-in perhaps a build-in feature of .27? (In that case, I'm going to wake my old windows machine after four years of 'hibernation', since os and mac aren't the best friends yet xD )

    I was also wandering if I could implement some sort of 'warning message', giving the subject another try should he or she mistakenly click on an empty area of the canvas. I tried this by implementing the following inline code right after the part of the response collection section were the cursor position is made relative to the window:

    # Collect the response 
    responseID = 0 
    for i in range(NTarget): 
    responseID +=1 
    print responseID 
    button, position, timestamp = my_mouse.get_click()
    
    # Make the cursor position relative to the window 
    position = position[0] - winPos[0], position[1] - winPos[1] 
    if position = stimProperties[0], stimProperties[1]: 
        exp.set("xMouseClick"+str(responseID), position[0]) 
        exp.set("yMouseClick"+str(responseID), position[1]) 
    else: 
        draw textline -200 -200 "The selected area is empty, please select a target" center=0 color=white font_family=mono font_size=18 show_if="always"
    

    Unfortunately, I keep getting a syntax error. I'm also thinking about a way to give feedback to the subjects about the number of correctly tracked objects (I'm not sure if this is necessary for all trials, perhaps only during the first three trials). Is it possible to somehow 'reveal' the targets after each trial, and presenting a score (ranging from 0 to NTargets) at the same time?

    Cheers & thanks!

    Thijs

  • edited 2:46AM

    The button widget from the forms plugin should do the trick, but I can't find a way to install it on my mac (which is running .26). Is this plug-in perhaps a build-in feature of .27?

    Yes indeed, the form plug-ins require at least OpenSesame 0.27.

    Unfortunately, I keep getting a syntax error.

    The problem here is that you're mixing OpenSesame script with Python script. This line ...

    draw textline -200 -200 "The selected area is empty, please select a target" center=0 color=white font_family=mono font_size=18 show_if="always"

    ... is how the elements of a sketchpad item are defined. This is not a real programming language, but a simple definitional syntax called OpenSesame script. In contrast, the inline_script item requires that you use Python, which is a real programming language and a different beast altogether. For an explanation of OpenSesame script (and the difference with Python), see:

    There are some other things that will not work, such as the use of = instead of == to make a comparison, and the assumption that participants will click exactly on the stimulus center instead of checking whether the response falls within a certain area around the stimulus center.

    I don't want to sound negative: I think it's a very good idea to try to make this relatively small modification yourself. But you should familiarize yourself with the basics of Python first! For some good tutorials, see:

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited February 2013

    Hi Sebastiaan,

    Thanks for your reply! I took your advice and read some tutorials. Of course I should have done this first before putting my bets on the forum again (sorry about that) but I got somewhat frustrated about all the errors I got on my mac. Fortunately, I got my old windows machine up and running again and I haven't got any of the indent or syntax errors, so far so good!

    I managed to print some text on the canvas to instruct the subjects where to click during the trials to move the bounding box with the following inline code.

    
    if not replay:
        if j >= 200 and j <= 400:
            myCanvas.text('Click here',True,512,20)
        if j >= 600 and j <= 800:
            myCanvas.text('Click here',True,60,374)
        if j >= 1000 and j <= 1200:
            myCanvas.text('Click here',True,512,748)
        if j >= 1400 and j <= 1600:
            myCanvas.text('Click here',True, 960,374)   

    The next step was to implement the warning message. I tried this by setting up several comparisons:

    
    if position[0] - winPos[0] > stimProperties[0] + Clickmargin:
         myCanvas.text('The selected area is empty, please select a target',512,20)
    elif position[0] - winPos[0] < stimProperties[0] - Clickmargin:
         myCanvas.text('The selected area is empty, please select a target',512,20)
    elif position[1] - winPos[1] > stimProperties[1] + Clickmargin:
         myCanvas.text('The selected area is empty, please select a target',512,20)
    elif position [1] - winPos[1] < stimProperties[1] - Clickmargin:
         myCanvas.text('The selected area is empty, please select a target',512,20)

    Followed by an else statement stating:

    <code class="Python">
    else:
         exp.set("xMouseClick"+str(responseID), position[0])
         exp.set("yMouseClick"+str(responseID), position[1])</pre>
    
    <p>I tried to alter the Clickmargin from 5 (i.e. the radius of the stimuli) to 25, but none of these margins result in a warning message displayed on the canvas when a mouseclick is initiated on an empty area of the canvas.</p>
    
    <p>By changing the .text part into a variable writing 'empty' after every <code>if statement, I was able to see through a feedback item whether the script did anything at all. It seems that only the coordinates of every last mouse-click in sequence are recorded.
    
    edit:
    
    I just tried the following inline code but still no success :s
    
    
    
    Am I on the wrong track or am I missing something really obvious here?
    
    Cheers & Thanks
    Thijs
  • edited March 2013

    but none of these margins result in a warning message displayed on the canvas when a mouseclick is initiated on an empty area of the canvas.

    To actually show something on the display, you need to use the canvas.show() function. The other functions only draw to some 'offline' canvas, which is not shown until you explicitly call the canvas.show() function. For many examples, see:

    Also, you will need to implement a way for participants to get a second chance to click. If (after a mis-click) you only present a warning and skip the logging, that opportunity to respond will be lost. Other than that, your logic to do a fuzzy comparison of the coordinates is valid, although you can make things a bit easier for yourself to use a distance measure (see below), which doesn't require as many if statements.

    Below you see an example that implements more-or-less what you are trying to achieve: It will ignore all clicks that are not on a stimulus. You can improve and extend this script in many ways (for example by adding warning screens), but it should get you started.

    Good luck!
    Sebastiaan

    # First part of the script not shown
    
    # Collect response
    responseID = 0
    for i in range(NTarget):
        responseID +=1
        print responseID
    
        # Go into a loop that will be broken when the participants
        # clicks on a stimulus
        while True:
            # Collect the response
            button, position, timestamp = my_mouse.get_click()
    
            # Make the cursor position relative to the window
            position = position[0] - winPos[0], position[1] - winPos[1]
    
            # The maximum click error
            clickMargin = 20
    
            # We use Pythagoras to determine the distance from
            # the clicked location to the center of stimulus 1 (d1)
            # and stimulus 2 (d2)
            from math import sqrt
            d1 = sqrt((position[0]-stimList[0][0])**2 + (position[1]-stimList[0][1])**2)
            d2 = sqrt((position[0]-stimList[1][0])**2 + (position[1]-stimList[1][1])**2)
    
            # Some debugging output
            print d1, d2
            print 
            # If the error is small enough, we accept this click
            # by breaking from this loop
            if d1 < clickMargin or d2 < clickMargin:
                break
    
        # Set the x and y coordinates of the response so that they will
        # be logged by the  logger item. Position is an (x,y) tuple in
        # screen coordinates
        exp.set("xMouseClick"+str(responseID), position[0])
        exp.set("yMouseClick"+str(responseID), position[1])
    

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited March 2013

    Hi Sebastiaan,

    Thanks for your reply! Your code seems a bit more logical and much cleaner. When I implement your code however, the script doesn't seem to get past the my_mouse.get_click() line, which means
    d1 &lt; ClickMargin or d2 &lt; ClickMargin is never true?

    With the following else statement:

    
    else: 
       mycanvas = canvas(exp)
       mycanvas.text('The selected area is empty, pleas click on a stimulus',True,512,20)
       mycanvas.show() 

    I tried to check whether the opposite condition (i.e. d1 > ClickMargin or d2 > ClickMargin) did occur, but it can't seem to get any response after the get.click() line?

    I understand the 'while True' statement continues to 'loop' through the response collection code until one of the stimuli is clicked and until NTarget clicks are recorded. The debugger however, doesn't show any signs of response collection.

    Am I missing some additional code perhaps?

    Cheers,
    Thijs

  • edited 2:46AM

    Hi Thijs,

    The easiest way to debug your script is by using the print statement, which prints stuff to the debug window. That way you can print out all the variables in various stages of the script, and see where things go wrong. For example, you can print out the 'raw' mouse coordinates, the mouse coordinates relative to the window, the coordinates of the stimuli, the distance, etc. By inspecting all this information you will probably be able to tell where the problem lies.

    print 'position is %s' % position
    print 'd1 is %s' % d1
    # etc.
    

    I understand the 'while True' statement continues to 'loop' through the response collection code until one of the stimuli is clicked and until NTarget clicks are recorded.

    There are two loops here. The first is a for loop, which collects NTarget responses. The second is a while loop, which continues to collect responses for a single target until a click is close enough to a stimulus.

    Am I missing some additional code perhaps?

    Nope. I tested this script and it should work.

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited March 2013

    Hi Sebastiaan,

    Once again, thanks for the quick reply. The support I'm getting through this forum (even during the weekends!) is absolutely amazing!

    After reading your reply I decided to copy your code by literally typing it over in the inline script, instead of copy-pasting it from notepad. And guess what?! Now everything is working just fine!

    I've added another six distance equations so now the script successfully works with a total of 8 stimuli, displaying a warning message whenever an empty area of the canvas is clicked. Since I couldn't find a command other than canvas.clear() to erase the message (and the whole canvas), I simply let the script draw a black rectangle over the warning message after a stimulus is clicked, which does the trick as well =)

    With the exp.set command I've added two variables (i.e. Target1 and Target2) to determine whether both targets are tracked correctly. Since d1 &lt; Clickerrormargin is true when Target1 is clicked, I've added a line right before the break which sets the variable Target1 to 1. (The same goes for d2 and Target2, Target 1 and 2 are set to 0 at the start of each trial) This actually makes it a lot easier to process the data afterwards.

    As for now, all there is left is some fine-tuning of the stimulus variables (velocity, radius, shape etc..) but the script basically contains all the functionality I need for my experiment so I won't be expecting any big challenges in that. Should I however come across any additional problems (which can't be solved by reading the os or python tutorials) I'll let you know!

    Cheers and thanks!

    Thijs

  • edited 2:46AM

    After reading your reply I decided to copy your code by literally typing it over in the inline script, instead of copy-pasting it from notepad. And guess what?! Now everything is working just fine!

    Indentation trouble, probably. Python uses indentation to deduce the structure of the code, and this can easily get mixed up when copy-pasting.

    As for now, all there is left is some fine-tuning of the stimulus variables (velocity, radius, shape etc..) but the script basically contains all the functionality I need for my experiment so I won't be expecting any big challenges in that.

    :-bd

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited March 2013

    Okay, so I've made some small final adjustments to the script. I replaced the "click here" textline with a red rectangle and I've added some code to highlight the targets when clicked, which was all pretty straight-forward to implement.

    I also added some code to move the window with a key-press (e.g. press "up" to move the window up and "down" to move the window down) This all works fine on OS Windows, but I can't seem to get it working on my Mac (which isn't to big of a problem though, since the pc that will be running the experiment runs on Windows)

    I don't get any syntax or indent errors, It just refuses to respond correctly to any key-press. I've tested to see if any key-press was collected with the print response cmd, and it seems that "up" is registered as "213" and "down" as "214". So I thought simply adding an or "213" statement would do the trick, but unfortunately not.

    Do you have any ideas on what the problem might be?

    Cheers & Thanks!

    I used the following inline code:

    
    my_keyboard = keyboard(exp, timeout=1)
    response, timestamp = my_keyboard.get_key()
    if response == 'up':
        targetPos = w/2, winSize[1]/2
    if response == 'down':
        targetPos = w/2, h-winSize[1]/2 
  • edited 2:46AM

    Hi Thijs,

    In OpenSesame 0.26 and before, get_key() returned key-codes, rather than names or characters, and you had to do an extra conversion:

    response = my_keyboard.to_chr(response)
    

    This was kind of awkward, so nowadays get_key() returns a key name/ character right away, as you would expect.

    But more importantly, mind your Python logic! This ...

    if response == 'down' or "213":
    

    ... does not mean whether response is down or response is "213" (with quotes, so it's a string and not an int), but whether response == 'down' evaluates to True and (separately), whether "213" evaluates to True. What you actually mean is:

    if response == 'down' or response == 213:
    

    Cheers!
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • edited 2:46AM

    Okay that was a pretty obvious one.. Just when I thought I understood the basics of python, I made another 'rookie' mistake L-)

    Thanks for your reply!

    Cheers!
    Thijs

Sign In or Register to comment.