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

op63_no02: Clef placement and incorrect rests rendering #26

Open
bel28kent opened this issue Aug 19, 2023 · 2 comments
Open

op63_no02: Clef placement and incorrect rests rendering #26

bel28kent opened this issue Aug 19, 2023 · 2 comments
Labels
hum2mei This issue is caused by the necessary conversion of humdrum data to mei for vhv rendering.

Comments

@bel28kent
Copy link
Owner

op63_no02 has several passages of cross-staff beaming that also have incorrect clef placements and rests rendering in VHV.

The relevant passages are mm. 9, 11, 13–15, 26, 28–29. Here are those passages myanked in VHV.

Here is a description of the issues in m. 9; the same issues apply to all measures listed above.

  1. Rests that are rendering with quarter notes should be eighth notes (as encoded).
  2. Stems on eighth notes following the septuplet runs are not rendering.
  3. In measures with a bass clef change at the end, the clef change should be before the barline, as encoded. The last three notes should still be in the treble clef. This issue may relate to the cross-staff beaming. I have to encode these measures in *staff1 because of the alla ottava, which seems to be attached to the staff of the spine it is encoded in. So I have the notes encoded in *staff1, but the tandem interpretations for clef changes are still placed in *staff2. Here is an attempt to do the opposite; the alla ottava does not render.
Screen Shot 2023-08-19 at 9 07 29 AM Screen Shot 2023-08-19 at 9 18 41 AM
@bel28kent
Copy link
Owner Author

bel28kent commented Aug 19, 2023

N.B.: My placement of the treble clef in the VHV image is correct; I am using an urtext edition that differs slightly from the score I pulled off of IMSLP.

@craigsapp
Copy link
Contributor

craigsapp commented Aug 19, 2023

The basic problem is that XML cannot overlap element hierarchies. In MEI, <tuplet> is a container for notes, and <beam> is a container for notes. In this problems there is a tuplet which contains a subset of notes in a beam (or a beam which contains a subset of notes in a tuplet). So there are notes that need to be in both tuplet and beam, but not all notes in the tuplet/beam are in the other respective container.

The solution for this situation in MEI is called a tupletSpan, which is implemented in verovio, but it is having a problem rendering the distilled example that I created to test:
rism-digital/verovio#3500

Also, this will be somewhat complicated to implement (at least in terms of concentration), so I will probably look at it in the Autumn (and after the above issue is fixed in verovio, or a demonstration that I formulated the example incorrectly).

The octave line has complications because the notes are cross-staff (as well as the octave line), so I will also have to deal with that sort of case as well in the Humdrum-to-MEI conversion.

Probably the clef problem will be fixed after the tupletSpan is implemented.

@bel28kent bel28kent added the hum2mei This issue is caused by the necessary conversion of humdrum data to mei for vhv rendering. label Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hum2mei This issue is caused by the necessary conversion of humdrum data to mei for vhv rendering.
Projects
None yet
Development

No branches or pull requests

2 participants