Hi Simon,
How do I access the component codec so I can figure out where my state system is hanging?
The component codec has code 2 (as documented in System Event Codes). As you discovered, it also happens to be the first event in the event file. However, that’s not guaranteed to be true forever. The right way to get it is to select events with code equal to 2, e.g.
cc = f.get_events(codes=[2])[0].data
It would be nice a bit on how to access the component codec in the manual, I think, for those who come after me. It would be even nicer to have announce_state somewhere in plain text without having to unpack the mwk file, or even quick access to the component codec decoder in a window while an experiment is running.
The component codec and #announceCurrentState variable aren’t as useful as they might seem. When you read “state”, you probably think of task system states. While those are announced in #announceCurrentState
, so are all other paradigm components and, more significantly, all actions. A UI element that attempted to show the tag associated with the current state would mostly just be a blur, as MWorks changes “states” very, very often. Even when it was legible, it would often show junk like “idm34633081972176”, which is what the component codec gives you for components that aren’t named in the experiment (e.g. most actions).
What would be more helpful, I think, would be to introduce a new system variable that only announced task-system states. The client could use that variable, along with the component codec, to display the name of the state.
Is there any way to access the state of an alt device with a variable? For example, I would like a variable to be set to 999 when the eyelink fails to initialize, so that this will be recorded in our csv log file of the experiment, if someone ever starts the program and then does a trial with the mouse, I don’t want it to be mixed up with the real monkey data.
No. However, in the case of the EyeLink, you could set the initial value of the variable associated with e.g. pupil_lx
to some sentinel value like -999. If the EyeLink fails to initialize, that value should never change, so you could use its presence to detect simulated trials.
Cheers,
Chris