Measuring numbers note

[craigsapp]

In https://1520s-project.org/work/?id=Ver3001 the 6th measure is labeled as barline 5. Is that desired?

Preferably there would be a =1 barline at the start of the data, lack of a barline seems to be confusing the MusicXML-to-Humdrum converter (or did you delete that barline?).

There are ways of fixing the problem on the command line (not yet available in VHV):

(1) remove the barline numbers with the humextra command:

barnum -r input.krn > output.krn

(2) Add an explicit barline before the first note for measure one (no need to label it as barline 1.

(3) Automatically add barlines with this command:

barnum output.krn > final.krn

You can tell me at what stage the first barline was omitted (perhaps in the convert-to-humdrum option in VHV which converting a MusicXML file info Humdrum, and I can study why it is happening.

The barnum tool should be able to handle this sort of case properly if the first measure of data does not contain a barline at its start. If the time signature (2/1 in this case) matches the duration of the measure, then the data starts with measure 1, and the first explicit barline in the data should be labeled as bar 2.

[benory]

No, the error in the barline numbers is not intentional. This seems to have arisen in the musicxml2hum conversion. I use:

musicxml2hum name_of_file.musicxml | tassoize > name_of_file.krn

It must be during this process that the bar numbers get offset by one.

I'm wondering if we can batch process the files, and/or edit the tassoize filter to include the barnum command?

[craigsapp]

There is also a different MusicXML-to-humdrum converter built into VHV:

which is doing the same thing -- but I found the problem: you seem to be using 2/2 as the meter (by using cut-time). This is equivalent to 1/1 rather than 2/1. As a result the first measure is considered to be a pickup measure, and therefore determined to be measure 0 when labeling the first measure. You then seem to correct the time signature to 2/1 after converting.

It would be better to use 4/2 as the time signature rather than 2/2 if that is what you are doing in Sibelius.

I could automatically update all existing scores. I will have to write a short script to insert the correct number of barlines, and then I can batch process all existing scores.

The current measures seem to be causing the negative measures numbers in the activity plots (but I also found some places that can be improved in the x-axis range for the merged activity plots).

[craigsapp]

Here is an illustration of the encoding problem:

On the left I highlight the time signature in the MusicXML exported from Sibelius:

    <time symbol="cut" color="#000000">
     <beats>2</beats>
     <beat-type>2</beat-type>
    </time>

Notice that the cut-c symbol you are using in the score is not cut-c but rather cut-time. When generating MusicXML output from Sibelius, you should change these to 4/2 time signatures (unless Sibelius can be told that cut-time represents 4/2 rather than 2/2 (and you probably need to use 4/2 unless a more proper 2/1 can be created). Then you can change them to cut-time for making a PDF.

[craigsapp]

Fix done in commit https://github.com/benory/1520s-project-scores/commit/407ba670025ede5ec15e73e6acc988a60f5ea1b1

[craigsapp]

A script called bin/fixBarnums was added:

https://github.com/benory/1520s-project-scores/blob/main/bin/fixBarnums

This script will fix the bar/bar number problems in a score. Usually this should be done through the makefile command make fix-barnums or make fb for short.

This can be done after each Humdrum file is added to the repository and the bar numbers have problems. Repeated running of make fb should not cause a problem, but it is useful to run git diff after running to check for problems in the bar numbering.

If the script seems like it is not causing errors, it could be added to the make humdrm command by changing the default makefile target in Makefile from:

humdrum: segment id newlines

to

humdrum: segment id newlines fix-barnums

Note that the barnum tool from Humdrum Extras must be installed (the fixBarnums script will complain if it cannot find it).

[craigsapp]

You should check bar numbers around section boundaries to make sure the bar numbers are correct (casual checking indicates there are no problems). Also check around mensuration changes (which I did not check). There could be problems occasionally when the mensuration changes are not the same in all parts, but there is a way of forcing barline numberings on every measure in barnum if that is a problem (otherwise if there are two measures which sum to the prevailing time signature, then the middle barline between them will not be numbered by default).

The barnum tool requires time signatures that match the durations of the measures (such as cut-c needing to be described as *M2/1). If you use 2/1 (or 4/2) for cug-c in the Sibelius files when exporting MusicXML, you probably will not need to run this script.

[benory]

Thanks, Craig! The genesis of this appears to be an exporting problem. The underlying time signature in Sibelius in my scores is usually 2/1 or 4/2 but I think my use of the symbol seems to overwrite this when I export to MusicXML.

I'll run the script as needed. This is very helpful!