Open jacekiwaszko1 opened 6 years ago
By the way, It is a bit confusing that some interpretations work for both unseparable subspines (like rscale), some work for both subspines, but you can separate them (eg. tuplet and Xtuplet) and some work only for one subspine by default (eg. cue and *Xcue):
These are designed for how I am expecting them to be used. Cue and tuplet control have to allow for different settings at the same time on the staff. Rhythmic scaling is mostly intended to be controlled at the staff level rather than the layer/voice level.
A main problem for rhythmic scale is: when two subspines merge, which value should be the one that continues?
*cue
operates on the layer level, and continues at the same level even when the spines merge/split:
Tuplets behave differently, and can probably be improved, although the use cases are more different than cue notes. They have a single state for the staff like, but the staff is processed layer by layer in the Humdrum-to-MEI converter, so the control state is not causal (tuplets in the past can be altered by *tuplet
in lower-numbered layers).
In other words, the tuplet control is at the staff level, but it is influenced by the serialization of the layers when converting to MEI data. Here are how two subspines are encoded in MEI:
<staff>
<layer> data for layer 1 </layer>
<layer> data for layer 2 </layer>
</staff>
For *rscale
, it is implemented similar to *tuplet
but I disabled the non-causality that is present in tuplet control:
rscale
is inteneded for large-scale adjustment of the rhythms, and !LO:N:vis=
should be done for layer-specific cases. But I notice that rscale is getting priority over the layout setting, at least in this case:
I see. So proper encoding of original example should look like this?
**kern
*^
* *
!LO:N:vis=8 !
16cL 4c
!LO:N:vis=8 !
16e .
!LO:N:vis=8 !
16g .
!LO:N:vis=8 !
16ccJ .
*v *v
*-
It gives expected rendering:
That is the current way of doing it. What is the source music that this is from? And what is the meaning or purpose of using eighth notes rather than 16ths? In other words, is this because the beam is incorrectly missing a line? In that case I would say that the above encoding is the most correct way.
Are the 8th/16th notes taking only a quarter-note duration with notes on the other staff? That would indicate *rscale
would be better. Particularly if the notes are supposed to be cue-sized (indicating ad lib rhythm). So this might be a better encoding:
**kern
*^
*rscale:2 *
! !LO:N:vis=4
16cL 4c
16e .
16g .
16ccJ .
*v *v
*-
And I would have to fix the converter so that the LO command has priority above *rscale
. The Musedata printing system will handle the above encoding properly:
the conversion from Humdrum to Musedata (with hum2muse tool in Humdrum Extras):
$ Q:4 T:1/4 C:4
P C0:x0
C4 1 1 e u [
E4 1 1 e u =
G4 1 1 e u =
C5 1 1 e u ]
back 4
C4 4 2 q d
measure
Another possible encoding (depending on the meaning of the notation) would be:
**kern
*^
*rscale:2 *
16cL 8c
16e .
16g 8ryy
16ccJ .
*v *v
*-
Where rscale is used to set the display of both layers, and an invisible rest is added to complete the bottom layer's duration.
Are the 8th/16th notes taking only a quarter-note duration with notes on the other staff? That would indicate *rscale would be better. Particularly if the notes are supposed to be cue-sized (indicating ad lib rhythm).
That's the case (Chopin's Mazurka op. 30 no 4, Braitkopf & Härtel):
And that's why I was trying to use *rscale
. Your first option of encoding is exactly what I wanted, so I will use that in score.
Although quarternote changed back into quarternote looks a bit strange in this example.
One possibility is to implement this as an RDF:
**kern
*^
16cLZ 4c
16e .
16g .
16ccJ .
*v *v
*-
!!!RDF**kern: Z = single beam, cue-sized
That would be more concise than the alternative:
**kern
*^
*cue *
*rscale:2 *rscale:1
16cL 4c
16e .
16g .
16ccJ .
*v *v
*rscale:1
*Xcue
*-
And since it occurs often in Chopin's music, it should make it more efficient to encode and easier to read the data.
*rscale
interpretation placed in first subspine works also for second subspine:And
*rscale:1
interpretation added to second subspine cancels first interpretation:By the way, It is a bit confusing that some interpretations work for both unseparable subspines (like
*rscale
), some work for both subspines, but you can separate them (eg.*tuplet
and*Xtuplet
) and some work only for one subspine by default (eg.*cue
and*Xcue
):