Enormously Long Stems when Using Beams in GNU/Linux ARM

The key is the fact your are on ARM I believe.
Something is probably wrong in the method to compute the stem length
https://github.com/musescore/MuseScore/blob/dbd9e842d43104fd3be6f919199… (which is not the easiest one in MuseScore...)

See https://musescore.org/en/node/88691 for a more in-depth report.

Does it happen for new scores as well? Or only existing scores made on x86?

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.

OK let me try to be more useful then ;)
I can't compile on ARM but if I could, my first test would be to convert these two char into signed char here

https://github.com/musescore/MuseScore/blob/dbd9e842d43104fd3be6f919199…

since ARM chars are unsigned by default. We found it already here https://musescore.org/en/node/73701 https://github.com/musescore/MuseScore/pull/2171

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...

Has that PR of mine made its way into the 2.0.3 branch yet?

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)

DISREGARD...actually lasconic suggestion #6 fixed the beams!

update: lasconic's suggestion #6 https://musescore.org/en/node/95951#comment-425181 did not seem to fix the long beams.

I'll try some more as suggested by Jojo.

Jojo, yes your commit is in 2.0.3 too https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/clef.h#L95

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.

Awesome! Do you make a PR? Or you want me to commit this?

I'll make PR now... (I want the star).

And this is why I'm on a 'holy war' to get compiler warnings fixed since quite awhile ;-)

I made PR: https://github.com/musescore/MuseScore/pull/2366

It simply changes those two chars to signed chars.

I don't know how to make a test for this issue, considering that the Travis builds on x86-64 machine would not catch it anyway.

:) Feel free to look through my .txt of ARM compiler output and suggest to me any specific ARM things I should look at.

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.

Fixed in branch master, commit e56717e255

fix #95951 use signed chars for BeamMetric to fix ARM type limit issue causing long stems

Fixed in branch master, commit 92f915372a

Merge pull request #2366 from ericfont/95951-long-stems-ARM

fix #95951 use signed chars for BeamMetric to fix ARM type limit issue causing long stems

Fixed in branch 2.0.3, commit 1da2c07146

fix #95951 use signed chars for BeamMetric to fix ARM type limit issue causing long stems

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.

Maybe checking all these warnings leeds to the culprit...

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 ;-)

1) it is fixed in the sources and every one can get it from there, for free.
2) yes
3) see the developers' handbook

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:

https://efjz.in/index.php/s/c1cDsReQhx8xKe4

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? ;)

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.

shoogle, I noticed that your launchpad 2.0.2 armhf build failed because "Missing build dependencies: qtdeclarative5-dev (>= 5.3)". Just bringing that to your attention in case you didn't notice.

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

Those warnings reg. struct MidiMapping shouldn't be related to slurs and other lines looking 'funny'.

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.

Ah, OK, sorry for missunderstanding

@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.

Automatically closed -- issue fixed for 2 weeks with no activity.