*staff1/*staff2 directive is ignored in Verovio Humdrum Viewer

[Néstor Nápoles]

In the documentation of Humdrum, the following syntax is explained in example 2.3

Nevertheless, trying to render that and similar examples in the Verovio Humdrum Viewer results in the following score, with 4 different staffs.

According to another Humdrum user, a similar example (but not the same) was rendered correctly in VHV at some point, however, we can't replicate it.

Are we missing something?

Best,

Néstor

[Craig]

Hello Nestor,

You are not missing anything directly in this case. That example you cite from the documentation, I typeset by hand (before VHV was created). I do not remember that the original ms command in the Humdrum Toolkit merged data spines onto staves using the *staff interpretations.

When converting into MEI data for display in verovio, I treat each spine as a separate staff. At the moment the *staff# interpretations are ignored in VHV, but at some point I am thinking of creating a generalized tool that will compile *staff# instructions into a Humdrum file that follows those instructions, such as having two spines with the same staff number merging into the same staff in different layers.

For now, I have a specialized tool called satb2gs (SATB vocal score layout to Grand Staff layout) which is appropriate for this sort of case. Try adding the line:

!!!filter: satb2gs

anywhere in the file when editing it on VHV. Documentation page for the SATB filter:

https://doc.verovio.humdrum.org/filter/satb2gs

Your example could also use the autobeam filter:

!!!filter: autobeam

The output of this filter could be compiled into the data with the alt-c key shortcut in VHV. For satb2gs, it should not be compiled into the data. If you want to edit the beams to add cases that do not match the time signature, then there is graphic editing of beams that is pretty fast:

https://doc.verovio.humdrum.org/graphic/beams

(also using arrow keys to move between notes).

Note that the satb2gs filter is fragile, so it currently does not allow other spines of data such as text or harmonic analysis (I think). I need to allow non-kern spines to also be present in the data that is processed by satb2gs...

-=+Craig

[Néstor Nápoles]

Thanks, Craig!

The satb2gs filter works as expected. So does autobeam.

Note that the satb2gs filter is fragile, so it currently does not allow other spines of data such as text or harmonic analysis (I think).  I need to allow non-kern spines to also be present in the data that is processed by satb2gs... 

I just tried adding a **harm spine at the end and, as you said, the filter did not work after that. For our purposes (building a dataset), we do need to add a **harm spine to our encodings, however, we can probably make a separate file with the **harm spine or figure out another workaround. The notation is good enough after using these filters.

Dziękuję bardzo!,

Néstor

--
--
This is a message is from the **HUG newgroup.
To post to this group, send email to stars...@googlegroups.com
To unsubscribe from this group, send email to
starstarhug...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/starstarhug?hl=en
---
You received this message because you are subscribed to the Google Groups "starstarhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to starstarhug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/starstarhug/13b83db6-b898-4ede-ab7a-5460f8f29227%40googlegroups.com.

[Craig]

Proszę Néstor,

> I just tried adding a **harm spine at the end and, as you said, the filter did not work after that. For our purposes (building a dataset), we do need to add a **harm spine to our encodings, however, we can probably make a separate file with the **harm spine or figure out another workaround. The notation is good enough after using these filters.

I have been meaning for quite a while to fix that problem with satb2gs, so I will plan on fixing it soon...

In the meantime, you can use the following script to generate the desired GS layout with the figured bass:

recip -p input.krn | extractx -s 1,3 > temp1.fb

extractx -i kern input.krn | satb2gs  > temp2.krn

partjoin temp2.krn temp1.fb | extractx -s 3,2,4 > output.krn

You need to have both Humdrum Extras, Humdrum Toolkit (both via humdrum-tools) as well as humlib installed (recip is part of humlib; extractx, partjoin and satb2gs are in humextra, and partjoin relies on Humdrum Toolkit assemble command).

Example input to that script:

**kern **fb **kern **kern **kern

*I"Bass * *I"Tenor *I"Alto *I"Soprano

*clefF4 * *clefGv2 *clefG2 *clefG2

*k[f#] * *k[f#] *k[f#] *k[f#]

*M3/4 * *M3/4 *M3/4 *M3/4

4GG . 4B 4d 4g

=1 =1 =1 =1 =1

4G 5 4B 4d 2g

4E 6 8cL 4e .

. . 8BJ . .

4F# 6 4A 4d 4dd

=2 =2 =2 =2 =2

*- *- *- *- *-

And example output:

**kern **fb **kern

*clefF4 * *clefG2

* * *

* * *

* * *

*^ * *^

*I"Tenor *I"Bass * *I"Soprano *I"Alto

!*clefGv2 !*clefF4 ! !*clefG2 !*clefG2

*k[f#] *k[f#] * *k[f#] *k[f#]

*M3/4 *M3/4 * *M3/4 *M3/4

*tb8 *tb8 * *tb8 *tb8

4B 4GG . 4g 4d

=1 =1 =1 =1 =1

4B 4G 5 2g 4d

8cL 4E 6 . 4e

8BJ . . . .

4A 4F# 6 4dd 4d

=2 =2 =2 =2 =2

* * *- * *

*v *v * *

* *v *v

*- *-

The spine terminator on **fb is not so pretty in the output, but it is legal.  There are some empty `*` lines at the start for some reason.  This can be removed with "rid -i" or "ridx -i" if needed.  Also the added *tb8 line can be removed if you want the data to look pretty.

The **fb spine is placed properly (attached to the bottom staff) for encoding figured bass with a musical part, but in this case it is more for theoretical purposes, so it would be nice to place it as the first spine rather than as the second spine.  I will see about allowing it to be moved to the first spine (i.e., attach to the entire system rather than a particular part).  The visual result will be the same, but the analysis data will be more clearly separated from the musical data.

-=+Craig

[Néstor Nápoles]

Hi Craig,

Thanks for the script!

We were talking about this (Laurent, my colleague and I) and we thought that encoding as SATB (with the extra annotation spine) does the job for now. We don't strictly need the GS except for easier visualization (the original examples we are encoding are written in GS). It is good to know about the satb2gs program, I plan to use it as a pre-processing step whenever we want to engrave the encoded scores.

Regarding the script you provided, I have a working setup of humlib, humextra, and humdrum.

Step 1 and 2 run as expected.

temp1.fb:

**recip **fb

* *
* *
* *
* *

4 .
=1 =1
4 5
8 6
8 .
4 6
=2 =2
*- *-

temp2.krn:

**kern **kern
*clefF4 *clefG2
*^ *^
!*I"Tenor" !*I\"Bass" !*I"Soprano" !*I"Alto"
!*clefGv2 !*clefF4 !*clefG2 !*clefG2
*k[f#] *k[f#] *k[f#] *k[f#]
*M3/4 *M3/4 *M3/4 *M3/4
4B 4GG 4g 4d
=1 =1 =1 =1
4B 4G 2g 4d
8cL 4E . 4e
8BJ . . .
4A 4F# 4dd 4d
=2 =2 =2 =2

*v *v * *
* *v *v
*- *-

Running partjoin with these files as input shows the following message:

Problem determining smallest time unit in input files.

And stdout seems to be blank when the program ends.

It could be that I am running an old version of the libraries (~June 2019). 

I will figure this out when we get to the point of requiring to do the engravings, as it is not stopping us at the moment (and I don't want to contribute with more workload on your schedule :).

Thanks again.

Best,

Néstor

--
--
This is a message is from the **HUG newgroup.
To post to this group, send email to stars...@googlegroups.com
To unsubscribe from this group, send email to
starstarhug...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/starstarhug?hl=en
---
You received this message because you are subscribed to the Google Groups "starstarhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to starstarhug...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/starstarhug/ca30e373-2ad2-4ab1-9187-1dc071f89422%40googlegroups.com.

[Craig Sapp]

Hi Néstor,

> Running partjoin with these files as input shows the following message:

> Problem determining smallest time unit in input files.

That is peculiar... the problem is caused by output from the minrhy program being empty:

https://github.com/craigsapp/humextra/blob/c818b799/scripts/perl/partjoin#L80-L86

Why the output from minrhy is empty is unknown (minrhy means minimum rhythmic unit, which should be "8" for the example).  One possibility is that you cannot use standard input into partjoin, and the input must be in the form of filenames:

    partjoin file1.krn file2.krn

and not

    cat file1.krn file2.krn | partjoin

but I doubt that you did that.  Another problems could be that the tab characters got messed up if you are copy/pasting the example data from the **HUG email (in which case try with one of your files instead).

Try "minrhy file1.krn" and "minrhy file2.krn" and "minrhy file1.krn file2.krn" (using the real names of the two files) and see what happens. For the example I posted, the program should return "8" in all three cases.

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

You may be interested in studying the website:

    https://chorales.sapp.org

This is a demo website for displaying music in Humdrum form on the web (and Bach chorales in specific).  In particularly you can try the typesetting page:

https://chorales.sapp.org/typesetter

Notice the black boxes on the right.  You can adjust the size of a chorale or make it SATB or GS format, etc., and then copy/paste the text of those black boxes to create a webpage with the music notation.  After I fix the problem with non-kern spines with satb2gs, you can also use the satb2gs to dynamically switch between SATB and GS formats on a webpage (see the "filter" parameter in the demo page below).

Here is an example:

<html>
<head>
<title>My Example</title>
<script src="https://verovio-script.humdrum.org/scripts/verovio-toolkit.js"></script>
<script src="https://plugin.humdrum.org/scripts/humdrum-notation-plugin.js"></script>
<script>var vrvToolkit = new verovio.toolkit()</script>
</head>
<body>
<div style="width:590px">
<script>displayHumdrum({
   source: "chor370",
   scale: 32,
   spacingNonLinear: 0.58,
   header: true,
   appendText: "!!!header-left: @{SCT}",
   filter: "satb2gs",
   uri: "github://craigsapp/bach-370-chorales/kern/chor370.krn"
})</script>
<script id="chor370" type="text/x-humdrum"></script>
</div>
</body>
</html>

In this case the data is being downloaded from Github:

https://github.com/craigsapp/bach-370-chorales

The source code for the Bach Chorales website is on Github in the same repository as the data, but in the gh-pages branch:

     https://github.com/craigsapp/bach-370-chorales/tree/gh-pages

The data can also come from an arbitrary URL (with limitations caused by HTTPS and related factors).  And you can insert the Humdrum file contents into a webpage directly (as discussed on the Humdrum Notation Plugin website, https://plugin.humdrum.org).

Here is an online example linked to from the above documentation:

https://www.w3schools.com/code/tryit.asp?filename=G67CR2SIWSCG

Click on the green "Run" button to see the resulting webpage.

-=+Craig

[Craig]

Cześć Néstor,

I have generalized the satb2gs filter in VHV to allow for non-kern spines in the input.

Here is a demo:

https://verovio.humdrum.org/?file=BachChoralesAnalyzed/chor311.krn

This downloads a Bach chorale with harmonic analysis into VHV:

Notice that the score is in SATB format, with the **harm data showing below the bass staff (The **harm spine is actually being attached to the system rather than the bass part, **fb data cannot yet be attached to the system and be converted for display in Verovio, but I will plan on adding that capability).  The harmonic labels are colliding since verovio does not do collision avoidance for MEI <harm> data yet.  This should not be much of a problem with figured bass since they are narrow, but the spacing of the music can be widened to fix the problem at the moment.

Now when you add the satb2gs filter to the data:

      !!!filter: satb2gs

The score will correctly be converted to grand-staff orientation, even though the **harm data is also present:

For data that does not include beams, they can be added automatically with the autobeam filter, either by piping the data to/from satb2gs:

     !!!filter: satb2gs | autobeam

or

    !!!filter: autobeam | satb2gs

Or, the filters can be added as separate lines:

!!!filter: satb2gs

!!!filter: autobeam

or

!!!filter: autobeam

!!!filter: satb2gs

In this data file, there is a **root spine (second on the line).  To make this spine visible as notation, use the filter:

!!!filter: satb2gs | autobeam | shed -e "s/root/kern/X"

The updated satb2gs filter can also be used with the Humdrum Notation Plugin:

    http://plugin.humdrum.org

You can try playing with the filter option in this online demo using HNP:

https://www.w3schools.com/code/tryit.asp?filename=GAJ2F23MWWAS

(or copy and paste the HTML text in the editor on the above page to try in a file on your local computer)

There is also a command-line version of the new satb2gs version.  The new version is only available in humlib (https://github.com/craigsapp/humlib), so I am calling the humlib version "satb2gsx" to indicate that it is the extended version.  Eventually the humlib programs will replace their twins in Humdrum Extras from which they originated (humlib has a different Humdrum file parser, which allows for integration with verovio while Humdrum Extras's organization does not).   In VHV, you can use either "satb2gs" or "satb2gsx", with both of those filters pointing to the humlib version of the tool (Humdrum Extras and standard Humdrum Toolkit commands are not accessible from VHV since they cannot be compiled into javascript for running in a web browser).

For those who want to use the command-line version of the tool but do not have humlib yet, here are the basic installation commands:

      git clone https://github.com/craigsapp/humlib

      cd humlib

      make

      make install

then check if satb2gsx is in the command path:

      which satb2gsx

To run from the command-line is equivalent to VHV filters:

      cat input.krn | satb2gsx | autobeam > output.krn

An easy way to process all files in a directory in bash:

      mkdir temp

      for i in *.krn

      do

           cat $i | satb2gsx | autobeam > temp/$i

      done

The directory "temp" will contains all of the data files with the grand-staff layout.

Here is the C++ source code of the new version of satb2gs:

     https://github.com/craigsapp/humlib/blob/master/src/tool-satb2gs.cpp

-=+Craig

[Néstor Nápoles]

Hi Craig,

I just tried the new satb2gs with your example. It works great. Thank you.

The collision is not a big problem, we mostly want to store the data, visualizing only for debugging purposes.

For the time being, we are only rendering the files we are encoding in VHV, I will let you know how the command-line version goes once I try it as well.

Wszystkiego najlepszego w nowym roku!

Best,

Néstor

--
--
This is a message is from the **HUG newgroup.
To post to this group, send email to stars...@googlegroups.com
To unsubscribe from this group, send email to
starstarhug...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/starstarhug?hl=en
---
You received this message because you are subscribed to the Google Groups "starstarhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to starstarhug...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/starstarhug/457984f2-a032-47e1-aa4d-a0d9cd168c94%40googlegroups.com.