[MU4 Issue] sigD = 256 crashes MuseScore

[PopSlime]

Describe the bug
Selecting notes and rests in a measure whose sigD = 256 crashes MuseScore. Playback also crashes upon reaching the measure.

To Reproduce
Steps to reproduce the behavior:

1. Save a file with a single measure in Uncompressed MuseScore 3 File.
2. Modify the sigD to 256, and modify the length of the rest to match the time signature via an external editor.
3. Open the file in MuseScore and click Play.

Context

• OS: Windows 10 (10.0)
• Arch.: x86_64
• MuseScore version (64-bit): 3.6.2.548021803
• revision: github-musescore-musescore-3224f34

[Jojo-Schmitz]

The issue tracker here on GitHub is only used for tzhe current in develeopment 4.0, the master branch

For but in 3.x use the issue tracker on musescore.org.

But please also explain what "sigD" is?

Apart from that modifying the mscx with an external editor is not supported at all.

[PopSlime]

So I'm creating a custom time signature, with the denominator (sigD) being 256, however it is not listed in MuseScore (only 2, 4, 8, 16, 32, and 64 are listed), so I have to modifying the file itself. I found that when sigD = 128, which is also impossible to achieve in the app, MuseScore can work perfectly. However it crashes when sigD = 256.

[Jojo-Schmitz]

The shortest denominator MuseScore allows in the UI is 64. That is for a reason! Manually chanmge that tio anything higher is not supported, a crash in those cases is basically by design. It certainly is not a bug.

1/128 is possible BTW. See this as a bonus. It gets shown as 1/4 though. But at least no crash ;-)

[Jojo-Schmitz]

You've opened it as a MU4 issue, but it isn't. It is a limitation of MuseScore that exists ever since

[PopSlime]

I see, but I'll be glad if it can be supported in the future. Also it is weird how 1/128 works but 1/256 not, both of which are not supported. Anyway I'll look for a substitution (I have no idea why that piece of music uses such a strange time signature lol). Thanks for your reply :D

[Jojo-Schmitz]

Well 128 doesn't crash, but doesn't really work either
Guess we'd better check and forbid and report that explicitly rather than crashing on it.

One place for such a check might be

MuseScore/src/engraving/libmscore/measure.cpp

Lines 2102 to 2105 in 186ced1

	if (_len.numerator() <= 0 || _len.denominator() <= 0) {
	e.raiseError(QObject::tr("MSCX error at line %1: invalid measure length: %2").arg(e.lineNumber()).arg(_len.toString()));
	return;
	}

adding an || _len.denominator() > 64 should fix the crash and malfunctioning

[PopSlime]

128 does work in 3.6.2, but yes adding a check is necessary I guess

[Jojo-Schmitz]

I've found the place where the malfunctioning at 128th happpens, in 3.x:

MuseScore/mscore/measureproperties.cpp

Lines 128 to 130 in 3ca622a

	int index = actualN->findText(QString::number(m->ticks().denominator()));
	if (index == -1)
	index = 2;

As a 128 is not in the UI, it doesn't get found here, so falls back to the 3rd entry, a quarter
Seems supporting 128th would be very easy

But feel free to submit a feature request for 128th and 256th, at least the latter would only be possible to provide with MuseScore 4, as MuseScore 3.6.2 and earlier would crash on them. It it doesn't make it into MuseScore 4, such a feature would have to wait for MuseScore 5

[PopSlime]

lol
I see

[Jojo-Schmitz]

Actually the crash happens at

MuseScore/src/engraving/libmscore/sig.cpp

Lines 33 to 40 in 186ced1

	int ticks_beat(int n)
	{
	int m = (MScore::division * 4) / n;
	if ((MScore::division* 4) % n) {
	qFatal("Mscore: ticks_beat(): bad divisor %d", n);
	}
	return m;
	}

And this reveals that shorter than 128 is not possible without bumping up MScore::division, currently 480. This indeed would be a very major change