Noob questions

[Bob Myers]

I have the following file:

```

!!!COM: Mendelssohn, Felix Bartholdy
!!!OTL: Sonata NR. 3
!!!SCA: BWV 565
!!!OMD: Andante tranquillo
!!!filter: autobeam
**kern **kern **kern
*clefF4 *clefF4 *clefG2
*M3/4 *M3/4 *M3/4
*MM76 *MM76 *MM76
*k[f#c#g#] *k[f#c#g#] *k[f#c#g#]
*I""Pedal *I""Keyboard *
*group1 *group2 *group2
!! split the upper staff into two voices.
* * *^
!! add a finger spine to the tenor and soprano voices for now.
* *+ * *+
* * **fing * * **fing
*IPedal *Iorgan * *Iorgan *Iorgan *
*k[f#c#g#] *k[f#c#g#] * *k[f#c#g#] *k[f#c#g#] *
*met(C) *met(C) * *met(C) *met(C) *
=1- =1- =1- =1- =1- =1-
4AA (4c# 3 4e\ (8e/ 1
. . . . 8cc#/ 5
=2 =2 =2 =2 =2 =2
4E 8d 4 2e\ 8b/L 4
. 8B 2 . 8g#/J 2
4A 4c#) 3 . 4a) 3
*- *- *- *- *- *-

```

But I have the following problems/questions.

1. When I drag this into the Verovia viewer, it highlights the last line and claims that there's an illegal empty record. But I've examined the file closely and can find nothing wrong. This problem seems to come and go.

2. I have two **fing spines, but only the second (rightmost) one seems to be getting processed. I tried adding *left and *right tandem identifiers, but no luck.

3. I want the top two staves to be grouped with a curly bracket marked Keyboard, the lower staff marked Pedal, but no combination of *part and *group and I"" I tried will work for me.

4. I tried using the autobeam filter, but it doesn't autobeam in places where it seems it clearly should.

5. Although I've marked the signature as 3/4, it shows as the big C.

6. I tried using { and } to indicate phrasing, but the viewer renders this as as upper left corner and upper right corner. Is that expected?

7. I want there to be extra space between the two top staves and the bottom staff (pedal). I looked at various Verovio options but I can't see how to control this.

Any help would be much appreciated.

[Craig Sapp]

Hi Bob,

Here are suggested updates:

[View in VHV]

(1) The last line with the warning is because of the empty line, which is not strictly allowed in Humdrum data.  I allow it in my parsers and I think it is mostly OK in the original Humdrum Toolkit (I do not remember ever having a problem with it).   The problem is that the ACE editor used on the VHV website loves to put an empty line at the end of the text, and I gave up trying to get rid of it.   If you save the file using File->Save editor contents:

then the trailing blank line will be removed automatically.  If you are copy-and-pasting, you can unselect the last line before copying or delete it later (which I typically do when pasting into the GitHub editor).

2. I have two **fing spines, but only the second (rightmost) one seems to be getting processed. I tried adding *left and *right tandem identifiers, but no luck.

I think the **fing parsing might be related to the use of *+ to add new spines.  I don't use *+, and as a result, they do not seem to be well supported in VHV.  I could work on them it you want to use them, but see the above encoding sample which is much easier to read by mapping to a more 2D layout of the data into columns.

Notice the extra space added for the second voice in the **kern data before the last **fing:

This extra space is created to align the **fing (and the primary spines of any other columns that may split), but clicking on the diagonal arrows pointing away from each other:

This is very useful for keyboard parts since the voice count changes over time for a given spine, and aligning the spines in this way makes it easier to edit the music.  But I would recommend saving in the compressed tab style which is the diagonal arrows pointing towards each other, since the original Humdrum Toolkit commands and the Humdrum Extras commands do not allow multiple tabs to separate columns (Humlib and VHV allow this).

3. I want the top two staves to be grouped with a curly bracket marked Keyboard, the lower staff marked Pedal, but no combination of *part and *group and I"" I tried will work for me.

See the revised encoding.  Line 25 is the control for this:

!!!system-decoration: {s1,s2}s3

The curly braces indicate that staff 1 and staff 2 should be grouped together.   Once this is done, add the same name to staves 1 and 2 (line 8 in the example).  If the names are identical, then they will be merged into one instrument name in between the two staves grouped together.  Note that the comma in the system-decoration line is optional.  The "s" means "staff" and refers to the staff numbers on line 6 of my sample encoding.

Note that the instrument names use a single quote, instead of a double quote:

*I"Organ

The line:

*Iorgan

means that the part is for the organ instrument.  If you do not give an explicit name to the part, then VHV will automatically add one based on this instrument code.  The top two staves do not technically need the *I"Organ (but is good in case the default name changes but you want to keep it as "Organ").  Here I removed the explicit names:

The *I"Pedal is needed to override the automatically generated "Organ" label for the bottom staff.

4. I tried using the autobeam filter, but it doesn't autobeam in places where it seems it clearly should.
5. Although I've marked the signature as 3/4, it shows as the big C.

These two are most likely related.  Line 20 in the original example contained:

    *met(C)

These are used to show the C mensural sign, which in modern form is

    *met(c)

meaning common-time.   This line comes from the prototype that you were starting with, and should be deleted since you want to show the 3/4 time signature, and not replace it with a metric symbol, such as *met(c) for common-time or *met(c|) for cut-time.

After removing the metric symbol line (I think), the autobeam filter was working.  However, I see there is a limitation in the filter, where it will not process the last measure in the score if there is no terminating barline.  So only one beam in the pickup measure was being beamed, and the beam in the second measure was not.   Typically music will have a final barline, but I can fix the case where there is no ending barline (submit an issue on humlib, as I will forget -- maybe I can fix this problem in about two weeks).

> 6. I tried using { and } to indicate phrasing, but the viewer renders this as upper left corner and upper right corner. Is that expected?

Yes, It becomes difficult to separate articulation slurs and phrasing slurs in piano music, in particular.   There is not a distinction in any graphical editor, so import into Humdrum via MusicXML will always be articulation slurs.  So the default style of {} for analytic/phrase slurs is the open brackets style.  In your example, these are articulation slurs (phrasing slurs would most likely cause two levels of slurs to be present: one for articulation and another for phrasing slurs which would be longer).

To change the notation style of {} analytic/phrasing slurs, use the construct:

!!!RDF**kern: phrase: slur

This will make the phrase markers {} look like articulation slurs.   Below I add a coloration of the phrase slurs (which is optional):

[View in VHV]

Various stylings that phrase/analysis slurs can be given:

Phrasing slurs can be hidden by using "none" as the style:

!!!RDF**kern: prase: none

Solid brackets:

!!!RDF**kern: phrase: brack

!!!RDF**kern: phrase: slur, dot

!!!RDF**kern: phrase: slur, dash

!!!RDF**kern: phrase: dash

!!!RDF**kern: phrase: dot

7. I want there to be extra space between the two top staves and the bottom staff (pedal). I looked at various Verovio options but I can't see how to control this.

Yes, this is possible (there are a lot of verovio options to search through :-), and the spacing options are a bit complicated to figure out:

 spacingBraceGroup <i>      Minimum space between staves inside a braced group in MEI units (default: 12; min: 0; max: 48)

 spacingBracketGroup <i>    Minimum space between staves inside a bracketed group in MEI units (default: 12; min: 0; max: 48)

 spacingStaff <i>            The staff minimal spacing in MEI units (default: 12; min: 0; max: 48)

 spacingSystem <i>           The system minimal spacing in MEI units (default: 4; min: 0; max: 48)

Below I add these to embedded verovio options (typically I would add to the bottom of the file since they are not otherwise interesting to see):

!!!verovio: spacingBraceGroup 10

!!!verovio: spacingStaff 20

[View in VHV]

spacingBraceGroup is for the spacing of staves if they are in a brace group, so this is the distance between the first two staves.

spacingStaff is for the spacing of the pedal staff.  I made it 20 to exaggerate.

The spacings are 12 by default, and can range from 0 to 48 (staff steps, or two values between staff lines as the unit of measure).   The staves will automatically spread out if there is any potential for collisions, so these values are the minimum allowed for any system.

-=+Craig

[Bob Myers]

Thanks again for these invaluable tips. A couple of more questions:

1. Is there any way to have measure bars extend all the way from the top of the topmost staff to the bottom of the bottommost staff?

2. I'm going to want to be able to provide pedaling notations, such as a V above or below the note indicating it is to be played with the toe. What are the chances this is possible? An alternative is to place a bracket under two or more pedal notes, which I think I can do based on your suggestions above, but then I would want to annotate the bracket with the text "r" to mean these notes are played with the right foot. Alternatively, I might want to place the text notation (lr) under a node to indicate a foot substitution. Is there any prior art for doing this kind of thing?

3. To indicate a glissando, which in the organ world refers to sliding your finger from one note to another, it is common to use a line connecting the fingering notation "1" above the first note, slanting slightly upward to the finger notation "1" on the second notation. Any thoughts on how to accomplish this?

Bob

[Craig Sapp]

1. Is there any way to have measure bars extend all the way from the top of the topmost staff to the bottom of the bottommost staff?

Yes, you can use parentheses to connect barlines across staves:

!!!system-decoration: ({s1,s2}s3)

However that is not working (you can submit an issue about that for me to fix).   Barring only the grand staff is working (this is more common in modern organ scores):

!!!system-decoration: {(s1,s2)}s3

[View in VHV]

2. I'm going to want to be able to provide pedaling notations, such as a V above or below the note indicating it is to be played with the toe. What are the chances this is possible? An alternative is to place a bracket under two or more pedal notes, which I think I can do based on your suggestions above, but then I would want to annotate the bracket with the text "r" to mean these notes are played with the right foot. Alternatively, I might want to place the text notation (lr) under a node to indicate a foot substitution. Is there any prior art for doing this kind of thing?

There is no direct representation of organ heel/toe.  I can add it fairly easily, but suggestions from **HUGers on how to encode in Humdrum would be useful.  One possibility would be to have a separate spine with heel/toe information such as **foot.  Another would be to use RDF redefinitions of up/down bows to map to toe/heel markers.   And a third way would be to use something like this:

     !LO:TX:a:t=[heel]

to display a heel mark above the staff.

For L/R text markers these can currently be done as text displayed on the score (but could be formalized into some **foot encoding system).

Here is the best way of doing foot changes as text:

[View in VHV]

To add a line of (!) for adding text, go to the line after its position (line 6, in the above music for example) and type alt-shift-L, then you can fill in the text in the desired spine.

3. To indicate a glissando, which in the organ world refers to sliding your finger from one note to another, it is common to use a line connecting the fingering notation "1" above the first note, slanting slightly upward to the finger notation "1" on the second notation. Any thoughts on how to accomplish this?

 Do you mean this (probably not exactly since this changing the finger):

which I would probably call a finger exchange (as a pianist).   I will have to check if verovio can currently do it.   

Here is something closer, but probably not yet the same as you are describing:

In this case the slurred 1,1 means to do what you want, but in this case keep holding down the F with the thumb while playing the G with the thumb.

-=+Craig

 

[Bob Myers]

Thanks once more for your response.

I will provide an example of glissando in the organ sense (sliding finger) in a separate post.

For pedals, I'm sure there are many ways to encode this, but one idea is to leverage the existing syntax and logic to handle **fing as follows:

1. Use the **fing representation.

2. Add a tandem interpretation of *pedal to indicate that the notations should be for the pedal.

3. Use 1 for the toe, and 2 for the heel.

4. Use the existing tandem interpretations *left and *right to indicate which foot.

A substitution of heel for toe could be notated as 1-2, and rendered as ∩-V etc.

A substitution of left toe for right toe could be notated, somewhat awkwardly, as

```

**kern    **fing

*              *pedal
*              *right

4C           1

*              *left

.               1

```

If we are going instead to have a **foot representation, then we could avoid the extra lines required for foot changes and use pedal-specific notations, such as RT and RH.

I will continue to ponder this. A full-blown solution might also want to support the convention of using "-" below and above the pedaling mark to indicate foot position lower or higher on the pedal.

Bob

[Bob Myers]

A quick question about the positioning of fingering notations.

On the page doc.verovio.humdrum.org/humdrum/fingering, it shows fingering marks which are at the same vertical position, in other words, aligned horizontally. In the examples you have been kindly working with me on, however, the finger marks are moving up and down with the notes. Is there some magic incantation to get the fingering notations to line up? Or is the changing position an inevitable consequence of the slur?

[Craig Sapp]

Hi Bob et al.,

On Fri, 8 Nov 2024 at 13:55, Bob Myers <bobm...@gmail.com> wrote:

A quick question about the positioning of fingering notations.

On the page doc.verovio.humdrum.org/humdrum/fingering, it shows fingering marks which are at the same vertical position, in other words, aligned horizontally. In the examples you have been kindly working with me on, however, the finger marks are moving up and down with the notes. Is there some magic incantation to get the fingering notations to line up? Or is the changing position an inevitable consequence of the slur?

The fingering positions are automatically placed with verovio, so placements such as below are a coincidence (where the numbers ignore the stems since they can still be placed without colliding with the stems):

Otherwise, there is are stacking rules in verovio which will place fingering numbers above slurs, but if the number can fit below the slur, it will be moved below: 

[View in VHV] 

In this case I forced the horizontal layout to be tight with the line:

!!!verovio: spacingLinear 0.2

which in turn allowed the "4" fingering to fit below the slur, but not any other fingerings.

------------------------------------

In theory it should be possible to get the fingerings displayed on a single horizontal line, but I have checked verovio, and it does not allow this feature for fingerings yet.   Here is how it looks when treating the fingerings as text:

:vg=7 is added to each text marker, and this maps to vgrp="7" in the MEI conversion in verovio.  vgrp means vertical group, which will cause verovio to align vgrp with the same positive integers horizontally (i.e., they are placed at the same vertical position, causing the items to be in a horizontal line).

While the vertical grouping system is not implemented for fingerings in verovio, I can add a request for it.  When available, then I could add *vg:7 (where 7 is an arbitrary positive integer) to enforce horizontal alignment of the fingerings:

[View in VHV]

And probably *vg:0 to cancel exact horizontal placement.

-=+Craig