specify prefered "markers" to be imported from eyelink .asc data

[SerenXia]

Feature Description

I am using PsPM 6.1.1 to import eyelink 1000 plus data. We have both "INPUT" sent via BITSI and "MSG" of different texts sent via IP LINK to the eyelink system.

In the current import_eyelink.m function in PsPM (it is in the "Import" - "eyelink" folder), MSG indices are parsed and filtered out based on predefined and nonconfigurable strings.

Can we have a new feature for defining preferred marker texts or not only looking for "MSG" but look for "INPUT", by providing "options.markers" input argument (or something similar) in future versions of PsPM?

For now, to make sure I have preferred markers for my current data, I just modified it as shown below (in Bold) in my local PsPM. But a more general implementation is needed if we want to have this feature.

import_eyelink.m line 266-275: sblink_indices = find(strncmp(messages, 'SBLINK', numel('SBLINK'))); eblink_indices = find(strncmp(messages, 'EBLINK', numel('EBLINK'))); ssacc_indices = find(strncmp(messages, 'SSACC', numel('SSACC'))); esacc_indices = find(strncmp(messages, 'ESACC', numel('ESACC'))); msg_indices = strncmp(messages, 'MSG', numel('MSG')); for name = {'RECCFG', 'ELCLCFG', 'GAZECOORDS', 'THRESHOLDS', 'ELCL', 'PUPIL_DATA_TYPE', '!MODE'} msg_indices = msg_indices & ~contains(messages, name); end msg_indices = msg_indices & (contains(messages, 'trial onset') | contains(messages, '_onset')); msg_indices = find(msg_indices);

Additionally, if the eyelink datafile contains several TRIALS (defined by eyelink, not the experimental trial design), PsPM would add two 0s in a line, as a sign of new TRIAL onset, in the markerinfo.name and markerinfo.value, but not in the marker data, resulting in inconsistency of the length of marker data and markerinfo.name/value.

Thank you in advance for considering this!

[teddychao]

@dominikbach May we have some comments from you and then assign it to me or someone else to fix this? Thank you.

[dominikbach]

1. I think it would be helpful to simply import all occurrences of "msg" or "input" in a marker channel. The user can then later parse this from the marker values.
2. The second issue in the last paragraph seems to be a bug.