Crashes when doing anything with extra strings (lute)

• May 2, 2020 - 10:20

Hi, in my demo file is a very simple example where I wish to arrange Bach's famous Cello suite (measures 19-20) for the 13 course lute, and this low open note should be a C#, here's what I got so far..

(edit: see bold below)
If I (somehow) manage to get to change the note to C#, it crashes.

If I change the open tuning of the C2 string to C# in the instruments dialogue, it crashes.

If I change it from 'open string' (checkbox) to not open whereas I can presumably fret it, it crashes.

If I (somehow again) add a sharp to the score it for some reasons unknown makes the note a G#9.

Okay, I found the bug, if a open string is above a fretted string, is when the crash occurs. I 'open' a string above it for example, and it crashes. My guess is the tab software freaks out that maybe it can't use that string in the tab section.

I'll search for or submit a bug report if there isn't when I get around to it..

Attachment	Size
error_example.mscz	7.78 KB
instruments_screenshot.jpg	101.62 KB

Comments

Jojo-Schmitz

• May 2, 2020 - 10:48

Confirmed, with MuseScore 3.4.2 and even in latest development build.
Please file in the issue tracker

Strange enough: it doesn't crash in a Debug build in QtCreator/MinGW, but does in a RelWithDebInfo build in VS2019:

   ntdll.dll!0000000076d8a365()    Unbekannt
    kernel32.dll!0000000076c615aa() Unbekannt
    MuseScore3.exe!_free_base(void * block) Zeile 105    C++
    [Inlineframe] MuseScore3.exe!std::allocator<int>::deallocate(int * const) Zeile 780  C++
    [Inlineframe] MuseScore3.exe!std::vector<int,std::allocator<int>>::_Tidy() Zeile 1695  C++
    [Inlineframe] MuseScore3.exe!std::vector<int,std::allocator<int>>::{dtor}() Zeile 673  C++
    MuseScore3.exe!Ms::StringData::fretChords(Ms::Chord * chord) Zeile 252  C++
    MuseScore3.exe!Ms::Chord::cmdUpdateNotes(Ms::AccidentalState * as) Zeile 1729   C++
    MuseScore3.exe!Ms::Score::getNextMeasure(Ms::LayoutContext & lc) Zeile 2716 C++
    MuseScore3.exe!Ms::Score::collectSystem(Ms::LayoutContext & lc) Zeile 3489  C++
    MuseScore3.exe!Ms::Score::doLayoutRange(const Ms::Fraction & st, const Ms::Fraction & et) Zeile 4570   C++
    MuseScore3.exe!Ms::Score::update(bool resetCmdState) Zeile 301    C++
    MuseScore3.exe!Ms::Score::endCmd(bool rollback) Zeile 264 C++
    MuseScore3.exe!Ms::Score::cmd(const QAction * a, Ms::EditData & ed) Zeile 4155    C++
    MuseScore3.exe!Ms::ScoreView::cmd(const char * s) Zeile 2685    C++
    MuseScore3.exe!Ms::ScoreView::cmd(const QAction * a) Zeile 1945  C++
    MuseScore3.exe!Ms::MuseScore::cmd(QAction * a, const QString & cmd) Zeile 6530  C++
    MuseScore3.exe!Ms::MuseScore::cmd(QAction * a) Zeile 5957 C++
    [Externer Code]   
    MuseScore3.exe!Ms::ScoreTab::actionTriggered(QAction * _t1) Zeile 227 C++
    [Externer Code]   
    MuseScore3.exe!Ms::runApplication(int & argc, char * * av) Zeile 7782   C++
    MuseScore3.exe!main(int argc, char * * argv) Zeile 92  C++
    [Externer Code]

I suspect this being related to MSVC not supporting VLAs

tigerkindred

• May 2, 2020 - 10:52

Hey thanks for getting back to me so quick - I'll file a report in the morning for sure, as maybe I still can't re-tune it unless that was fixed too. It's interesting the debug version works with it, I'll check that out perhaps, and work on uncompressed files so I can fix bug-inducing madness when I break something again..

Jojo-Schmitz

• May 2, 2020 - 10:53

You've set up that tab staff to show 11 strings, have 13 strings and only 8 of those being fretted. Not sure how much sense this makes?

tigerkindred

• May 2, 2020 - 11:54

I had to work around a few things, is all.

8 was the default frettable strings, which I couldn't change at the time before I knew I had to 'uncheck' all the open strings up to the 11th in order to fret the 11th string.

11 lines are shown as 11 is the number of strings I actually use, as I had to expand the tab to read the lower notes or get around a maybe bug:

Lute tab should ideally use slashes to inform the reader how many strings down should be struck, though this 'notation' or formatting errors (fret numbers shown -0-, -1-, 9 10 11 on the same line as seen in the image) didn't make sense to me (the 11 is maybe 11th string, though 11th string was was fretted to 1 now, not open, so being '11' is useless/erroneous) so I had to expand the number of lines drawn in order to read every note I used.

cadiz1

• May 2, 2020 - 12:25

It seems there is a few confusion here.
Your picture simply shows that you are using the wrong tablature. "Modern" tablatures are not, should not be used with lutes. This is not intended, implemented for this. That is why you observe these unexpected extra and truncated lines below the staff. And not more by changing the number of lines in your tablature.
For lutes you have to use the historical tablatures (French or Italian Tab), and then there is no problem.
See, e.g: historical tab.mscz

For example, from the Instruments dialog:

EDIT: Also, see: https://musescore.org/fr/node/278562#historical-tablature

tigerkindred

• May 2, 2020 - 13:41

Oh wow, this is amazing thank you! Okay.. so, I guess, after I uncheck the open strings to get around that crash-bug, I go to fix that C in to a C#:

(pressing sharp toolbar button)

Wow! Well, if I hit 'up' on the note instead of sharp it finally updates the score.

Yet, only the score changes.
The problem I run in to (am I unlucky, or sacrilegious?) is that with the French notation .. wait for it..

a\ + 1 = b\ a\\ + 1 = b\\ a\\\ + 1 = b\\\ 4 + 1 = ... ??? Always 4 no matter what note!
Yes, the French notation indeed is meant to change to numbers after three slashes I realise.

So, I have to wonder .. should 'b\\\\' or 'b4' exist? Or am I in the wrong to want to even attempt to tab that? Should I give up and overlay a comment? I know retuning might be easier for the player, but in this transcription it's not difficult to fret the 11th string once or twice and will be preferred.. (I can't see from a glance that fretting so low is 'illegal' in French notation)

Thank you all for bearing with me, I tend to require strange things .. though for every bug I find, I find a two new features I like.

(attached historical tab_2.mscx is where I'm at, non-open strings + score not reflecting tab)

cadiz1

• May 2, 2020 - 14:38

"So, I have to wonder .. should 'b\\' or 'b4' exist"
Nope. See how it was implemented a few years ago: https://musescore.org/en/node/67261#comment-307651

wolfgan

• May 2, 2020 - 12:48

if you have open strings in the string data make them fretable

Jojo-Schmitz

• May 2, 2020 - 12:54

Open strings are open because they don't have frets

wolfgan

• May 2, 2020 - 15:43

you are completely right but the bug is : musescore crashes completely if you change the note on an open string

Jojo-Schmitz

• May 2, 2020 - 15:45

And rightfully so: an open string plays one note exactly.
But yes, it should not crash on that, but this crash seems like a bug in MSVC to me, not in MuseScore

wolfgan

• May 2, 2020 - 17:15

if you enter music from another staff in a lute tablature and there is only one note not fitting on an open string musescore crashes. In my opinion this is a bug (this note should be red like the notes out of range)