jonkb / tictimer Goto Github PK

A reviewer wrote:

The package logs occurrence of a 10 s period in which no tic is reported – but this time window appears arbitrary: it would be useful ... (b) to allow the user to change it, either at run time, or in subsequent sensitivity analysis of the log files: how long a period of tic-free behaviour should count as a success event?

I'm hesitant to make it easy to change the 10s duration at run time, because it would be annoying in our studies, and provide one more chance for user error. But can we at least make it easier for that first suggestion to be a compile-time option? The relevant changes are only in line 51 of TicWatch .java and in all the places where a string like "10s tic free interval ended at 00:02:04" is generated. Recall that we decided long ago to use only integer seconds for timing.

I think the analysis of the log files is an interesting point but one that we did not try to supply with the first version, so I don't feel compelled to change it.

Please add the following features:

1. No rewards dispensed and all sessions are identical from the rater's perspective; essentially like scoring a “baseline” session every time.
2. This version does not need the RxTx program (so perhaps fork this from the original project in case others want to use the serial-communication version for rewards).
3. The current version saves files with names like nt848_24mo_session6_baseline_TicTimer_log.txt. The new version should instead use names like mns101_A_e_TicTimer_log.txt, where the subject code is 101, A (or B) stands for the first or second subject visit (she’s blind to which it is when rating), and “e” (from the set e,f,g,h,j,k,m,n,p) represents one of the nine 5-minute blocks (she’s blind to which it is when rating).
4. Ideally when the program is used to rate another session before the program is closed, it will pre-populate the field for entering the subject code and the field for entering the day code (A or B) so as to reduce errors and save the rater time. A bonus would be if it also checks which files are already present in the current directory for this subject & day and moves the selection to the next letter in that e,f,g,h,j,k,m,n,p set, but allowing her to change it if needed. She will almost always be rating them in that order.
5. I don’t remember but I think this program requires clicking on a “tic detected” button, but ideally it would allow her alternatively to use the letter t or the number pad Enter key or something similar so it won’t matter if she bumps the mouse.
6. Please change the recorded time for tics from mm:ss to mm:ss.xxx i.e. milliseconds. Milliseconds is a little silly for the precision actually used, but we can always round that to tenths of a second or seconds if we want, but not if we never record the info in the first place. (This is an old feature request we figured was not worth doing before, but now I’d like to do it before the rater scores all these videos.)
7. The default session duration can remain 5 minutes.

Change timing to by-the-millisecond. Note: even if we do that, the feedback to the user should probably still be reported in whole seconds.

Jon wrote:

By the way, looking back through the code, I see a drawback to the way it's made now.
It only subdivides times to the second. So, if you press Tic Detected at 3.9 s, it will say "Tic detected at 3 s" and, just .1s later at 4.0s, Tic Free Time will read 1s.

Does that make sense? Anyway, it's been like this since the early versions of TicTimer, and I don't know if it's worth it to change it because every session you've already done has been like this. It would also be quite a bit of work to make it deal in milliseconds.

Kevin replied:

​I think we talked about it at the beginning. I suppose any time division is arbitrary, and ​I figured 1 second was small enough for any real-world problem. We can put in a feature request to change it to ms, but there is almost zero urgency at this time.

please change it to an MIT license
thank you