fix broken links, see #770

_includes/shared/tutorial/sourcelocalization_background.md

@@ -1,4 +1,4 @@
-The EEG/MEG signals measured on or around the scalp do not directly reflect the activated neurons in the brain. To reconstruct the actual activity in the brain, source reconstruction techniques are used. You can read more about the different methods in the review papers that are listed [here](references_to_review_papers_and_teaching_material/#source-estimation).
+The EEG/MEG signals measured on or around the scalp do not directly reflect the activated neurons in the brain. To reconstruct the actual activity in the brain, source reconstruction techniques are used. You can read more about the different methods in the review papers that are listed [here](/references_to_review_papers_and_teaching_material/#source-estimation).
 
 The activity in the brain is estimated from the EEG or MEG signals using
 

development/integration.md

@@ -28,7 +28,7 @@ We use <https://shields.io> to generate badges for the DOIs, PMIDs and PMCIDs.
 
 ## YouTube
 
-We use a YouTube [video channel](https://www.youtube.com/fieldtriptoolbox) that contains video recordings of lectures. More details are [here](/video) and [here](/development/guideline/video).
+We use a YouTube [video channel](https://www.youtube.com/fieldtriptoolbox) that contains video recordings of lectures. The videos are embedded in some tutorial pages and [listed as an overview](/video) on their own page.
 
 ## GitHub
 

development/testing.md

@@ -73,9 +73,9 @@ More background information about this test and others that are named `test_bugX
 
 When you modify or remove pre-existing code, you should find the necessary [test scripts](https://github.com/fieldtrip/fieldtrip/tree/master/test) and run them on your local computer. Note that these test scripts are also included in your own `fieldtrip/test` directory.
 
-For example, let's say you made a modification to the **[ft_preprocessing](/ft_preprocessing)** function. You first need to see if the corresponding test for **[ft_preprocessing](/ft_preprocessing)** exists. These tests are always starting with `test_ft_xxx` where `ft_xxx` is the function being tested. In our case **[test_ft_preprocessing](/test/test_ft_preprocessing)** exists. So, we need to run this test first.
+For example, let's say you made a modification to the **[ft_preprocessing](/reference/ft_preprocessing)** function. You first need to see if the corresponding test for **[ft_preprocessing](/reference/ft_preprocessing)** exists. These tests are always starting with `test_ft_xxx` where `ft_xxx` is the function being tested. In our case **[test_ft_preprocessing](/reference/test/test_ft_preprocessing)** exists. So, we need to run this test first.
 
- If **[test_ft_preprocessing](/test/test_ft_preprocessing)** did not exist or if you want to do a more detailed testing, you can list all test scripts together with their list of requirements and dependencies in a [MATLAB table](https://nl.mathworks.com/help/matlab/ref/table.html):
+ If **[test_ft_preprocessing](/reference/test/test_ft_preprocessing)** did not exist or if you want to do a more detailed testing, you can list all test scripts together with their list of requirements and dependencies in a [MATLAB table](https://nl.mathworks.com/help/matlab/ref/table.html):
 
     % find your copy of FieldTrip
     [ftver, ftpath] = ft_version;
@@ -207,5 +207,5 @@ Private test data is stored in the directory `/home/common/matlab/fieldtrip/data
 Public test data is stored in the directory `/home/common/matlab/fieldtrip/data/ftp`, which on the Donders Windows desktops is available on `H:\common\matlab\fieldtrip\data\ftp`. This data is also available from the [download server](https://download.fieldtriptoolbox.org/).
 
 {% include markup/info %}
-Note that test scripts that depend on public data or that do not require any data can be executed by everyone. If needed, the **[dccnpath](/utilities/dccnpath)** function will download the public data automatically.
+Note that test scripts that depend on public data or that do not require any data can be executed by everyone. If needed, the **[dccnpath](/reference/utilities/dccnpath)** function will download the public data automatically.
 {% include markup/end %}

faq/should_I_use_t_or_F_values_for_cluster-based_permutation_tests.md

@@ -14,7 +14,7 @@ Cluster-based permutation tests have originally been used with a t-test statisti
 
 ## The decisive step in cluster-based permutation testing: computing the cluster mass
 
-Cluster-based permutation testing involves calculating the test statistic (t-value, F-value, etc.) on so-called random partitions of the data (for details see [Cluster-based permutation tests on event related fields](/tutorial/cluster_permutation_timelock.md)). Calculating the test statistic for a cluster involves the step of computing the summary statistic for the whole cluster, which usually is the _cluster mass_, but could in theory be any other way of summarising the test statistics across contiguous points of your data in time and space that are above a certain threshold value. The cluster mass is simply the sum of all the statistic values across the cluster. The concept has been introduced in work with structural MRI data (Bullmore et al., 1999, in IEEE Transactions on Medical Imaging).
+Cluster-based permutation testing involves calculating the test statistic (t-value, F-value, etc.) on so-called random partitions of the data (for details see [Cluster-based permutation tests on event related fields](/tutorial/cluster_permutation_timelock)). Calculating the test statistic for a cluster involves the step of computing the summary statistic for the whole cluster, which usually is the _cluster mass_, but could in theory be any other way of summarising the test statistics across contiguous points of your data in time and space that are above a certain threshold value. The cluster mass is simply the sum of all the statistic values across the cluster. The concept has been introduced in work with structural MRI data (Bullmore et al., 1999, in IEEE Transactions on Medical Imaging).
 
 
 ## The cluster mass destroys the equivalence between t and F distributions and makes them lead to different p-values

tutorial/coregistration_opm.md

@@ -192,7 +192,7 @@ If you rotate the image, the first thing to notice is that the nose is properly
 
 ## Coregistration using head localizer coils
 
-Conventional SQUID MEG systems are based on certain number of sensors (e.g., 275 or 306) that are placed in a fixed-size helmet to accommodate most participants. Unless when using [custom headcasts](Barnes paper), the SQUID MEG helmet gives the participant a few cm of space around the head. The heads of different participants will therefore not be in the same position relative to the helmet, for an individual participant the position of the head in the helmet will differ between sessions, and can even vary within a session. Conventional SQUID MEG systems therefore commonly use head localization or head position indicator (HPI) coils. The HPI coils are placed on the head - usually on well-defined [anatomical landmarks](/faq/how_are_the_lpa_and_rpa_points_defined) - and at the start of the recording session a small current is passed through the coils to create small magnetic dipoles. Sometimes the localization is repeated at the end of the recording session, and some systems also have the possibility to do the localization continuously. These magnetic dipoles can be localized, thereby determining the position of the sensors relative to the anatomical landmarks. All commercial SQUID MEG systems have a standard procedure for this that is well-integrated in the acquisition protocol and software, consequently the MEG recordings stored by the acquisition software include the sensor positions in [head coordinates](/faq/coordsys).
+Conventional SQUID MEG systems are based on certain number of sensors (e.g., 275 or 306) that are placed in a fixed-size helmet to accommodate most participants. Unless when using [custom headcasts](https://doi.org/10.1016/j.jneumeth.2016.11.009), the SQUID MEG helmet gives the participant a few cm of space around the head. The heads of different participants will therefore not be in the same position relative to the helmet, for an individual participant the position of the head in the helmet will differ between sessions, and can even vary within a session. Conventional SQUID MEG systems therefore commonly use head localization or head position indicator (HPI) coils. The HPI coils are placed on the head - usually on well-defined [anatomical landmarks](/faq/how_are_the_lpa_and_rpa_points_defined) - and at the start of the recording session a small current is passed through the coils to create small magnetic dipoles. Sometimes the localization is repeated at the end of the recording session, and some systems also have the possibility to do the localization continuously. These magnetic dipoles can be localized, thereby determining the position of the sensors relative to the anatomical landmarks. All commercial SQUID MEG systems have a standard procedure for this that is well-integrated in the acquisition protocol and software, consequently the MEG recordings stored by the acquisition software include the sensor positions in [head coordinates](/faq/coordsys).
 
 OPM sensors allow for individual placement and use variable-sized helmets. Furthermore, labs that operate an OPM MEG system will not all have the same number of sensors; some labs have as few as 8 sensors, whereas other labs might have up to 128 sensors.