grid snap jumps way out of place when changing time signature denominator

[th1rtyf0ur]

When dragging beat markers in a place where the time signature changes denominators (e.g. from 9/8 to 4/4), the previous anchor tends to halve or double its newly calculated BPM value, causing the right (dragged) marker to snap back or forward to the wrong place. Easier to see an example:

https://youtu.be/2_j_WRyvzGc

[th1rtyf0ur]

I think I understand why this is happening- when the right anchor is being dragged, the previous anchor continuously updates itself with the new calculated BPM, but considering the denominator of the NEW measure, instead of that of its own time signature. So when you have an anchor in 9/8 and drag a 4/4 measure to its right, the 9/8 measure's anchor gets calculated with quarter notes getting the beat, so it makes all the beat markers half as wide as they should be, and vice versa if switching the other direction.

[raynebc]

I think the issue is exactly as you described: When a beat that has a time signature change was clicked and drug, its denominator was taken into account instead of the one that was in effect immediately before. This will be corrected in the next hotfix.

On Tue, Nov 10, 2015 at 12:27 AM, th1rtyf0ur notifications@github.com wrote:

I think I understand why this is happening- when the right anchor is being dragged, the previous anchor continuously updates itself with the new calculated BPM, but considering the denominator of the NEW measure, instead of that of its own time signature. So when you have an anchor in 9/8 and drag a 4/4 measure to its right, the 9/8 measure's anchor gets calculated with quarter notes getting the beat, so it makes all the beat markers half as wide as they should be, and vice versa if switching the other direction.

— Reply to this email directly or view it on GitHub https://github.com/raynebc/editor-on-fire/issues/294#issuecomment-155343675 .

If you look through windows you can see what people are doing. If you try to look through a penguin it will bite you.

[raynebc]

Fixed by commit 5c269195f7bc989aaef267a1fd5d6836a6698287

[th1rtyf0ur]

I'm still seeing this issue on build 1426.

[raynebc]

What do you mean by build 1426? I can't reproduce the behavior anymore. If you are able to, please send me a project file with steps to trigger the bug.

[th1rtyf0ur]

Sorry, I meant (svn) revision 1426. Let me try it again w/ a fresh test project.

[th1rtyf0ur]

Yeah, still happening. Just started a new project w/ a random audio file, marked a few measures w/ different time signature bases & dragged.

[raynebc]

Maybe I'm misunderstanding you, but the EOF SVN repository on Google Code is not maintained anymore because Google is discontinuing that service. This Git repository is now the official latest source and will have all fixes. I can't reproduce the problem on the current Git version of EOF.

[th1rtyf0ur]

yes, I'm using github:

Bigal:~/docs/apps/eof-src/editor-on-fire-github$ svn info
Path: .
Working Copy Root Path: /Users/*****/Documents/apps/eof-src/editor-on-fire-github
URL: https://github.com/raynebc/editor-on-fire/trunk
Repository Root: https://github.com/raynebc/editor-on-fire
Repository UUID: 1b06e8d9-8460-1c45-5f0b-ce57b7db7bff
Revision: 1426
Node Kind: directory
Schedule: normal
Last Changed Author: raynebc
Last Changed Rev: 1426
Last Changed Date: 2015-11-16 15:40:32 +0900 (Mon, 16 Nov 2015)

[raynebc]

I still couldn't reproduce, please send me your test file with steps.

[th1rtyf0ur]

I can't attach an .eof file here, but here's what I did:

• start a new project w/ any audio
• set a few measures to different time signatures- I used 4/4, 3/8, 3/4, 12/8, 4/4
• drag the beat markers around. sometimes they'll work ok the first time, but a second drag will double or halve the BPM from what it should be, affecting the marker after it.

[raynebc]

Looks like it specifically required another anchor to be present after the moved beat in order to trigger the bug. This is fixed in commit f8b41f7d020a1a62e5679dcafc45f0cb69da36c0.

[th1rtyf0ur]

working perfectly now, thanks!