scriabin-op64.krn: pp is rendering below staff 4, not staff 3

[bel28kent]

The pp on line 1842 should render below staff 3, but is currently rendering below staff 4.

!!!COM: Scriabin, Alexander
!!!OTL@@FR: Sonate no 7
!!!OTL@@EN: Sonata No. 7
!!!OPS: 64
!!!ODT: 1911–1912
!!!AGN: Sonata
**kern	**kern	**dynam	**kern	**dynam	**kern	**dynam
*staff4	*staff3	*staff3/4	*staff2	*staff2/3	*staff1	*staff1/2
*clefG2	*clefF4	*	*clefG2	*	*clefG2	*
*k[]	*k[]	*	*k[]	*	*k[]	*
*M6/8	*M6/8	*	*M6/8	*	*M6/8	*
=145	=145	=145	=145	=145	=145	=145
2.r	8AAN] 8AN]	.	8ee#N]	.	4r	.
.	8r	.	8r	.	.	.
.	8r	.	[8a	p	8r	.
*	*clefG2	*	*	*	*	*
.	.	.	.	.	8qbb#	.
!	!	!	!	!LO:DY:b=3	!	!
.	8c## 8b# 8ff#	.	4.a_	pp	40ggg#LLL	pp
.	.	.	.	.	40eee#	.
.	.	.	.	.	40ccc##	.
.	.	.	.	.	40bb#	.
.	.	.	.	.	40aaJJJ	.
.	8r	.	.	.	8r	.
.	8r	.	.	.	8r	.
=	=	=	=	=	=	=
*-	*-	*-	*-	*-	*-	*-
!!!system-decoration: {(*)}
!!!filter: flipper -a
!!!RDF**kern: > = above
!!!RDF**kern: N = linked
!!!RDF**dynam: > = dim.
!!!ENC: Bryan Jacob Bell
!!!END: November 2021 to April 2022
!!!PED: Günter Philipp
!!!PTL: Ausgewählte Klavierwerke (Edition Peters)

[craigsapp]

The !LO:DY:b parameter numbers are actually relative, and do not relate to the staff numbers. So change 3 (with the intended meaning of *staff3 to 2 (with the meaning the second staff to the left of that **dynam spine:

Since you have a *staff3/4 **dynam spine, it might be better to move the pp to that spine. Then the pp will be placed below the *staff3 staff without a number qualification:

If you don't care about being below, it will be placed "c" style (center between the staves) without !LO:DY:b:

That will depend on how it is displayed in the source edition (but they look very similar). Also it would depend on if the notes in the 4th staff are pp later on. If not then !LO:DY:b is better. Currently in verovio dynamics are not rendered, so difficult to check by listening.

[craigsapp]

I could possibly add !LO:DY:b=s3 which would mean place on *staff3. rather than the third staff to the left of the dynamic. This would make extracting single staves or a different arrangement of staves better in terms of the dynamic placements (which could be placed on the wrong staff if a **kern spine is removed that would otherwise be moved to whatever staff is third from that **dynam spine).

It would still be best to encode relatively as discussed above, but I could write a tool that switches between absolute positioning (!LO:DY:b=3) and relative positioning (!LO:DY:b=2). Then you could convert to absolute method before extracting **kern spines in a different arrangement.

[bel28kent]

My preference generally is for absolute / fixed / static solutions over relative / arbitrary / dynamic ones. In practice, the former can greatly reduce the number of cases and simplify reasoning about new programs.

It also seems to me that the absolute (staff) position is more intuitive. For piano music, the third or fourth staff is an edge case. When there are only two staves, you get the same behavior whether or not the position is interpreted as absolute or relative. Given:

**kern	**kern	**dynam
*staff2	*staff1	*staff1/2

*staff1 is both the staff one and the first from the **dynam spine and *staff2 is both staff two and the second staff from the **dynam spine. So I think the assumption would be of absolute / staff positions. This also seems more musically intuitive as a dynamic belongs to a certain part or parts, i.e. the !LO:DY:a or !LO:DY:b is both visual and musical. It specifies that the dynamic is attached to a part (1, 2, 3, etc.) and not multiple parts (DY:c).

[craigsapp]

I realize that, but absolute assignments in general are less flexible that relative ones, and I only use this information to distinguish between single-staff parts and double-staff parts (keyboard grand staff -- or triple-staffed parts like organ with an added pedal staff -- or a double grand staff as in this case). See this recent discussion which is slightly related to literal versus more symbolic description of accidentals on turns: rism-digital/verovio#3761

The *staff and *part information was originally coming from MusicXML imports, but otherwise I did not do much with this information. The conversion to MEI only looks at the order of the **kern spines and not the *staff numbers (see exception that was added below). In MusicXML, the data is organized by *part, and *staff is inferred from parameters on the notes (so grand staff parts are a single part which internally can be found to have two staves). This is possible to do in Humdrum, but I do not process grand staff parts in this organization:

**kern
*part1
*^
*staff2   *staff1
*^        *^
v1    v2  v1   v2

Instead, I am converting to:

**kern     **kern
*part1      *part1
*staff2     *staff2
*^          *^
v1    v2    v1    v2

This makes it easier to extract the top or bottom staff with extract, and I use RDF markers on the notes for when a melodic line crosses over to the other staff.

But I don't have problems with adding !LO:DY:s3 for placing on the staff labeled *staff3, and then writing a tool that can convert between absolute and relative staff assignments for the dynamics. It will not be tool difficult, but there is an additional complication that when you extract staves 3 and 4 from the Humdrum, they will be mapped to staves 1 and 2 in the MEI export (I map from right to left ordering of the **kern or otherwise staff-like spines (**mens) for example, so I will have to do a double mapping to place on the correct staff.

A non-documented feature I added last year is that you can reverse the order of the *staff# numbers and the verovio Humdrum-to-MEI converter will detect this and reverse the order of the **kern spine staves (so in that case the highest staff is on the left rather than the right):

Unlabeled spines (assumes low-to-high ordering of the **kern spines:

[View in VHV]

Traditional ordering of spines with staff labels (low-to-high):

[View in VHV]

Reverse ordering of spines to staff mappings with *staff labels in reverse order from traditional Humdrum interpretation of low-to-high (making the data now high-to-low):

[View in VHV]

Doing this would allow the subspines to be in the pitch height order (high-to-low) that you are wanting in the source data (where flipper will not be necessary to flip the high-to-low that I use for subspines).

[View in VHV]

---

Also another note: I do look at the slash in the **dynam staff data, such as

**dynam
*staff3/4

If there is a slash, then the default position of dynamics will be to center them between the next two staves on the left (and I do not check for adjacent number for the 3, and 4 values):

[View in VHV]

Without the slash, the dynamic will be place below the next staff to the left:

[View in VHV]

And notice that the *staff# of the dynam is ignored because it only applies to the next **kern staff to the left.

I will have to fix the reverse ordering system for use with dynamics (the dynamic should go in the middle of staff 1 & 2 not below staff 1):

[View in VHV]

---

!LO:DY:a or !LO:DY:b is both visual and musical. It specifies that the dynamic is attached to a part (1, 2, 3, etc.) and not multiple parts (DY:c).

Yes, although it is incorrect to use **dynam to share amongst more than one part unless it is a grand staff. For a single staff these will be for dynamics on a single voice, but that will be complicated and there will be a need for "invisible" dynamics to assign to both (multiple) voices but only show it above or below when the dynamic is being placed on a particular voice, but applies to both (as can happen in keyboard music where the staff-positioned dynamic applies either to all voices on that staff, or just the top/bottom voice on that staff.

---

Note that I do not encode ( or ) for crescendos/dimuendos, and I would use autodynam to add them when necessary for analysis. (autodynam is currently in Humdrum Extras, so not available in VHV until I convert it to humlib).