% overlap actually defines % step in mtmconvol

[NirOfir]

Not too important, but someone from our lab noticed that cfg.overlap, when used with "%..." does the opposite of what it's supposed to do. Instead of defining the overlap of consecutive windows in percent, it defines the step size of the windows in percent. This can be seen in the code at the beginning of ft_freqanalysis:

fieldtrip/ft_freqanalysis.m

Lines 305 to 307 in 87990ee

	overlap = str2double(cfg.toi(1:(end-1)))/100;
	cfg.toi = linspace(begtim, endtim, round((endtim-begtim) ./ ...
	(overlap * min(cfg.t_ftimwin))) + 1);

As overlap grows, the number of elements requested from linspace decreases instead of increases.

Test based on those lines of code:

cfg.t_ftimwin = 1;
begtim        = 0;
endtim        = 10;
overlap       = 0.1:0.1:0.9;
step = zeros(length(overlap), 1);
for i = 1:length(overlap)
  toi = linspace(begtim, endtim, round((endtim-begtim) ./ (overlap(i) * min(cfg.t_ftimwin))) + 1);
  step(i) = mean(diff(toi));
end

The result is that step is equal to overlap:

step =

    0.1000    0.2000    0.3030    0.4000    0.5000    0.5882    0.7143    0.7692    0.9091

A solution could be to add the following line after line 305 in ft_freqanalysis, to invert overlap:
overlap = 1 - overlap;
Which fixes it.

cfg.t_ftimwin = 1;
begtim        = 0;
endtim        = 10;
overlap       = 0.1:0.1:0.9;
step = zeros(1, length(overlap));
for i = 1:length(overlap)
  tmp_overlap = 1 - overlap(i); % invert overlap
  toi = linspace(begtim, endtim, round((endtim-begtim) ./ (tmp_overlap * min(cfg.t_ftimwin))) + 1);
  step(i) = mean(diff(toi));
end

The result is as expected, with step decreasing as overlap increases:

step =

    0.9091    0.7692    0.7143    0.5882    0.5000    0.4000    0.3030    0.2000    0.1000