Millisecond Forums

Any way to set /errormessage attribute dynamically?

https://forums.millisecond.com/Topic31561.aspx

By AKrishna - 5/19/2021

Hi all,

I've encountered a situation where I'm not sure whether the planned experiment will use error feedback or not (my collab partners haven't decided yet), so I thought I would program flexibly to allow either. Unfortunately, it looks as though trials don't have an errormessage property that can be reassigned. I've tried setting the errormessage duration as a value and then setting that value to zero via script to switch the errormessage off, but it is still displayed briefly. Is there any way to control whether an errormessage is displayed on the fly based on a <value> or <parameter> content? I'm aware that the same functionality could be implemented using /branch to call up a dedicated error trial, but I would prefer to avoid that if possible (I'm already using complex branches and variable stimulus displays on screen with /erase, so it would be a bit of a headache to implement).

Appreciate any input!


By Dave - 5/19/2021

AKrishna - 5/19/2021
Hi all,

I've encountered a situation where I'm not sure whether the planned experiment will use error feedback or not (my collab partners haven't decided yet), so I thought I would program flexibly to allow either. Unfortunately, it looks as though trials don't have an errormessage property that can be reassigned. I've tried setting the errormessage duration as a value and then setting that value to zero via script to switch the errormessage off, but it is still displayed briefly. Is there any way to control whether an errormessage is displayed on the fly based on a <value> or <parameter> content? I'm aware that the same functionality could be implemented using /branch to call up a dedicated error trial, but I would prefer to avoid that if possible (I'm already using complex branches and variable stimulus displays on screen with /erase, so it would be a bit of a headache to implement).

Appreciate any input!



It's a bit hack-ish, but you can do something like this:

<parameters>
/ showerror = true
</parameters>

<expressions>
/ e_stim = if (parameters.showerror){
    text.redX;
} else {
    clearscreen;
};
/ e_dur = if (parameters.showerror){
    500;
} else {
    0;
};
</expressions>

<block myblock>
/ trials = [1-5 = mytrial]
</block>

<trial mytrial>
/ pretrialpause = 1000
/ stimulusframes = [1=mytext]
/ validresponse = (57, 0)
/ correctresponse = (57)
/ timeout = 3000
/ errormessage = true(expressions.e_stim, expressions.e_dur)
</trial>

<text mytext>
/ items = ("Press SPACE or do nothing")
</text>

<text redX>
/ items = ("X")
/ txcolor = red
/ position = (50%, 80%)
</text>
By AKrishna - 5/19/2021

Dave - 5/19/2021
AKrishna - 5/19/2021
Hi all,

I've encountered a situation where I'm not sure whether the planned experiment will use error feedback or not (my collab partners haven't decided yet), so I thought I would program flexibly to allow either. Unfortunately, it looks as though trials don't have an errormessage property that can be reassigned. I've tried setting the errormessage duration as a value and then setting that value to zero via script to switch the errormessage off, but it is still displayed briefly. Is there any way to control whether an errormessage is displayed on the fly based on a <value> or <parameter> content? I'm aware that the same functionality could be implemented using /branch to call up a dedicated error trial, but I would prefer to avoid that if possible (I'm already using complex branches and variable stimulus displays on screen with /erase, so it would be a bit of a headache to implement).

Appreciate any input!



It's a bit hack-ish, but you can do something like this:

<parameters>
/ showerror = true
</parameters>

<expressions>
/ e_stim = if (parameters.showerror){
    text.redX;
} else {
    clearscreen;
};
/ e_dur = if (parameters.showerror){
    500;
} else {
    0;
};
</expressions>

<block myblock>
/ trials = [1-5 = mytrial]
</block>

<trial mytrial>
/ pretrialpause = 1000
/ stimulusframes = [1=mytext]
/ validresponse = (57, 0)
/ correctresponse = (57)
/ timeout = 3000
/ errormessage = true(expressions.e_stim, expressions.e_dur)
</trial>

<text mytext>
/ items = ("Press SPACE or do nothing")
</text>

<text redX>
/ items = ("X")
/ txcolor = red
/ position = (50%, 80%)
</text>

Cheers! I was thinking something similar, but I'm not sure whether the fact that errormessages are still displayed at duration = 0 might add on an extra frame of duration even if the errormessage is transparent. Any idea whether that is the case?
By Dave - 5/19/2021

AKrishna - 5/19/2021
Dave - 5/19/2021
AKrishna - 5/19/2021
Hi all,

I've encountered a situation where I'm not sure whether the planned experiment will use error feedback or not (my collab partners haven't decided yet), so I thought I would program flexibly to allow either. Unfortunately, it looks as though trials don't have an errormessage property that can be reassigned. I've tried setting the errormessage duration as a value and then setting that value to zero via script to switch the errormessage off, but it is still displayed briefly. Is there any way to control whether an errormessage is displayed on the fly based on a <value> or <parameter> content? I'm aware that the same functionality could be implemented using /branch to call up a dedicated error trial, but I would prefer to avoid that if possible (I'm already using complex branches and variable stimulus displays on screen with /erase, so it would be a bit of a headache to implement).

Appreciate any input!



It's a bit hack-ish, but you can do something like this:

<parameters>
/ showerror = true
</parameters>

<expressions>
/ e_stim = if (parameters.showerror){
    text.redX;
} else {
    clearscreen;
};
/ e_dur = if (parameters.showerror){
    500;
} else {
    0;
};
</expressions>

<block myblock>
/ trials = [1-5 = mytrial]
</block>

<trial mytrial>
/ pretrialpause = 1000
/ stimulusframes = [1=mytext]
/ validresponse = (57, 0)
/ correctresponse = (57)
/ timeout = 3000
/ errormessage = true(expressions.e_stim, expressions.e_dur)
</trial>

<text mytext>
/ items = ("Press SPACE or do nothing")
</text>

<text redX>
/ items = ("X")
/ txcolor = red
/ position = (50%, 80%)
</text>

Cheers! I was thinking something similar, but I'm not sure whether the fact that errormessages are still displayed at duration = 0 might add on an extra frame of duration even if the errormessage is transparent. Any idea whether that is the case?

Theoretically the clearscreen at duration 0 takes up a frame, but whether that in effect *adds* a frame to your trials would depend on how exactly your trials are set up. I.e. is there a posttrialpause or not, are the stimuli presented by the trial set to erase or not, etc.
By Dave - 5/19/2021

Dave - 5/19/2021
AKrishna - 5/19/2021
Dave - 5/19/2021
AKrishna - 5/19/2021
Hi all,

I've encountered a situation where I'm not sure whether the planned experiment will use error feedback or not (my collab partners haven't decided yet), so I thought I would program flexibly to allow either. Unfortunately, it looks as though trials don't have an errormessage property that can be reassigned. I've tried setting the errormessage duration as a value and then setting that value to zero via script to switch the errormessage off, but it is still displayed briefly. Is there any way to control whether an errormessage is displayed on the fly based on a <value> or <parameter> content? I'm aware that the same functionality could be implemented using /branch to call up a dedicated error trial, but I would prefer to avoid that if possible (I'm already using complex branches and variable stimulus displays on screen with /erase, so it would be a bit of a headache to implement).

Appreciate any input!



It's a bit hack-ish, but you can do something like this:

<parameters>
/ showerror = true
</parameters>

<expressions>
/ e_stim = if (parameters.showerror){
    text.redX;
} else {
    clearscreen;
};
/ e_dur = if (parameters.showerror){
    500;
} else {
    0;
};
</expressions>

<block myblock>
/ trials = [1-5 = mytrial]
</block>

<trial mytrial>
/ pretrialpause = 1000
/ stimulusframes = [1=mytext]
/ validresponse = (57, 0)
/ correctresponse = (57)
/ timeout = 3000
/ errormessage = true(expressions.e_stim, expressions.e_dur)
</trial>

<text mytext>
/ items = ("Press SPACE or do nothing")
</text>

<text redX>
/ items = ("X")
/ txcolor = red
/ position = (50%, 80%)
</text>

Cheers! I was thinking something similar, but I'm not sure whether the fact that errormessages are still displayed at duration = 0 might add on an extra frame of duration even if the errormessage is transparent. Any idea whether that is the case?

Theoretically the clearscreen at duration 0 takes up a frame, but whether that in effect *adds* a frame to your trials would depend on how exactly your trials are set up. I.e. is there a posttrialpause or not, are the stimuli presented by the trial set to erase or not, etc.

Below is a variation on the same theme, using a slightly different method to suppress display of the error stimulus. On my system at least, there is no detectable timing difference between the parameterized version vs commenting out the /errormessage attribute entirely.

<data>
/ audit = true
</data>

<values>
/ e_dur = 500
</values>

<parameters>
/ showerror = false
</parameters>

<expressions>
/ e_set =     if (!parameters.showerror){
        text.redX.skip = true;
        text.redX.erase = false;
        values.e_dur = -1;
    } else {
        text.redX.skip = false;
        text.redX.erase = true;
        values.e_dur = 500;
    };
</expressions>

<block myblock>
/ onblockbegin = [
    expressions.e_set;
]
/ trials = [1-5 = mytrial]
</block>

<trial mytrial>
/ pretrialpause = 1000
/ stimulusframes = [1=mytext]
/ validresponse = (57, 0)
/ correctresponse = (57)
/ timeout = 3000
/ errormessage = true(text.redX, values.e_dur)
</trial>

<text mytext>
/ items = ("Press SPACE or do nothing")
</text>

<text redX>
/ items = ("X")
/ txcolor = red
/ position = (50%, 80%)
</text>

By AKrishna - 5/19/2021

Ah, thanks a lot! Interesting to note that the /erase setting plays an important role. I'll be able to work with this!