Slice addition case

[Joshua Albrecht]

Hi Craig and all-
I may just be dealing with an old version of musicxml2hum from humlib, but I'm working on converting single-line melodies from xml to kern, and I am frequently getting some version of the following error message:

Warning, replacing existing token: 8g# with a null token
ERROR: Negative duration: -3/4
tokendur = 1
slicedur = 7/4
token    = 4f#_
CURRENT SLICE = TS=7/4 (p0:)(s0:)(v0:) "4f#_"  sside: []  pside: []
TIMESTAMP 7/4
NEXT SLICE = TS=7/4 (p0:)(s0:)(v0:) "4f#_"  sside: []  pside: []
NEXT TIMESTAMP 7/2
Cannot deal with this slice addition case yet...
Cannot deal with this slice addition case yet...

The above is the error I'm getting for the attached file. I'm not sure what's going on with slice addition, but I'm guessing it has something to do with rhythm/meter. In the attached file, it's pretty simple and I don't see any instance of problematic rhythms fitting into a bar. Thoughts? Should I be concerned about what the conversion process is doing to the data?

Thanks much!

-Josh

[Craig Sapp]

Hi Josh et al.,

There is definitely a problem on line 8 of the Humdrum output:

Where the null token should be an 8th note (most likely 8g#).

Can you send me the original MusicXML file to test with?

-=+Craig

--
--
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 visit https://groups.google.com/d/msgid/starstarhug/CANNxkQOKZKwLfy3zz0%3DX9RjtNNB8Cjs_gj7VQ0FpXb5xzaqD4g%40mail.gmail.com.

[Joshua Albrecht]

Oh, interesting. Is it possible, especially because this is before bar 1, that this could be thought of as an almost complete pickup measure? Anyways, I'm attaching the musicxml file for you to look at.

Thanks!

-Josh

To view this discussion visit https://groups.google.com/d/msgid/starstarhug/CAPcjuFdbPgx%3DPZMSSbSy_OzfmUNV-3KeeYEujLkO6r7ytkNvpA%40mail.gmail.com.

[Craig Sapp]

Hi Josh et al.,

The problem is in the first measure of the MusicXML data on lines 92–94:

This moves back the timeline by a 16th note (colliding with the duration of the first 8th note and causing the problem by positioning the next note before the previous one has ended).

Also a similar problem on lines 182–194 at the end of measure one where there is a gratuitous backup of an 8th note:

There is also a reverse problem:

This also needs to be removed in the first measure.

(no other problems that I see in the score). It looks like you (or your student :-) might have been editing the file to create a monophonic score ("mel" in the filename).  And somehow something got confused in the data which then caused problems in the MusicXML export.   The file was created by MusicXML 3.1.0 (maybe upgrading Musescore 4 might help avoid such problems).

Removing these lines before converting to Humdrum fixes the problem:

Attached is the fixed input and updated output.

Also the file loads into MuseScore 4.4.4 with this message:

"Opening anyway" results in a strange gray rest added (caused by the <forward>) in first measure) and a gray plus meaning the measure is overfilled:

Musescore ignores the problem caused by the backup by how it converted the MusicXML data.

-=+Craig