"Any help would be greatly appreciated!"
Rather than forcing meta-data into fieldnames, better data design would probably store the meta-data in the fields themselves, or into the arrangement of the data (i.e. the array size). For example using a non-scalar structure, something like this (where rows correspond to Forceplate 1, 2, 3... and the columns correspond to X, Y, and Z):
S(1,1).Force = arrX % Forceplate 1
S(1,2).Force = arrY
S(1,3).Force = arrZ
S(1,1).Moment = arrX
S(1,2).Moment = arrY
S(1,3).Moment = arrZ
etc..
S(2,1).Force = arrX % Forceplate 2
S(2,2).Force = arrY
S(2,3).Force = arrZ
S(2,1).Moment = arrX
S(2,2).Moment = arrY
S(2,3).Moment = arrZ
etc..
This means that you can e.g.:
- loop over the structure rows using basic indexing. One row is one complete data set for one Forceplate, for example the complete second forceplate data would be simply S(2,:)
- quickly convert each column to a meaningful table using STRUCT2TABLE().
- use a convenient comma-separated list syntax to help access/process the data:
In contrast, doing those kind of things will be much more complex with meta-data stuck in the fieldnames.
