craigsapp
commented
4 years ago Given the examples in the documentation, when two splines must be merged into one, the *v operator must be used at the end of both spines. Then, the expected encoding should be:
Yes, that is close. But the problem with this line:
*v *v *v *v
*is that it means to merge all spines into a single one. When you do this:
....
D2 AA2 dd2 f#2
* *v *v *v
= =
*- *-the right three are merged into the second spine below. The problem is that the original spines were not restored (2:2 goes to 1:3). Technically this allowed in Humdrum, although I avoid this since it is difficult to distinguish from a bug in the data.
The current solution to this is to do each merge on a separate line:
**kern **kern
*staff2 *staff1
*clefF4 *clefG2
*k[f#c#] *k[f#c#]
*D: *D:
*M2/4 *M2/4
*^ *^
G2 BB2 g8L d4
. . a8J .
. . b8L e4
. . cc#8J .
= = = =
D2 AA2 dd2 f#2
* * *v *v
*v *v *
= =
*- *-
Either merge can happen before the other, although collapsing the right-most subspine group first make the visual display of the data a little more complex:
*v *v * *
* *v *v
* *I do not like this, and I would like to implement a new spine manipulator *V that would allow merging adjacent spines groups on a single line, where the capitalization indicate a new merge group is starting:
*v *v *V *v
* *But I have not yet implemented this system (and it would not be backward compatible with the original Humdrum Toolkit). This would improve readability and data processing in certain cases, but would also cause complications when adding/removing spines from a score (where the v/V states may need to change).
In my parser, I could also disallow merging across original spines, then the original case would be as you expected:
*v *v *v *v
* *Coming from above in the data, I keep track of which primary spine a token belongs two. If I see such a merger where two adjacent tokens are from a different primary spine (which I call a track to avoid confusion between spine/subspine terms), then I could implicitly segment the merges into two separate groups. However, this would make the data incompatible with the original Humdrum Toolkit tools, so I have avoided doing that.
I changed the documentation example to include more complex spining:
**kern **kern
*M4/4 *M4/4
=1 =1
* *^
1E 1cc 4a
. . 4g
* * *^
. . 4f/ 2c\
. . 4e/ .
* *v *v *v
=2 =2
*^ *^
* * * *^
1E 4r 4r 2gg 4d/
. 2EE 2.ccc . 4g
. . . 2ryy 4f
. 8FFL . . 4e
. 8GGJ . . .
* * *v *v *v
*v *v *
=2 =2
1AA; 1f;
== ==
*- *-And added a paragraph describing the complications:
Note that when the subspines for adjacent staves merge at the same time (at the end of measure 2), then the merges must be staggered for grouping clarity. Also when a spine needs to expand from one to three voices, there must be two
*^expansions (the first to go from one to two subspines, and the second to go from two to three spines). Also note the use of2ryy, which is used to delay merging of the spines until the end of the measure (otherwise the two right subspines could merge together before merging with the first subspine for the staff at the end of the measure). Also note that subspines should not be ended before the full duration of the last note in the subspine (so the first two subspines in the top staff in measure 2 can not merge half-way through the measure since the note in the first subspine has not yet finished sounding).
You are writing the duration after pitch in **kern tokens, such as D2 for a half note on the D below middle C. This is allowed in **kern data, so there is not real problem, but it makes the data a little more difficult to read, because scientific pitch will use a number after the pitch to indicate the octave. For example C4 in scientific pitch notation means middle C. If you put the rhythm first, such as 2D, then there is less confusion when viewing the notes out of context. Also, this would allow rhythm and scientific pitch to be mixed easily, such as 2C4 which might mean a half note middle C.
So you can keep putting the rhythm after the pitch without any problems, but there is a "canonical ordering" for **kern data in the documentation somewhere that says that rhythm-pitch is preferred over pitch-rhythm.
davidrizo
In Partial voices/layers, when two spines are to be merged into one spine the
*voperator is used on both spines:In Multiple staves, the top staff spines are merged into just one using the same method, while the bottom staff is maintained without being split or merged. This is perfect.
However, for getting the example below the encoding is a bit different.
Given the examples in the documentation, when two splines must be merged into one, the
*voperator must be used at the end of both spines. Then, the expected encoding should be:However, VHV complains because the number of tokens in the last bar line record do not match. To make it work, I've had to remove the left spine merge operator :