You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
scholarLY needs to be able to sort annotations by exact location, and so far it is only designed to parse locations up to a basic subdivision (which in most cases is suitable). The current system works since the examples aren't too complex, but it needs to be tested further and designed to deal with more complex rhythmic schemes.
Eventually this is something that should be regtested.
The text was updated successfully, but these errors were encountered:
3e03794 (in a new branch annotate-locations) shows the problem. Checkout that branch and compile annotate.ly, then see that the last annotation, attached to a slur on the the second of three tuplet subdivisions in the first beat, shows as 1 1/3.
Yes, that is technically correct in terms of time (as the grob spans 1/3 through 2/3 of the way through the beat), but isn't that misleading? We say beat 1 for first beats, beat 2 for second, and so on ... so we should say 2/3 for the second of three tuplet of a tuplet-subdivided beat.
OK, I see. But It is not a matter of parsing (and I'm pretty sure it wouldn't affect sorting by time) but rather an issue with the output formatting.
The thing is that ly:moment? is zero-based and "thinks" in terms of ratios of the whole note - instead of beats.
I don't have time to look into the code today, but I assume that I implemented a "fix" for that when displaying the beat but didn't do so on lower levels.
It's definitely something to be looked into, but on that level of output formatting.
A quick glance also pointed to util/rhythmic-location.ily in the oll-core package, but I'm not sure right now what the actual problem is.
scholarLY needs to be able to sort annotations by exact location, and so far it is only designed to parse locations up to a basic subdivision (which in most cases is suitable). The current system works since the examples aren't too complex, but it needs to be tested further and designed to deal with more complex rhythmic schemes.
Eventually this is something that should be regtested.
The text was updated successfully, but these errors were encountered: