music-encoding / encoding-tools

Tools for working with or transforming MEI Encodings
Educational Community License v2.0
41 stars 32 forks source link

Usage of saxon:evaluate() in musicxml2mei-3.0.xsl #9

Open ahankinson opened 8 years ago

ahankinson commented 8 years ago

From @ahankinson on May 28, 2015 18:13

From roewenst...@gmail.com on July 31, 2014 10:12:27

The usage of the Saxon extension function evaluate() forces users to have a Saxon EE license and it doesn't seem to be necessary.

The line 1790 could be rewritten from

to

The lines 1794, 3857, 3861 can be rewritten in the same way.

Cheers, Daniel

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=196

Copied from original issue: music-encoding/music-encoding#196

ahankinson commented 8 years ago

From pd...@virginia.edu on July 31, 2014 12:18:03

Most of the time, plain old, run-of-the-mill time signatures don't need the evaluate() function. BUT, its use is necessary to calculate a common time-base for compound time signatures, for example in /tools/musicxml2mie/Lilypond-MusicXML-TestSuite-0.1/timewise/11c-TimeSignatures-CompoundSimple.xml,

3+2 8

and in 11d-TimeSignatures-CompoundMultiple.xml,

3 8 2 8 3 4

where the string value of beats (i.e., 3+2) must be evaluated/calculated (i.e., 5) when trying to figure out the beat position of an event or a control event (e.g., something other than a note or a rest like a dynamic marking).

Unfortunately, it looks like some work is still needed for multiple time signatures because the result of running the stylesheet against the 2nd file is a meterSigGrp containing 5/2 and 1/8. Bummer! :-(

Until I can get it to function properly 100% of the time, I'm inclined to re-write the stylesheet so that it dies when it encounters a compound meter signature of the 2nd variety for now.

Labels: -Type-Enhancement -Priority-Medium Type-Bug Priority-High

ahankinson commented 8 years ago

From pd...@virginia.edu on July 31, 2014 14:18:12

I was wrong about the reason for using saxon:evaluate. It seems that it's actually being used to choose between and when a MusicXML rest doesn't specify that its duration equals a measure (using @-measure='yes') and is missing.

A better option might be to use the rest's position in the measure; that is, if it's the only event in the measure, then it gets transformed into ; otherwise, it becomes a . The complicating factor, however, is , which makes it more difficult to determine the rest's position in the measure.

Still working on it ...