humdrum-tools / verovio-humdrum-viewer

Verovio Humdrum Viewer
http://verovio.humdrum.org
38 stars 9 forks source link

Spine split and *rscale #154

Open jacekiwaszko1 opened 6 years ago

jacekiwaszko1 commented 6 years ago

*rscale interpretation placed in first subspine works also for second subspine:

**kern
*^
*rscale:2   *
16cL    4c
16e .
16g .
16ccJ   .
*v  *v
*-

subspine-rscale1

And *rscale:1 interpretation added to second subspine cancels first interpretation:

**kern
*^
*rscale:2   *rscale:1
16cL    4c
16e .
16g .
16ccJ   .
*v  *v
*-

subspine-rscale2

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):

**kern
*^
*Xtuplet    *
20cL    12cL
20e .
.   12c
20g .
20cc    .
.   12cJ
20eeJ   .
*v  *v
*-

subspine-xtuplet

**kern
*^
*tuplet *Xtuplet
20cL    12cL
20e .
.   12c
20g .
20cc    .
.   12cJ
20eeJ   .
*v  *v
*-

subspine-tublet2

**kern
*^
*cue    *
16cL    4c
16e .
16g .
16ccJ   .
*v  *v
*-

subspine-cue

craigsapp commented 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:

screen shot 2018-10-15 at 7 50 14 am

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).

screen shot 2018-10-15 at 8 12 43 am

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:

screen shot 2018-10-15 at 8 31 20 am

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:

screen shot 2018-10-15 at 8 35 57 am
jacekiwaszko1 commented 6 years ago

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:

subspine-rscale3

craigsapp commented 6 years ago

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:

screen shot 2018-10-16 at 4 47 23 am

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.

jacekiwaszko1 commented 6 years ago

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):

subspine-rscale4

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.

craigsapp commented 6 years ago

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.