Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

advance green bar #376

Closed
davidsancal opened this issue Sep 7, 2018 · 7 comments
Closed

advance green bar #376

davidsancal opened this issue Sep 7, 2018 · 7 comments

Comments

@davidsancal
Copy link

I was trying out a score of my own and when I gave it to him to advance the green bar I see that he does not do it well. Attached video

bug.zip

@bneumann
Copy link
Collaborator

bneumann commented Sep 8, 2018

Hi @davidsancal,thanks for sharing this bug. The behavior is, while unwanted, explainable. We are calculating the position over all found notes/rests in a measure so having these 3 rests in the left hand results in a jumping cursor.
That should still not happen and I can have a look into that.

@sschmidTU remember the shifted bounding box for whole rests? Might be connected.

@davidsancal
Copy link
Author

If it helps you in version 0.2 it works well

@sschmidTU
Copy link
Contributor

sschmidTU commented Sep 9, 2018

Yes, i noticed this is a regression. It works fine in 0.3.1 too, i think [edit: no, it doesn't].
It might be introduced by one of my changes. I'll look into it.

@davidsancal
Copy link
Author

I have been testing and not only fails with silences. I attached another video
bug2.zip

@bneumann
Copy link
Collaborator

bneumann commented Sep 9, 2018

It's just as I thougth. So the first time the cursor is highlighted is at the position of the whole rest:
image

Going to the next note:
image
And the next...
image

I am not sure actually what the wanted behaviour is. Is the cursor supposed to stick to the rest note in the first staffline or is it always following the "minimal" voice entries? I assume it is the latter so that would mean that our First staffentry is calculated incorrect. It needs to include the whole rest and the first rest but set the coordinate to the first rest.

@sschmidTU
Copy link
Contributor

sschmidTU commented Sep 10, 2018

Yes, the cursor needs to always go to the note that will be played next, that is, the note with the next, but smallest timestamp across all connected StaffLines.
Bach Air is a good example, as I said in the PR.

The bug from "bug2.zip" david posted is fixed in the PR, here's the reproduced score:
cursor_test_bug2.zip

The bug from the first "bug.zip" should with 99.99% certainty also be fixed, as it is in the samples i checked.

@sschmidTU
Copy link
Contributor

Duplicate of #138 by the way.

bneumann added a commit that referenced this issue Sep 11, 2018
#377)

* fix(Cursor jumping around): Instead first staffentry the minimum is calculated and taken as x refere

#376

* docs(Cursor jumoing): Added more detailed description of code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants