[Some questions from Ralf]
In the first example experiment you sent us, the variable stimulus_index is used for the decision which stimulus will be shown next (set by the “New Replicator”). In the windows “Variables” of the mWorks-Client the value of the var stay all the time at “0”… is that ok?
A second question is, if it possible to change stimulus parameter during/before/after a trial (set by the client/MatLab)?
Oh and a last one… which data are saved and how can i read them?
Hi Ralf,
In the first example experiment you sent us, the variable stimulus_index is used for the decision which stimulus will be shown next (set by the “New Replicator”). In the windows “Variables” of the mWorks-Client the value of the var stay all the time at “0”… is that ok?
Yes, that’s OK. The range replicator is expanded during experiment parsing. In this case, the parser generates three copies of the replicated body. In each copy, the string “stimulus_index” is replaced with a value (0, 1, or 2). Thus, the actual value of “stimulus_index” is irrelevant, whether it’s set in the experiment file or in the variables window.
To be honest, it’s not clear to me why you need to create a variable named “stimulus_index”. As far as I can tell, the parser treats it strictly as a symbolic placeholder; by the time the experiment has loaded, all references to it are replaced with concrete values. Maybe it simplifies the parser implementation to have an actual variable with that name?
In any case, an important point to remember is that a variable used in a range replicator must have local (rather than global) scope. You can set this with the “Scope” drop-down when inspecting the variable in the editor.
I’ll answer your next question in another reply.
Chris
A second question is, if it possible to change stimulus parameter during/before/after a trial (set by the client/MatLab)?
It depends on how you queue the stimulus. The standard “Queue Stimulus” action freezes the parameters of the queued stimulus to their current values. If you change a parameter after queuing the stimulus, the change won’t affect how the stimulus is displayed until you dequeue and re-queue it.
On the other hand, if you queue the stimulus via the “Live Queue Stimulus” action, then any parameter changes you make between when the stimulus is queued and when it’s actually displayed will affect its appearance. The experiment QueueLiveQueue.xml demonstrates the difference between regular and live queuing.
As for how you change the parameters, you can definitely do so with the client’s variables window. However, I don’t think it’s possible to change parameters at runtime via a MATLAB script, although I may be wrong.
Oh and a last one… which data are saved and how can i read them?
When you stream to a data file, MWorks writes to the file all events that occur while the stream is open. In MWorks, an “event” is a general-purpose container that is used to encapsulate all the different kinds of data generated by the system: messages, state transitions, stimulus announcements, variable value changes, etc.
Each event structure contains the event time, a code identifying the event, and a value. Most event codes have an associated tag name (e.g. “#announceCurrentState”) that provides a useful description of the event. Each variable defined in your experiment has its own code, and the associated tag name is the variable’s name.
To read the events from a data file, you can use either MATLAB or Python. I’ve attached example scripts in both languages that show how you can inspect a data file’s contents. Hopefully these will help you get started with writing your own MWorks data analysis scripts.
I know I’m barely scratching the surface here, and I’m sure you’ll have many more questions as you start to play with this stuff. Please don’t hesitate to ask!
Chris
Hi Ralf,
I discovered a bug that can lead to Python or MATLAB crashing when running my example scripts. The problem happens when reading the last event in a data file, so one workaround is to avoid reading that event, e.g. in Python:
for i, evt in enumerate(events[:-1]):
...
or in MATLAB:
for i = 1:length(events)-1
...
Alternatively, you can use the nightly build, which will contain the fix for this bug starting tonight.
Chris