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
Thanks for this dataset! The semantic files seem to encode accidentals differently so that I fear that one can't parse them correctly, and perhaps you can help me to understand the convention you used by creating them?
My understanding of the encoding so far was that it is inspired by the PrIMuS semantic definition, but that CPMS decided to encode accidentals in what PrIMuS calls agnostic. With this in mind, this example makes sense to me:
D#4 is the only note with an accidental symbol, and thus the only note with an accidental in the semantic file. In particular, the F-notes don't get an accidental (which the semantic format of PrIMus would suggest), as the sharp comes from the key but not from an accidental symbol.
When reading the semantic file of the first example, then the sharp of the key must be added to the F note to get the correct pitch. But in the second example the flat must not be added to the B note, and there is no indication in the file encoding which rule to apply then parsing the semantic files.
The first B-note received a courtesy accidental. The next two are Bb notes due to the key. However, the last B-note has a natural and therefore is a B-Natural. How would one tell the B-natural apart from the B-flats?
The text was updated successfully, but these errors were encountered:
liebharc
added a commit
to liebharc/homr
that referenced
this issue
Jun 28, 2024
Hello,
Thanks for this dataset! The semantic files seem to encode accidentals differently so that I fear that one can't parse them correctly, and perhaps you can help me to understand the convention you used by creating them?
My understanding of the encoding so far was that it is inspired by the PrIMuS semantic definition, but that CPMS decided to encode accidentals in what PrIMuS calls agnostic. With this in mind, this example makes sense to me:
https://github.com/itec-hust/CPMS/tree/main/semantic/training/6826807-5
D#4 is the only note with an accidental symbol, and thus the only note with an accidental in the semantic file. In particular, the F-notes don't get an accidental (which the semantic format of PrIMus would suggest), as the sharp comes from the key but not from an accidental symbol.
My issue arises with https://github.com/itec-hust/CPMS/blob/main/semantic/training/6546825-4/
The F4 note has a courtesy accidental which doesn't show up in the semantic file. But the true issue is that the B-Natural has no indication of that the natural symbol cancelled the key for this note.
When reading the semantic file of the first example, then the sharp of the key must be added to the F note to get the correct pitch. But in the second example the flat must not be added to the B note, and there is no indication in the file encoding which rule to apply then parsing the semantic files.
I just found this example, and it might make the issue much clearer: https://github.com/itec-hust/CPMS/tree/main/semantic/training/91103002-5 : The semantic file has four B-notes
note-Bb4_eighth note-B4_eighth note-B4_eighth note-B4_eighth
The first B-note received a courtesy accidental. The next two are Bb notes due to the key. However, the last B-note has a natural and therefore is a B-Natural. How would one tell the B-natural apart from the B-flats?
The text was updated successfully, but these errors were encountered: