Two quick questions

Hi Chris -

I’m continuing to adapt the example code you sent me (attached) and had a few questions:

(1) I dont see where in the protocol the parameter “num_accepted” is updated
(2) How do I adapt this code to show multiple repeats of the image set?

In looking over other example code provided with the install, I think you achieved point #2 above via the “when…” conditional in the final state of RSVPdemo.mwel :
state ‘RSVP complete’ {
report (‘********* RSVP Trial Completed *********’)
sync = 0
goto (
target = ‘RSVP start’
when = image_set_repeat_count < image_set_repetitions
)
yield ()

But I’m not sure how that "when…"would interfere with the current "when…"conditional in the final state of example1.mwel:

state 'End trial' {
        wait (inter_trial_interval)
        // If there are more images to show, start a new trial
        goto (
            target = 'Begin trial'
            when = num_accepted('image_index') < image_set_size
            )
        // Otherwise, exit the task
        yield ()

How do I correctly “loop” over two things? Image set size AND repetition set size?

Thank you!
Yasmine

Hi Yasmine,

(1) I dont see where in the protocol the parameter “num_accepted” is updated

num_accepted is a function, not a variable. If you pass it the name of a selection variable as a string ( 'image_index' in your example experiment), it returns the number of accepted selections made on the variable. The current value of image_index itself is controlled by the invocations of reset_selection, next_selection, accept_selections, and reject_selections throughout the protocol.

If you want more info on how MWorks’ selection mechanism works in general, there’s a section on it in the user manual.

(2) How do I adapt this code to show multiple repeats of the image set?

Your reading of RSVPDemo is correct. To implement the same logic in example1, you need to add states at the beginning and end of the task to handle the image set repetition. I’ve attached an updated MWEL file that includes this change.

Cheers,
Chris

Attachment: example1.mwel.zip (2.45 KB)

Great - thanks Chris! Will work through all of this very shortly!
Yasmine

Hi Chris -

Since implementing the “image set repetitions” functionality in the
example1.mwel, I’ve noticed two types of errors come up on the “Server
Console” - although neither of them interfere with the progress of the
experiment.

(1) ERROR: There are no more items left to draw [line 191: column 13]

In my code, this line is the beginning of the “Stim on” state. My
understanding is that the code should only jump back to the “Stim on” state
if there ARE stimuli left to draw at the end of a trial - so Im not quite
sure why this is happening. Any ideas how to troubleshoot?

(2) An error warning that we skipped a screen refresh

Sorry I don’t have the exact wording - but wondering why this is happening
and if we can do anything about it. It’s rare - but thought I’d point
it out.

Thanks!
Yasmine

Hi Yasmine,

(1) ERROR: There are no more items left to draw [line 191: column 13]

This happens when you invoke next_selection after all selections have been exhausted. In the updated example I sent you, the state “End trial” checks whether all selections are exhausted and, if so, ends the current image set repetition:

// If there are more images to show, start a new trial
goto (
    target = 'Begin trial'
    when = num_accepted('image_index') < image_set_size
    )
// Otherwise, end the current image set repetition
goto ('End image set repetition')

On the other end, the state “Begin image set repetition” invokes reset_selection to reset the selection variable for the next image set repetition:

reset_selection (image_index)

If your code includes both those pieces and you’re still seeing the error, you can send me your MWEL, and I’ll try to spot the problem.

(2) An error warning that we skipped a screen refresh

This means that, for some reason, MWorks wasn’t able to update the screen on a particular display refresh. Seeing this rarely isn’t cause for concern. There are many reasons why the system might experience an occasional performance “hiccup”, and I wouldn’t spend time trying to track down the (presumably transient) cause of these events.

However, if these warnings show up frequently, it means the graphics hardware is having trouble keeping up with MWorks’ needs. In that case, the problem might lie in MWorks. It also might be due to another application or process, or it could reflect an issue in the system’s graphics drivers. If you ever find yourself in this situation, let me know, and I can help you troubleshoot.

Cheers,
Chris

Hi Chris -

Following up on my email below about the error I’m getting in relation to
calling next_selection when there are no more stimuli to draw:

ERROR: There are no more items left to draw [line 191: column 13]

Any chance you spotted the error in my code?

Thank you!
Yasmine

Hi Yasmine,

Any chance you spotted the error in my code?

Sorry, I never received your code. Can you try sending it again?

FYI, attachments with the extension “.mwel” sometimes cause emails to be treated as spam and lost. To avoid this, I recommend either adding a “.txt” extension to or ZIP compressing MWEL files before attaching them to an email. Sorry for the hassle!

Thanks,
Chris

Ah! Good to know. Re-attaching here as .txt.

Please let me know if you can access this.

Thanks!
Yasmine

Attachment: example1_YES.txt (19.2 KB)

Hi Yasmine,

Thanks, I received it this time. There is an issue, but I think it’s in my original version, too. I’ll let you know once I’ve sorted it out.

Chris

Hi Yasmine,

My apologies. The “no more items left to draw” message was due to an error on my part in the original example experiment. To resolve the issue, you need to make two changes.

First, in the definition of image_index, add the parameter advance_on_accept with value YES:

selection image_index (
    values = 0 : image_set_size - 1
    selection = random_without_replacement
    advance_on_accept = YES  // This is the line to add
    )

Second, in the state “Stim on”, replace

next_selection (image_index)

with

if (images_shown > 0) {
    next_selection (image_index)
}

I’ve attached a copy of your experiment file that includes these changes. With this version, you should no longer see the error message.

As for why these changes are necessary: Selection variables are confusing (even to me), because sometimes they advance automatically to the next selection, and sometimes they don’t. Specifically:

  • reset_selections does not automatically make a next selection. Immediately after being reset, a selection variable is in the “no selection” state. To make an initial selection, you have to either (1) invoke next_selection explicitly or (2) just use the variable, as asking for the value of a selection variable in the “no selection” state causes a selection to be made automatically for you. Personally, while I think (1) is totally reasonable and expected, (2) is not so expected and a little unnerving. However, it doesn’t really matter in practice, because in both cases, you end up making one, initial selection.

  • By default, accept_selections also does not make a next selection. However, unlike reset_selections, accept_selections doesn’t cause the selection variable to enter the “no selection” state. Rather, it leaves the current, just-accepted selection in place. You can alter this behavior by setting advance_on_accept to YES, in which case accept_selections does make a next selection.

  • Finally, reject_selections always makes a next selection.

When writing the example for you, I forgot that reject_selections makes a next selection. This meant that, when a trial failed before the current image set repetition was complete, the selection variable was advanced twice when it should have been advanced only once: implicitly by reject_selections, and explicitly by the next_selection invocation in state “Stim on”. This resulted in the first of those two selections (i.e. images) never being used, and it caused the next trial to “consume” more than images_per_trial images, which in turn led to later trials running out, hence the “no more items left to draw” error. The changes I outlined above fix the problem by

  1. making both accept_selections and reject_selections automatically make a next selection and
  2. explicitly invoking next_selection only when not at the beginning of a trial.

If you think this all sounds ridiculous and highly conducive to errors, I agree! I didn’t implement selection variables, and if I could re-make them from scratch, they would never implicitly make a next selection. However, I can’t change their behavior now, because doing so would break the many, many experiments that are designed around and depend on the existing behavior. I suppose I could make a new, alternative selection variable that behaves in ways that I find sensible, but that might just muddy the waters further.

If you have any suggestions for how to improve this situation, please let me know! In the meantime, the changes I described should make the selection-variable bits of your experiment work correctly.

Cheers,
Chris

I’ve attached a copy of your experiment file that includes these changes.

For some reason, the attachment failed to upload. Trying again.

Attachment: example1_FIXED.txt (19.2 KB)

if I could re-make them from scratch, they would never implicitly make a next selection. However, I can’t change their behavior now, because doing so would break the many, many experiments that are designed around and depend on the existing behavior.

Now that I’ve vented my frustrations, it occurs to me that I could just add a new parameter that enables alternative, more predictable behaviors for selection variables. That would avoid breaking existing experiments, while allowing new ones to opt in to the new behaviors. That’s probably what I’ll do.

Chris

Hi Chris.,

Super - I received your detailed commentary on that next selection error
and will work through it today! And sounds good about a new parameter for
getting more predictable behaviors for selection variables!

Thank you,
Yasmine

Hi Chris -

I made the two changes you suggested:

CHANGE 1
selection image_index (
values = 0 : image_set_size - 1
selection = random_without_replacement
advance_on_accept = YES //Y: Added this line to
get rid of “ERROR: no more items left to draw”
)
CHANGE 2
state ‘Stim on’ {
if (images_shown > 0){ //Y: Added this line to
get rid of “ERROR: no more items left to draw”
next_selection (image_index)
}

Last night, I ran the code with mouse simulation in eyelink, without moving
the mouse – and didn’t see the error come up. But today, we ran an animal
and we did get the error. I suspected that this was due to breaking
fixation and the state called “Trial failure” which also contains a
“reject_selections (image_index)”. To confirm, I re-ran eyelink with mouse
simulation and then introduced some simulated broken fixations…and sure
enough, I got the error again.

I do think the error is less frequent than it was previously…but Im
wondering if we should edit the “Trial failure” state?

Thanks!
Yasmine

Hi Yasmine,

Yes, it was reject_selections in the “Trial failure” state that triggered the error. I thought my changes had fixed that, but it sounds like they haven’t.

Can you send me the exact experiment file you’re having problems with? Maybe there’s another issue I missed.

Thanks,
Chris

Hi Chris -

Attaching the most recent version of our code (and %include files) in a
compressed folder.

Thank you,
Yasmine

Attachment: YESCODE-forStawarz.zip (9.99 KB)