I’m using the functionality of Dexterite 3.8 to run task protocols with 2000 unique trials. However, when I load the logged data, it appears as though the TP and TARGET tables don’t go beyond 1275 entries. The entries are split up into 5 sections, for example X, X_2, X_3, X_4, X_5, each of length 255 (I assume because of data type limitations), but 5 of these only covers up to 1275.
Am I missing something?
You’ve run up against a limitation of the data saving format that we have historically used. The C3D format only allows us to use a certain amount of memory to store parameters before the file becomes corrupted. When saving out all of the parameters (which includes tables) the tables can be trimmed back in the manner you are seeing in order to fit into the file. This only happens when the number of rows in the tables is quite high as you have seen, tables with even 500 rows would never be trimmed.
For the moment, the dtp file used to create your exam ZIP file is stored in the ZIP file, so you can extract the dtp and use MATLAB’s built in XML parser.
In the next version of Dexterit-E (3.9) the storage format has been updated extensively to avoid problems exactly like this one. From your point of view analyzing data you will not notice a difference.
All the best,
Thanks Duncan. Importing the .dtp is a bit annoying, since the tables are just constructed as big blocks of characters. For now, I’ll save a separate file when I create the .dtp that has all the required information, and I’ll look forward to the release of 3.9.
Hi Duncan, any idea when Dexterit-E 3.9 will be released? Being able to read all trial data from the saved files would make my analysis pipeline significantly simpler.
We’re just started the release testing for 3.9. That should mean we will be ready for release around the end of February.