bel28kent / Mysterium

An encoding of Alexander Scriabin's solo piano music in kern
7 stars 1 forks source link

op23_no01: does not render when `!!!filter: flipper -a` is used #47

Closed bel28kent closed 7 months ago

bel28kent commented 7 months ago

Without !!!filter: flipper -a:

Screen Shot 2024-04-22 at 3 53 36 PM

With !!!filter: flipper -a:

Screen Shot 2024-04-22 at 3 54 43 PM

kern

craigsapp commented 7 months ago

On lines:

Screenshot 2024-04-22 at 1 01 18 PM

Spine merging cannot be done within a measure with flipper related to a limitation in how conversion to MEI/MusicXML is done. These formats use the concept of voice/layers instead of subspines, so I read the subspines from left to right to assign to voices/layers. In this case the second layer/voice music is falling into the first layer when flipping, so the first voice becomes overfilled with notes since it is stealing the rest from the end of layer 2. When not flipping, there is no problem in this case since the first layer is not disrupted and the second layer disappears at the end of the measure. When flipper is used, both forms of the data cannot have merges that end in the middle of a measure (but a split can happen in the middle of a measure).

Something might be able to be done to fix this limitation, but it would take me a while to think about it (I would keep track of the subspines and pre-assign voice/track numbers to them, but a complexity occurs when they merge for these assignments).

For now, it is best to add spacer rests to prevent merging in the middle of a measure:

Screenshot 2024-04-22 at 1 10 15 PM

In general I keep the split spines lasting longer if there is just a brief merger otherwise:

Screenshot 2024-04-22 at 1 12 33 PM

Depending on analysis intentions, the following encoding may be more suiltable:

Screenshot 2024-04-22 at 1 14 18 PM

For example, if you want to explicitly say that the second voice is continuous as a separate melodic stream, as compared to a set of melodic fragments in the original encoding, then this encoding arrangement is better. Also, the rests that are generating the merges can be thought of as two over-struck rests, i.e., there are two rests but they overlap each other 100%.


Somewhat related: I will create a *rjoin interpretation (sooner or later). This would allow both rest in two subspines that should only be displayed once in the notation (rather than two separate rests):

16CC# 16C#  16r 16r .

It would go something like this:

*   *rjoin  *rjoin  *
16CC# 16C#  16r 16r .

This would be persistent until *Xrjoin is encountered.

This is related to automatic rest placement. I used to place rests in my Humdrum-to-MEI converter, but since last month I have removed that feature and let verovio automatically place rests vertically, since it is better at doing that than previously. Verovio vertically adjusts rests in two layers automatically to separate them, while my default was to merge them into a single rest by default. The *rjoin interpretation will allow easy switching between merged and separated rests style, and allow verovio to still manage vertical adjustments of rest against notes (which then makes it less necessary to deal with in Humdrum or add automatically within the Humdrum-to-MEI converter.

bel28kent commented 7 months ago

Fixed in 3c9edc9 by reducing and simplifying joins, and adding hidden rests. Will add *rjoin when created.