I’m absolutely fine with leaving being like this, as long as the crash is fixed
Just to possibly save you trouble: it seemed to me that engine always works with the nearest downbeat (“One”) not with the nearest beat (4 in this case), so the problem might possibly come from exactly that. It makes sense from a Denon perspective even, if the “ghost” marker that LXC sets does not have the correct bpm to sync up to the next full bar. Just a thought.
Edit: The crash that happens with flexible beatgrids sometimes:
Alright, I did some in depth testing. No crashes, but the wrong bpm is used for previous marker again (as expected).
I’m having a 100% success rate at mitigating this by placing a beat marker 4 beats before the tempo change. Actually, there is no problem with desync for the following reason: After the export the following happens:
1st marker has original BPM
2nd marker that was placed with original bpm has it’s bpm adjusted to something that syncs up with the 3d marker
3rd marker has the correct bpm.
I’m pretty sure that the problem here is that engine treats every marker as a downbeat marker, and engine hat to like quadruple the speed (400%!) to put four beats between the ghost marker and the next marker. In fact, if I recreate that manually, the resulting beatgrids on engine are broken after the ghost upon export.
Interestingly, this is different when using engine to place the markers. Engine does treat them as beatmarkers there, not downbeat markers.
well, whatever. The “set ghost marker manually in advance” seems to work, so why not use it. Maybe I’ll try reimporting beatgrids from engine tonight and see what weirdness comes from that