humlib icon indicating copy to clipboard operation
humlib copied to clipboard

[fb] Problems when time signature changes

Open WolfgangDrescher opened this issue 2 years ago • 3 comments

fb seems to have problems when the time signature changes. In Josquin Allez regrets there are passages where just one track changes the time signature. Sometimes numbers are missing. Sometimes there are numbers displayed when there should not be any.

Note that --frequency / --recip is not passed so every single slice should get labeled.

http://verovio.humdrum.org/?file=jrp/Jos/Jos0702a-Missa_Allez_regretz_II-Kyrie.krn

fb -i -c -a -m

Bildschirm­foto 2023-01-16 um 11 14 52 Bildschirm­foto 2023-01-16 um 11 15 48

WolfgangDrescher avatar Jan 16 '23 10:01 WolfgangDrescher

This is a problem in MEI. @tstamp is based on meter@unit and most likely the hidden time signatures for Cut-C and C are different (different meter@unit values). Preferably issue https://github.com/music-encoding/music-encoding/issues/322 would be implemented to create @qstamp which would describe time units in quarter notes so that the time signature would be irrelevant to the timestamp.

MEI also has difficulties in representing measures of different length such as the tenor measure being twice as long as the other parts. This may be related. Either the 2/1 measures can be encoded properly or the 4/1 measures, but not both at the same time. When encoding the score in 4/1 measures, there would be a <barLine> added to the middle of the 2/1 measure music. <barLine> does not rest the @tstamp counter, which is another complication. If encoding in 2/1, then the 4/1 measure will be split into two measures with an invisible barline between the two parts.

Probably not in this case (I have not looked at the Humdrum data), but there can be complexities related to using the breve as the bottom of the time signature (meter@unit in MEI) MEI does not allow the unit to be a breve, so when I convert to MEI I double meter@count and halve meter@unit.

craigsapp avatar Jan 16 '23 19:01 craigsapp

I don't have a lot of knowledge about the verovio internals and MEI, but couldn't this be fixed similar to what we discussed in https://github.com/craigsapp/humlib/issues/56 with using @startid?

WolfgangDrescher avatar Jan 17 '23 21:01 WolfgangDrescher

The main problem of using @startid for converting **fb data is that you probably need a note on the same staff as the fb data in order to attach it. It might be possible to use the @startid of a note on one staff but show the fb on another staff (I will have to test that).

craigsapp avatar Jan 18 '23 01:01 craigsapp