gpx - file containing ottavas crashes MuseScore

• Jan 6, 2016 - 19:14
Reported version
2.1
Type
Functional
Severity
S2 - Critical
Status
closed
Project
Tags

The attached gpx-file from

http://www.gprotab.net/comment_tab.php?tab_id=215372#

crashes MuseScore MS 2.02 rev-f51dc11 under Win7 64b reproducibly.

Attachment Size
Marley, Bob - No Woman No Cry Live v1.gpx 208.28 KB

Comments

Title gpx - file crashes MuseScore gpx - file containing ottavas crashes MuseScore

This issue is most likely related to this one: #70571: [GP] Crash on a gpx file import

Two parts in this GP6 file (ie Organ1 and Organ2) contains ottavas. They are the culprit:
- Marley, Bob - No Woman No Cry Live organ 1.gpx
- Marley, Bob - No Woman No Cry Live organ 2.gpx

If I delete these two parts, result, no crash:
Marley, Bob - No Woman No Cry Less organs.gpx

After that, the corrupted measures may be rather simply fixed:
Marley, Bob - Score fixed less organs.mscz

I had some time to analyze the bug: indeed, the culprits are the ottava lines in the organ parts.
In particular, the "ottavaFound" trigger is not reset to 0 when the ottava actually ends. Therefore when starting a new staff the code thinks that an ottava has already started and tries to find the chord before the first chord of this new track, yielding to a crash since prevSeg is 0 in this case.
Moreover, there is a problem in the initialization of the ottava array at line 1840 of importgtp-gp6.cpp: this array is iniialized with length equal to the number of staves, but then in the code ottava[track] is accessed. It should be initialized as an array with length staves*VOICES, i.e. the total number of tracks, otherwise a garbage value is accessed when there is an ottava in a track corresponding to a number larger than the total number of staves (in the file of this report, we have 11 staves and an ottava in track 12, for example).

@cadiz1 : Do you have GuitarPro? Can you please provide a pdf version (or whatever image version can be exported by GuitarPro) of the two organ parts, so that we can check if the ottava import is performed correctly?
Unfortunately, TuxGuitar with the gpx plugin does not show the ottava lines.
Thank you for your help.

I tried with a PR to solve this crash:
https://github.com/musescore/MuseScore/pull/2987
This will solve also #70571: [GP] Crash on a gpx file import.
@cadiz1 or in general someone with GuitarPro6:
Could you please post in one thread some small examples of ottava lines in gpx files, so that I can also add some tests?
I think we would need:
- One file with one instrument and simple ottava lines (different types of ottava; one of them starting exactly when the previous one finishes)
- One file with two instruments and ottava lines in both (one ottava in instrument1 and no ottava in instrument2 and then ottavae present at the same tick for both instruments)

- Something else to test?

EDIT:
I saw that there are already some tests in issue #70571: [GP] Crash on a gpx file import. I will start with those.

1) - "One file with one instrument and simple ottava lines (different types of ottava; one of them starting exactly when the previous one finishes)"

Here: File 1 ottavas.gpx
Pdf format (export GP6): File 1 ottavas.pdf

2) - "One file with two instruments and ottava lines in both (one ottava in instrument1 and no ottava in instrument2"

See: File 2 ottavas for one instrument.gpx
This one crashes MuseScore.
File 2 ottavas for one instrument.pdf
So, similar to the test file on the other thread?: https://musescore.org/en/node/70571#comment-328121:
Ie this test file: test2.gpx

3) - "One file with two instruments and ottava lines in both [...] and then ottavae present at the same tick for both instruments"

See: File 3 ottavas for two instruments.gpx
File 3 ottavas for two instruments.pdf

@cadiz1:
thank you for the files and sorry that I was not clear (I was using the terminology of elements from MuseScore source code, i.e. tick=time position).
I have problems with test2.gpx, since it is reported as corrupted because of only one quarter in the first measure of the second instrument.
Could you please check it?

By the way, these files helped me in correcting one residual problem I was seeing with the import of ottavae. So thank you very much. I think I now have a working implementation, but I am experiencing problems in updating the PR on Github.

"I have problems with test2.gpx, since it is reported as corrupted because of only one quarter in the first measure of the second instrument.
Could you please check it?"

I don't recall exactly about this file and why there is only a quarter note in the second instrument (the image attached on this comment: https://musescore.org/en/node/70571#comment-328121 seems to indicate I entered two whole notes.)
But as it is possible with GP to enter this kind of incomplete measures, maybe inadvertently did it on this file, I can not remember (it was in July 2015!) :)
Anyway, I do not get a corruption message here with this file (ie with a quarter note in the first measure of the second instrument) but a crash immediatly.
And no matter: because after editing this file in GP6 (a whole note for each instrument into the first measure), I get the same crash. And so, the fatal scenario (or one of them?) always seems to be: a volta in one instrument, and not in the other:
test2bis.gpx
- pdf format: test2bis.pdf

But no crash with this file (a volta in each instrument, but not at the same tick)
- test3bis.gpx
test3bis.pdf
EDIT: this last attached file (test3bis.gpx) seems a bit instable. I receive sometimes also crashs (maybe after toggle the loading of the file between 2.0.3, 2.1 dev. and 3.0 dev. ? ) With the 3.0 dev., the crash is systematic. No sure what happens exactly.

Thank you again for the files.
Updated PR with also tests:
https://github.com/musescore/MuseScore/pull/2988
(I had to open a new PR because of rebase problems)

Ottava lines appear wrong in the tablatures, but that is bug #29986: Ottava notes from music staff do not translate correctly to linked tablature.

This patch works also in 2.1, but a conflict merge must be solved in order to backport the PR (since types and subtypes changed in 3.0-dev with respect to 2.x branch). In 2.1 I see problems in the second group of notes of tied chords in the original example from #1, but I think that is another unrelated bug.