Bug: Slicing time conversion for take markers should not take account of offset or playback rate

[AlexHarker]

Please tell us what you were doing! You can include code and files by drag and dropping them into the text area.

The current code takes account of playback rate and take offset:

ReaCoMa-2.0/lib/slicing.lua

Line 103 in 864098a

slice_points[i] = (slice_points[i] - data.take_ofs_samples) / data.playrate

However, testing with Reaper 7.34 shows that this ends up with incorrect results, as Reaper is already converting internally. The following screenshot using onsetslice shows two versions of a file (top is playback rate 1 and no offset, bottom is faster with an offset). It is clear that the alignment is not the same (as one would expect) of waveform and markers.

This is solvable by simply removing this aspect of the conversion - it does appear that some accounting for reversal is necessary.

If you encountered an error processig a file, can you please upload the file here? Make sure to compress it beforehand or use a sharing service.

Any file will show the issue

What was the expected result?

Alignment of waveform and markers in a similar fashion regardless of playback rate and source offset.

What was the actual result?

See pic

FluCoMa Version

2.10

What operating system were you using?

Mac

Operating system version

Mac OS 14

[jamesb93]

I suspect this is something that has changed since 6.x.x. I'll have to test.

Either your solve is the solve and it was always broken, or i'll have to branch off in the code based on the version.

[AlexHarker]

I haven't tested what happens when you commit. I suspect that we should probably apply at this point.

[jamesb93]

Apply the markers simply reads back whatever markers are stored in the item, so it is likely WYSIWYG.

The calculation taking into account the playback rate is another thing though.

[jamesb93]

It might also be useful to test playback rate with no offset. Maybe the offset calculation is off too 🤷

[AlexHarker]

I've tested both separately and neither of them should be applied - AddProjectMarker2 is what is used to translate to markers or it is SplitMediaItem - both of these get adjusted for item offset, so I think what is happening here is that time in the project is real clock time and take markers are specified in "media time". My guess is that if I do something on items with offsets or different rates the final result will be correct, but the preview wrong. I will test to confirm and if so the solution is to move the maths into helpers.process. I'd also suggest sanitisation like markers at the beginning (or end) of takes should happen there. I can do a PR after investigation if that is helpful?