MS 3.5 alpha crash on chordsymbol playback

• May 8, 2020 - 14:11
Reported version
3.x-dev
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

MuseScore 3.5 Alpha AppImage /
Insert a chord symbol over a note, switch on "Play" for it in the Inspector and let the score playback, the program closes.
OS: Linux Mint 19.3, Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: 1ee2fe3


Comments

Status active needs info

No crash for me either, regardless of whether I enable chord symbol playback in Edit / Preferences / Note Input or not. So we'd need what's different for some people. I am also using the AppImage on Linux, using the default soundfont. I installed the AppImage using the "install" option (which apparently can help with some crashes).

The forum topic came with a sample score, attached here.

Wild guess / very vague feeling: could it have to do with language/translation? I had a crash yesterday and while playing with chord symbols playback I also switched between translations, System ("de" for me) and en_US, maybe en_GB too, I don't recall. I do remember though that suddenly an additional channel showed in the mixer, "Chord Symbols" and "Akkordsymbole".

Attachment Size
ChordSymbolPlay3.5alpha.mscz 4.54 KB

Hmm, opening that score, checking Mixer and switching from System to en_US crashes
Opening that score again, directly changing language: no crash! And then checking the mixer: 2 chord symbols channels!!

Easy way to reproduce a simiar crash, even if I am not sure that it is entirely the sae thing:
- new score
- add chord symbol near the end of the s ore (so you dont have to wait for too long)
- crash when playback cursor reaches end of score.

It only happens when the playback mode is "until next chord symbol" or until end. Not if it's for the segment's duration

Following Jojo-Schmitz's indications in the previous comments, I found I can reproduce the bug only if MuseScore language is not English.
For example:
1- load MuseScore and change language to Italian;
2- close and reopen MuseScore;
3- load that file;
4- start playback -> it hits an assert in debug build.

The assert is at line 539 of libmscore/rendermidi.cpp.
The function const Channel* channel = staff->part()->harmonyChannel(); returns a null pointer.

Edit:
Indeed, Channel::HARMONY_NAME is "Chord symbols", but the channels after loading that file are "Normal" and "Akkordsymbole".
After loading file and then changing language (e.g. from Italian to English), there are 3 channels: "Normal", "Akkordsymbole" and "Simboli accordo" (="Chord symbols" in Italian).

I can also reproduce Marr11317's crash.
It hits, in a debug build, another assert, this time at line 3742 of libmscore/score.cpp
Q_ASSERT(tick <= lastMeasure()->endTick());
The tick is set at line 476 of mscore/seq.cpp
int tck = cs->repeatList().utick2tick(cs->utime2utick(qreal(playFrame) / qreal(MScore::sampleRate)));

I think the problem is generated when creating the chord symbol channel, at line 601 of libmscore/part.cpp
c->setName(qApp->translate("channel", Channel::HARMONY_NAME));
I think that name should not be translated (maybe somewhere else).
It is also saved in the file. In the attached file we can find:

        <Channel>
          <program value="0"/>
          <synti>Fluid</synti>
          </Channel>
        <Channel name="Akkordsymbole">
          <program value="0"/>
          <synti>Fluid</synti>
          </Channel>

So, when loading the file the "Normal" channel and the "Akkordsymbole" channel are created. If the language is not English and additional channel is created with name "Chord symbols" translated to that language.
When playing, the harmony channel cannot be found because the names do not correspond.

Makes sense, glad we got to the bottom of it anyhow!

@Marr11317 I don't see a crash following your steps, is your language set to English? If not, maybe it's just the same problem? Or maybe only an issue in a debug build if it's an assertion failure? I'm testing on the actual alpha.

In reply to by ABL

| I can also reproduce Marr11317's crash.
| It hits, in a debug build, another assert, this time at line 3742 of libmscore/score.cpp
| Q_ASSERT(tick <= lastMeasure()->endTick());
| The tick is set at line 476 of mscore/seq.cpp
| int tck = cs->repeatList().utick2tick(cs->utime2utick(qreal(playFrame) / qreal(MScore::sampleRate)))

Yep this is the one. It has nothing to do with translation though (as it looks to me)

As I said, though, I can't reproduce the problem with playback at the end of the score. So we'd need you to open a separate issue and post your actual sample score, as whatever you are seeing, seems to be not related to this issue, and in any case I can't reproduce it.

Yes I do. So again, please attach the score. Also, as I said, say exactly what build you are using, Maybe I still won't be able to reproduce the problem, but we'll have more info that might help. Right now there is literally nothing I can do.

Seems my PR fixes the crash (and the translated text to get saved in score file), but it fails to translate those channel names (for display) in the Mixer labels too, so a bit more work needed

Priority P0 - Critical

Question is whether to use "normal" (lowercase) and "harmony" for those channel names (only the latter is used in the score files as far as I can tell), as in the original implementation (prior to efcf14a), and leave it to the translators to translate it for the UI (others like arco, pizzicato, etc. are lowercase too), esp. as "Chord symbols" is too long for that mixer label already.

PR amended for that, including artifacts for testing (although those don't have the channel names translated in the UI, that required the PR to get merged, the string to get translated, and the translations to get updated).
https://github.com/musescore/MuseScore/pull/6071/checks?check_run_id=66… (macOS and AppImage) and https://ci.appveyor.com/project/MuseScore/musescore/builds/32771661/art… (Windows)

Further question is how or whether at all to deal with scores using those channels (translated, if keeping the names, all, if not) already, just ignore, as it got to have been an development build (which comes with an explicit warning about potential compatibility issues) or the Alpha?

Fix version
3.5.0