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

Corrected Offsets for tied notes. #366

Merged
merged 3 commits into from
Aug 7, 2024
Merged

Corrected Offsets for tied notes. #366

merged 3 commits into from
Aug 7, 2024

Conversation

manoskary
Copy link
Member

@manoskary manoskary commented Aug 1, 2024

Tied note mismatch during parsing of Kern scores. Corrected by omitting second loop for tie_prev.
Also corrected parsing of G clef with octave change.

Closes #365
Closes #367

@manoskary manoskary added the bug Something isn't working label Aug 1, 2024
@manoskary manoskary requested a review from sildater August 1, 2024 15:08
@manoskary manoskary self-assigned this Aug 1, 2024
@manoskary manoskary linked an issue Aug 1, 2024 that may be closed by this pull request
@sildater
Copy link
Member

sildater commented Aug 5, 2024

simple fixes for two bugs during **kern import. Two minor questions:

  • is there a reason to comment the faulty code instead of just deleting it?
  • is there a reason to only accept treble Clefs on the second line for octave changes? It seems that **kern allows for all options and we could just parse them all by getting rid of the conditionals lines 565 - 571?

@manoskary
Copy link
Member Author

Thanks @sildater for your review and your comments!
To answer your questions:

  • is there a reason to comment the faulty code instead of just deleting it?

I was unsure if the second pass for tied notes could be helpful so I decided to keep it but you are right it is not useful so I deleted it and added a couple of comments.

  • is there a reason to only accept treble Clefs on the second line for octave changes? It seems that **kern allows for all options and we could just parse them all by getting rid of the conditionals lines 565 - 571?

In principle, a general parsing would be better but in practice, kern lines can take many forms since there are no strict formatting rules within kern files. In an attempt to parse as correctly as I could, I restricted the accepted solutions as much as possible. As the kern parser gets better maybe we can start loosening some of the constraints but for the moment I would suggest keeping it as is.

@sildater sildater merged commit df54d0c into develop Aug 7, 2024
3 checks passed
@sildater sildater mentioned this pull request Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants