craigsapp
commented
1 year ago You posted that while I was traveling and did not notice it. :-)
I recognize the esthetic discontinuity between subspines and spines. It was too confusing to implement subspine splits so that the left side was lower and the right side was higher. This is related to how all other musical data formats label the top voice/layer/subspine as 1, and it is easier to place the data on the line in order from left to right rather than right to left. To place left to right, I need to know in advance all of the tokens before writing them into the data. A secondary factor is that the melody is typically in the top voice on a staff with multiple layers/voices/subspines, and putting the melody in the first subtoken in the spine make it easier to follow since it will not shift columns when there is a secondary voice on the staff.
Much preferably you would store subspines from high-to-low and spines low-to-high. If you need the data purely in low-to-high in both spines and subspines, you can run a score through the flipper -a filter to place the data in the fully 90-degree rotation.
Another possibility is that you add the filter line:
!!!filter: flipper -aIn your files. This filter will be run before being converted into notation by verovio, to give proper directions for stems, slurs and ties. But preferably you would store subspines in high-to-low format and use flipper -a to have full 90-degree rotated scores temporarily (for editing or data processing where the lowest voice in a subspine needs to be first).
There is also extractx -r which is analogous to flipper but for spines rather than subspines. The -r option reverses the scores by **kern spines, keeping **dynam, **text and other tandem spines unreversed (so that text and dynamics, etc. remain attached to the same **kern spine).
https://verovio.humdrum.org/?file=chorales/chor001.krn&filter=extract%20-r
Also note that I place tandem spines to the right of **kern spines rather than to the left, even when they represent data (such as lyrics) below the staff. So this is another inconsistency:
(but in this case the **dynam is automatically placed above the staff as is traditional with dynamics in vocal scores).
Related to all of this, I actually reverse spine orders (similar to extractx -r) when converting to graphical music notation within verovio. I will add a feature to have scores oriented purely from high-to-low (90-degree rotation plus horizontal flip).
@craigsapp
When kern data is converted from MusicXML using the musicxml2hum converter, the spines are in the correct order. But, the subspines are in the reverse order from how they should be if a kern file corresponds to the score rotated 90 degrees to the right.
For example, here is a Bach chorale that I manually encoded. I have annotated it with arrows to show how the subspines align with the score.
The arrows do not cross.
Here is the same music, but encoded into Finale, exported to MusicXML, and then converted using musicxml2hum.
I have marked with red circles where the arrows cross because the subspines are in the wrong order. In simple music like this it is not much of an issue, but in more complicated music the ordering of the subspines makes manual editing of files very difficult.
Here is a more complicated example from a Scriabin sonata. In this example, there are three staves, one of which is divided into two subspines and one of which is divided into three subspines.
The red arrows show where the subspines should be. I extracted measure 17 on the command-line to make the example more easy. In context, it is actually more difficult because you cannot see the header of the file this many lines down. The line number for the start of m. 17 in context is 168. In the case of Scriabin—and I would imagine that this is true for other piano composers post-Chopin—the issue is compounded by the fact that the number of subspines often changes from measure to measure in a seemingly ad hoc manner.
Are you able to fix this issue? Even having an --option that the user can specify if they want the traditional kern ordering would be helpful.