Onset/offset times are not frame aligned

[sh0sh1n]

Describe the bug Timestamps must be aligned to the beginning or end of frames when inserted via hotkeys. Timestamps may be manually edited to arbitrary values by the user. However, while annotating any cells inserted during playback should insert cells at the beginning of the current frame as determined by the "step size".

For example, for 29.97fps videos, Datavyu uses a 34ms step size for jogging. During playback, setting times (either using set onset/offset keys or using insert cell) should use the floor multiple of the step size to set the timestamp of the cell. For inserting continuously coded cells, the new cell has an onset time at the multiple of the step size, and the prior cell has an offset set to 1ms before that time.

Inserting the current clock time without aligning to step size breaks consistency with prior coding and produces odd effects when locking onto cells (will file as separate issues).

To Reproduce

1. Play at normal speed.
2. Insert a new cell.
3. Jog backwards and forwards from the onset of the cell.

Expected behavior Onset time should be frame aligned, so jogging back several times and jogging forward should eventually bring you back to the onset of the cell. If the onset time is not frame aligned, jogging back will never return you to the onset time (though you may still be in the same frame).

Additional context Tested on 1.5.0rc1 on OS X using Native plugin,.

[TheoWolf]

@Xubes Please add the Release Candidate version to your description and the plugin used.

[TheoWolf]

@Xubes Are you certain that in previous Datavyu version, new cells timestamp is set to the floor multiple of the step size. I know that this is used only when jogging forward/backward but new cells timestamp is the exact time of the Controller Clock

[sh0sh1n]

I will verify with existing coding from v1.3.4.

[sh0sh1n]

Checked existing file coded in 1.3.x. Continuously coded cells indicated alignment: onset times were always aligned to step size (34ms in this case) and offset times were always 1ms less than the alignment time.

Checked the remainder of onset and offset times divided by the step size. Noticed that not all cells were aligned and it would be odd to have manually entered timestamps. Coded a new file (same 34ms step size) using several coding styles: continuous, point cells, and manual updates.

1. Continuous coding cells (inserted using Numpad-0) are ALWAYS aligned at the onset time and the offset time is ALWAYS 1ms less than an alignment time (remainder = 33ms).
2. Point cells are ALWAYS aligned.
3. Set Onset (Numpad-7) and Set Offset (Numpad-9) DO NOT ALIGN. Updating cell timestamps while the video is playing copies the controller time without alignment.

• NOTE: Cells were coded at 4x - 16x playback speeds.

Recommendations:

• Always align onset and set offset to 1ms below alignment time.
• Change behavior of set onset and offset commands to also always align.
• Align Controller time on Stop and Pause.

[sh0sh1n]

AlignmentTest.zip

[sh0sh1n]

Identical behavior in 1.3.7. alignment_test_1.3.7.opf.zip