identify channel breaks ft_databrowser on apple silicon (m3)

[EceKayaMPI]

The bug
I simply try to identify a noisy channel in the databrowser, right after loading the data.

`cfg = [];
cfg.dataset = 'subj_1.eeg';
cfg.continuous = 'yes';
data = ft_preprocessing(cfg);

cfg = [];
ft_databrowser(cfg,data)`

I can see the data, and all functions of the databrowser seem to work, except when I use the 'identify channel' in I get the following error, and databrowser stops working:

click in the figure to identify the name of the closest channel
identified channel name: PO10
Error using ft_getopt
multiple input arguments with the same name

Error in ft_plot_text (line 67)
fontsize = ft_getopt(varargin, 'fontsize', get(0, 'defaulttextfontsize'));

Error in ft_databrowser>keypress_cb (line 1678)
ft_plot_text(xpos, ypos, label, 'FontSize', cfg.fontsize, 'FontUnits', cfg.fontunits, 'tag', 'identifiedchannel', 'FontSize', cfg.fontsize, 'FontUnits', cfg.fontunits);

Error while evaluating Figure KeyPressFcn.

Importantly, I don't get this error on my older MacBook (intel processor) with same fieldtrip version.

Environment and versions:

• Operating System: macOS 14.4.1, apple silicon M3
• MATLAB version R2023b (for apple silicon)
• FieldTrip version 20240417

[robertoostenveld]

what happens if you directly type

get(0, 'defaulttextfontsize')

in your MATLAB command window?

I would expect a number to be returned... on my computer it returns 10.

[EceKayaMPI]

Hi, thanks for the fast response.

When I directly type that, I get 10 too.

I went into the ft_getopt, changed lines 84 to 94 to:

hit = find(strcmpi(key, keys)); if isempty(hit) % the requested key was not found val = default; elseif length(hit)==1 % the requested key was found val = vals{hit}; else % error('multiple input arguments with the same name'); val = default; end

for my current purposes and use, it seems to have solved the problem.

I think the problem stems from this (ft_getopt function): for font related settings hit captures two arguments with same name (see screenshot). This doesn't happen while only showing the data in databrowser, since I assume that it gets default settings, since hit returns as empty in these cases.

Best,
Ece

[schoffelen]

uhm, but doesn't this mean that the ft_getopt function is generically not robust when there are key-value pairs like this: {'bla1', somevalue, 'bla2', someothervalue}

and that this is the case for the *.m version of the file, and not for the compiled ones (and since there's not yet a mexmaca64 version you noticed it...?

[robertoostenveld]

@EceKayaMPI could you execute the https://github.com/fieldtrip/fieldtrip/blob/master/test/test_ft_getopt.m script and see whether that works for you? We have not tested extensively yet on apple silicon but it would be good to know whether our test script misses anything.

I do now have a Mac M3 and will install MATLAB asap to execute all tests.

[EceKayaMPI]

Yes, I modified the ft_getopt.m file, and the original version did have the issue while checking other properties like font units, etc.

@robertoostenveld I executed the test script and it ran without errors :)

[robertoostenveld]

Did it run without errors with the original version of ft_getopt, or only after you made the changes?

[robertoostenveld]

Ah, I now see that the error that was reported is actually due to

ft_plot_text(xpos, ypos, label, 'FontSize', cfg.fontsize, 'FontUnits', cfg.fontunits, 'tag', 'identifiedchannel', 'FontSize', cfg.fontsize, 'FontUnits', cfg.fontunits); 

having the FontSize and FontUnits options both twice. That is incorrect usage, so ft_getopt is actually right in throwing an error. The error should therefore first of all be solved in ft_databrowser. Subsequently we have to improve the test script.

Apparently the m-file version is stricter (and better) in checking the incorrect use than the mex-file version.

[robertoostenveld]

The issue is now only partially resolved, as we should improve the mex files implementation. Giving the same option twice is incorrect and unclear usage of ft_getopt.

When you do

ft_getopt({'key', 1, 'key', 1}, 'key');

you could expect it to return 1, but when you do

ft_getopt({'key', 1, 'key', 2}, 'key');

it is ambiguous. Hence passing the same key twice in the cell-array should not be allowed. With structure input arguments (like cfg) this problem cannot apply.

[EceKayaMPI]

Did it run without errors with the original version of ft_getopt, or only after you made the changes?

the https://github.com/fieldtrip/fieldtrip/blob/master/test/test_ft_getopt.m script ran without problems, using the unmodified getopt function