Feature: Auto measure label handling

[riedde]

Better handling of Measure labels

• joining labels when multiple measures pointing to same zone (avoids labels like 1/9)
• also works with already joined labels (multiRests)
• introducing diacritical labels (supplied and del)

needs:

• [x] code clean up
• [x] introducing functions (avoid redundancy)

[bwbohl]

@riedde what’s the status of this draft, any chance to resolve conflicts and close TODOs in the near future?

[riedde]

@bwbohl conflicts resolved. I'll have a look at the TODOs

[bwbohl]

What’s an appropriate dataset for testing this?

[riedde]

@bwbohl e.g., https://klarinettenquintett.weber-gesamtausgabe.de/index.html?lang=de (Erstdruck 1)

[bwbohl]

Tested with the klarinettenquintett dataset:

• label seem correct but Concordance navigation fails ,e.g. On Baermann D+-st with the multirest in Allegro/Klarinette M.1–11 ff.

[bwbohl]

The multiRest at the start of the Allegro in D+-st is also missing "–11"

[krHERO]

ping @nikobeer

[bwbohl]

pinging @riedde

[riedde]

@bwbohl I reviewed the function measure:getMeasureLabel(). It seems that there was an else case missing (added at https://github.com/Edirom/Edirom-Online/pull/302/commits/14837c2761d9d49c583c69571af04e029d7e6a14). I'm not sure if this coveres all cases but it is much more better than before and works with several datasets. I can offer you my dataset for testing if you like (three editions).

[riedde]

While testing I noticed that there is a bug when loading the measure based view with parts. I have to investigate this.

[bwbohl]

does this also address #432 ?

[riedde]

@bwbohl I don't think that this addresses #432, directly.

[peterstadler]

I think this should wait for #419 to be merged and then needs some adjustments for the new proper serialization options.

[hizclick]

I think this should wait for #419 to be merged and then needs some adjustments for the new proper serialization options.

NB: #419 is merged

[bwbohl]

testing this still returned an error when trying to address a measure in D+-st (see above):

error

<exception>
  <path>/db/apps/Edirom-Online/data/xql/getMeasurePage.xql</path>
  <message>exerr:ERROR org.exist.xquery.XPathException: err:XPST0003 expecting semicolon ';', found 'declare' [at line 29, column 1]</message>
</exception>

[bwbohl]

@riedde and yes it would probably be good, if you could provide your dataset (assuming it has diacritics in measure labels)

[bwbohl]

With the data from open edirom I get some nasty NaN values…

[riedde]

@riedde and yes it would probably be good, if you could provide your dataset (assuming it has diacritics in measure labels)

https://github.com/Baumann-Digital/baudi-data/releases/tag/v1.0.0

For a deletion see source A^P3 page 32 (Last measure is a deleted one [5th of movement III])

For auto-joining measures see ED^St-SSAA page 2

[riedde]

With the data from open edirom I get some nasty NaN values…

Give me a hint where this occurs and I'll have a look at.

[peterstadler]

This PR makes an excellent example of directly adding tests for the module functions. So we would not need to send around test data and test manually but rather use that test data to drive the automated tests.

I will try to create a basic test as an example for you to elaborate on.

[peterstadler]

added a first test in 09974a5108d8d5c08cec9d0205c0e4e0dbf56a48 Further tests can simply be appended to /testing/XQSuite/measure-tests.xqm

NB, some added tests do fail because the function does actually return attribute nodes and not strings. This should be fixed.

[bwbohl]

With the data from open edirom I get some nasty NaN values…

Give me a hint where this occurs and I'll have a look at.

e.g. Source A3 Parts "Entre Acts" measure 60-62–NaN on page 3 of the facsimile

[bwbohl]

The problem is probably due to the - (Hyphen-Minus) in the label instead of a –(En Dash). I don’t know if we have to be that strict, if so, this is just another point for an Edirom Online MEI customisation or Schematron to support content providers in authoring their files.

[riedde]

@bwbohl @peterstadler I merged develop into this branch and had some upcoming issues to resolve. now it works and the comments are resolved.

[peterstadler]

There are still issues with MEI multiRest. Consider the XQuery

xquery version "3.1";

declare namespace mei="http://www.music-encoding.org/ns/mei";

import module namespace measure = "http://www.edirom.de/xquery/measure" at "xmldb:exist:///db/apps/Edirom-Online/data/xqm/measure.xqm";


doc("/db/apps/Edirom-Online/testing/XQSuite/testdata/multiMeasureRests.xml")/mei:mdiv//mei:measure[1] 
    => measure:getMeasureLabel()

which will properly output

<xhtml:span xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <xhtml:span>107</xhtml:span>
</xhtml:span>

but will fail for mei:measure[2] (which features multiRests): https://github.com/Edirom/Edirom-Online/blob/def111dac49f7e97cf52f161cd41f14c1861bb08/testing/XQSuite/testdata/multiMeasureRests.xml#L64-L74

UPDATE: I just added a test for measure:getMeasureLabel#1 in 4d745b92a02def43479b0ba5db1f3892d03aff6c

[peterstadler]

I tried to update the code but there's still a test failing for measure:getMeasureLabel#1 at https://github.com/Edirom/Edirom-Online/blob/b45c7b57a8a06c5d228f7cb47666220f85ed03ea/add/data/xqm/measure.xqm#L90 because there can be multiple <mei:multiRest> (in multiple layers) in an <mei:measure>.

[krHERO]

at the community meeting 2024-12-18 we agreed to move this PR to next release. but extract parts from it and solve with #302 for v1.0.0 @feuerbart

[krHERO]

with the separation of frontend and backend the corresponding branch moved to backend and frontend. see the issue in the backend for continuing the discussion. for this reason, the PR in this repo will be closed.