Enormously Long Stems when Using Beams in GNU/Linux ARM

• Jan 28, 2016 - 22:38
S3 - Major

Hi, I just installed MuseScore 2.0.2 on my Android tablet with ARMv7 (Prestigio MultiPad 7.0 HD Duo) using chroot and Ubuntu with wily suite. If I don´t use beams with, the note stems are Ok, but if I use beams, the note stems are enormously long and the score becomes uneasy on the eye (see the attachment). Can you please help? Thanks

MuseScore 2.0.2, rev. 3543170, GNU/Linux, Ubuntu, wily suite, processor ARMv7, Android tablet (Prestigio MultiPad 7.0 HD Duo)

Attachment Size
LongStems.jpg 1.05 MB


good thinking lasconic...

I'm testing creating a new score right now in my ARM Asus C201 ChromeBook, and yes I am experiencing this issue of extremely long beamed stems in new scores, not just in scores made on x86.

I can compile for you :) ...doing so right now...

fyi, here are some beams that I am verifying I know work in 2.0.2 on my ARM:


those are all downward stems for beams without slope. I'm noticing upward stems for beams without slope are having the issue...as well as with most sloped beams.

DISREGARD....I was able to compile after updating my system, doing make clean && make...

hmm...trying to compile latest git release, and failed at very end with:

CMakeFiles/mscore.dir/importmidi/importmidi_beat.cpp.o: In function `Ms::MidiBeat::findBeatLocations(std::multimap, std::allocator > > const&, Ms::TimeSigMap*, double)':
/home/e/MuseScore/mscore/importmidi/importmidi_beat.cpp:292: undefined reference to `BeatTracker::beatTrack(std::__cxx11::list > const&)'
collect2: error: ld returned 1 exit status
mscore/CMakeFiles/mscore.dir/build.make:5877: recipe for target 'mscore/mscore' failed

That error might be something introduced since Nov 26, 2015, since I remember sucessfully compiling latest git then...

doing a make clean && make from latest git, and I notice this suspicious compiler warning:

/home/e/MuseScore/libmscore/beam.cpp: In member function 'void Ms::Beam::computeStemLen(const QList&, qreal&, int)':
/home/e/MuseScore/libmscore/beam.cpp:1209:34: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (bm.l < 0)

I'll try what lasconic said...once I can get compiler to complete.

Certainly another case for changing a char into a signed char, in beam.cpp, line 647 and 650, most probably in 648 too.

I could make that change (I just did, it compiles fine and doesn't show any obvious problem with beams on Windows) and submit a PR, but I guess it'd better be tested on ARM.

Please show us any other compiler warnings you might see

I'm attaching a txt of my compiler output after sucessfully compiling latest git on my ARM. I'm doing this for archival purposes and incase any of you want to inspect it for any suspect compiler warning messages (e.g. -Wtype-limits)

Attachment Size
git-compile.txt 164.04 KB

Good news everyone!

Lasconic's suggestion #6 did indeed fix the issue, and I have verified Reunoin, All Dudes, Triumph, Getting Started, are all rendering properly without long stems.

I no longer see that suspect compiler warning -Wtype-limits for beam.cpp

I think one moral of the story is: some of these compiler warnings are actually useful.

Attachment Size
Reunion_fixed.pdf 60.63 KB
All_Dudes_fixed.pdf 52.68 KB
Triumph_fixed.pdf 58.35 KB
Getting_Started_fixed.pdf 48.22 KB

For a test something along the lines of
char c = -1;
assert(((int)c) == -1);

might do the trick.

I'm against it, but it would be unfair if I didn't mention that most compilers (certainly GCC) allow for a compiler flag to force signedness of unspecified types.

Well, I see quite a few warning in tour compiler output, none of which cause warning on Windows (my machine) or Linux (Travis), so they all need to get looked at.
There are more signed vs. unsigned issue, some potentially unitialized variable (may cause crashes or be harmless and due to the compiler not understanding the code flow well enough), some unused variable (probably harmless, but I have seen problems with those more than 20 years ago, in gcc 1.37's optimizer), and a couple about format specifiers.

Well, I see quite a few warning in our compiler output, none of which cause warning on Windows (my machine) or Linux (Travis), so they all need to get looked at.
There are more signed vs. unsigned issue, some potentially unitialized variable (may cause crashes or be harmless and due to the compiler not understanding the code flow well enough), some unused variable (probably harmless, but I have seen problems with those more than 20 years ago, in gcc 1.37's optimizer), and a couple about format specifiers.

Just making a note that while this beam issue is fixed, I'm noticing in my ARM pdf for Reunion that the slur on measure 20 does not follow the slope of the notes, and the Pedal and 8va lines are displaced severely. I wouldn't be surprised if is the same signed char problem...I'll look into tom, but I need to go to sleep now.

Thanks for all your help...I'm so happy to have a now-usable mscore on my cheapo C201 ChromeBook.

Hi guys, thanks a lot for your great and fast work!! I am new to MuseScore and GNU/Linux and unfortunately I don´t understand how I can use the fix in my tablet. Can you please advice what I can do now to correct the stems? How can I update the program? What should I download, etc. Or are there any instructions how to fix somewhere? Thanks a lot

Currently the fix in in the git branches for master and 2.0.3, and nightly builds are available for Windows and Mac. Whether and where such builds are available for Ubuntu on ARM is a question to the maintainer of those builds.
Only other option is to build it yourself from the latest git sources, but I guess this isn't something for the faint hearted ;-)

Thanks for a reply, the hunger for a fixed program is fairly high and I´ll try my best:-) Can I please ask you this:

1/ What does it mean that the fix is in the git branches for master and 2.0.3? Does it mean that it is stored here for a new release of the program? Is it available from here? Paid or free?

2/ Is my understanding correct that I can find builders of the nightly builds (incl. the fix) and ask for Ubuntu on ARM whether it is available?

3/ If I build myself from the latest git sources, what do I need? I have spent lots of time installing good music programs to my Android tablet through GNU/Linux (frankly there is no good complex music notation software for Android yet), so a few weeks more is not an issue:-) Actually I would love to learn a bit of fixing:-))

Many thanks:-)

Thank you, so the builders are "ericfont" and "lasconic", right? I am guessing from the link: commit 1da2c07146. Thank you

Hi DusanP,

No we are not the builders. We write code and fix bugs. Basically we just wrote some text in a file. Eventually we compile or build the sofware so you can use it (building is turning code into something you can run on your device). You can of course compile it yourself if you have the skills. As Jojo mentioned, it's not particularly easy for a beginner and probably even more if you need to compile for ARM. You would probably need to compile it on a computer...

So in order to get this fix, the best (and the longest) way is to wait for Ubuntu Willy to update the MuseScore package once we will release a new version. Unfortunately that could take several months.

A little bit more involved, you could ask the maintainers of the nightly builds (compilation done every night) to add support for ARM. Currently they only support intel processors. https://launchpad.net/~mscore-ubuntu/+members#active

Last thing, apparently eric is able to compile on ARM, maybe he could share with you a mscore binary to replace yours. Since you are using different linux distribution (arch and ubuntu) it might be a problem but it could work... If you do so, it's better to use the 2.0.3 branch

But in any case, I'd advice to contact them via public way and not via direct email.

I've put the latest git build in a public folder:


Try that binary and let me know if it works on your ARM (might not work because i'm using arch linux, not ubuntu).

I'd like to get mscore on ARM running on par with x86, so please make forum post with ARM in title if you notice bugs.

I'm setting up an inotify so whenever I rebuild mscore on my arm machine, the binary is copied to that folder.

Since the fix is so simple I have applied it to the MuseScore 2.0.2 release in the Launchpad PPA. Over Christmas I enabled ARM builds in the PPA, but I hadn't actually got round to re-uploading the packages, so this is actually the first ARM build from the PPA. The previous build must have come from the 2.0.2 release in Ubuntu's default repository.

Unfortunately this fix will not be available on Trusty (Ubuntu 14.04) due to some missing dependencies on ARM, but it is now available on Vivid (Ubuntu 15.04) and Wily (15.10). If you already have MuseScore installed from the PPA, simply do:

sudo apt-get update && sudo apt-get upgrade

If you don't already have MuseScore from the PPA do:

sudo add-apt-repository ppa:mscore-ubuntu/mscore-stable
sudo apt-get update
sudo apt-get install musescore

I ran this command in MuseScore's root directory to find all occurances of "char" that are not explicitly signed or unsigned:

grep -r --exclude-dir="build.release" "[^(a-z|A-Z)]char " . | grep -v "signed " > ../char.txt

Would I be right in thinking all of these files need to be patched too? That's not a job I'm particularly keen on doing, but perhaps someone else would like to earn some points on GitHub? ;)

Attachment Size
char.txt 140.88 KB

I'm pretty sure it isn't needed to change them all, in the vast majority it just won't make a difference. But those few that throw warning during a build on arm surely need to get looked at.
Basically all those where such a char is compared against or getting assigned a negative number.

Thank you guys for your attention, I have installed the updated version from shoogle´s PPA (ppa:mscore-ubuntu/mscore-stable), it is fixed and the score is lovely indeed!! Thanks a lot! I am excited:)). Now another trouble with the score is that my keyboard is typing wrong characters (both any virtual keyboards or any hardware keyboards), but I have already made an issue, if only this was fixed, I would love to edit full scores made in x86 MuseScore in my micro tablet anywhere on the road...

Thanks again for your help!

Just reporting that I've compiled and tested this commit on another ARMv7-A machine of mine called "Novena" labtop running Debian 8.3 and Qt 5.3.2, and the beams are ok, just to confirm this issue is closed. I was also going to say the funny slur and other lines in Reunion I noticed in comment #28 are present on this machine as well. I see the same type of compiler warnings on these two machines. I've made issue regarding the next -Wtype-limit compiler issue I encountered: #96626: explicitly signed chars for struct MidiMapping for ARM

I realize that of course. All I was saying is that I was going to tackle these warnings one by one in order from my compiler list. I will be opening up a new issue for those slurs.

@ericfontainejazz thanks, I did see that it had failed and I tried rebuilding Qt Declarative but that failed too due to it having missing dependencies on ARM for Ubuntu 14.04. Since MuseScore runs fine on Ubuntu 15.10 (and since it's a free to upgrade) I decided my time was better spent contributing in other ways. I might have another look when MuseScore 2.0.3 arrives, but ultimately, if no other programs are being packaged for 14.04 on ARM then there's not much point in packaging MuseScore for it. Hopefully we can build an AppImage that will work on 14.04 and then that will solve it for every distribution.