[open] Trial list, pre-loading and efficiency

Comments

• Edwin

  February 2013 edited 12:24PM

  Hi,

  This sounds like a delay discounting task! If that is the case: why not simply put the fixed parts of the text in a sketchpad and vary only the values? E.g.: "[nowvalue] euro now or [delayvalue] in [delaytime] days"

  I've created a DDT before and used this technique. I had five delays (all values in days), a fixed delayvalue and calculated the current value per trial (as a random number between two boundaries defined based on a user's behaviour), therefore there was no need to create extremely long lists. Could this be a solution in your case as well? If you are using this paradigm, I could upload some sample code.

  If not: why do you worry about the delay? At the trial's start, the trial is prepared. Therefore you should have a minimal delay per trial. Although typing 200 rows sounds like quite a big bother, though.

  Good luck!
• koenraad

  February 2013 edited February 2013

  That is exactly what I'm trying to do.
  Using variables to fill in the blanks is a very nice and neat way, thx!

  If you upload the bit's that would help get around any snag.

  But my question was due to a weird delay in the sketchpad, using "keypress" as the time. using the fire-button, space-bar or mouse1 often doesnt give a response, while in the demo it works like a charm

  Update: using the spacebar followed by the trigger seems to satisfy the sketchpad, so for now I'll leave it at that
• Edwin

  February 2013 edited 12:24PM

  Hi,

  You can find my delay discounting task here. There is a notepad item added (called readme) that tells you which article I've followed. The experiment should be the same as the one mentioned in the article.

  It may not be the prettiest bit of work and it certainly is not my best work, but it still works.

  Good luck!