Bug 1330240 - Wrong drawing of beams in connecting notes that wrap
Summary: Wrong drawing of beams in connecting notes that wrap
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mscore
Version: 23
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Brendan Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-25 17:30 UTC by Marco Motta
Modified: 2016-12-20 20:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 20:08:18 UTC
Type: Bug


Attachments (Terms of Use)
Patch to apply to source, adding it in mscore-2.0.1-6.fc23.src.rpm (19.15 KB, patch)
2016-04-25 17:30 UTC, Marco Motta
no flags Details | Diff
Patch to test in MuseScore 2.0.3 (for maintainer) (19.05 KB, patch)
2016-04-27 15:31 UTC, Marco Motta
no flags Details | Diff

Description Marco Motta 2016-04-25 17:30:55 UTC
Created attachment 1150565 [details]
Patch to apply to source, adding it in mscore-2.0.1-6.fc23.src.rpm

Description of problem:

Wrong drawing of beams in connecting notes that wrap

Version-Release number of selected component (if applicable):

2.0.1 (b25f81d) [mscore-2.0.1-6.fc23.x86_64]
How reproducible:

See "Steps to Reproduce"

Steps to Reproduce:

1) Write a music with eights in the last measure of a line and in the first measure of the next, in the same voice.
2) click on the first eights of the second line
3) select "Beam Properties" ("Proprietà gruppo note) from the menu at the left;
4) double-click on "Do not end a beam at this note" ("Collega gruppo note");

Actual results:

the line that join the eights ends exactly at the last eight, and the rest of the line is drawn at the first line, instead of the second one.

Expected results:

the line that join the eights must end beyond the last eighth at the first line and begin before the first eight at the second.

Additional info:

There is a patch that solve 95% of this problem (https://github.com/musescore/MuseScore/pull/2144).
Since in a group of eights with only one note at the second line the end of the beam ends just over the note stem, rather than on the steam, I made a little change to the original patch (https://github.com/pgkos/MuseScore/compare/cross-system-beaming-fix...FryderykChopin:patch-1) to solve this too.
See bug report at https://musescore.org/en/node/106826 and https://musescore.org/en/node/16278.
Until the patch is accepted or another way is found, this patch can be inserted in Fedora version

To apply the patch:
1) Save the attachment MuseScore-2.0.1-beam-multiline.patch in /home/marco/rpmbuild/SOURCES;
2) install, as root, the requires programs:
# dnf install alsa-lib-devel cmake desktop-file-utils jack-audio-connection-kit-devel pulseaudio-libs-devel libsndfile-devel portaudio-devel libvorbis-devel qt5-qtbase-devel qt5-qtdeclarative-devel qt5-qtscript-devel qt5-qttools-devel qt5-qttools-static qt5-qtquick1-devel qt5-qtsvg-devel qt5-qtxmlpatterns-devel qt5-qtwebkit-devel qtsingleapplication-devel perl doxygen fontforge fontpackages-devel t1utils tex-cm-lgc texlive texlive-metapost-bin texlive-mf2pt1-bin gcc-c++
3) download, patch and rebuild the src.rpm:
$ mkdir /tmp/MuseScorePatch
$ cd /tmp/MuseScorePatch
$ dnf download --source mscore
$ rpm2cpio mscore*.src.rpm | cpio -ivd
$ rm mscore*.src.rpm
$ mv mscore.spec ~/rpmbuild/SPECS
$ mv * ~/rpmbuild/SOURCES
$ sed -i -e "s/Patch7\(.*\)/Patch7\1\nPatch8:        $ patchBeamMultiLine.patch/g" ~/rpmbuild/SPECS/mscore.spec
$ sed -i -e "s/%patch7 -p1/%patch7 -p1\n%patch8 -p2/g" ~/rpmbuild/SPECS/mscore.spec
$ rpmbuild -v -bb --clean ~/rpmbuild/SPECS/mscore.spec
4) reinstall, as root, the patched rpm. For example, if your user is marco,
# dnf reinstall /home/marco/rpmbuild/RPMS/$(uname -m)/mscore-2.0.1-6.fc23.x86_64.rpm

Done.

N.B. Note that is missing in the spec files a BuildRequires for gcc-c++.

Comment 1 Marco Motta 2016-04-25 17:33:36 UTC
Excuse for my error, but the line
$ sed -i -e "s/Patch7\(.*\)/Patch7\1\nPatch8:        $ patchBeamMultiLine.patch/g" ~/rpmbuild/SPECS/mscore.spec

is wrong: it must be

$ sed -i -e "s/Patch7\(.*\)/Patch7\1\nPatch8:        $ MuseScore-2.0.1-beam-multiline.patch/g" ~/rpmbuild/SPECS/mscore.spec

Comment 2 Brendan Jones 2016-04-25 17:51:47 UTC
Thanks for the patch. I am just about to release 2.0.3 to testing - do you know if it is fixed there?

Comment 3 Marco Motta 2016-04-26 05:45:26 UTC
It is not fixed, neither in 2.0.3, nor in 2.1, nor anyway. The patch was not accepted in MuseScore: the status is "procrastinated" (https://github.com/musescore/MuseScore/pull/2144). But the patch works. Until it is accepted, or a different solution is found, an user is not interesting if the solution is "not very consistent with how we do anything else", but only if the patch works. Note that, in the last testing version I tried, the only solution is... not to join eights in different lines! Even Finale 2003 does it! MuseScore why not? Read the linked pages, because them should clarify many aspects of this story.

Ah, my proposed patch is the one of pgkos (https://github.com/musescore/MuseScore/pull/2144), with two minor personal changes (see too http://forum.fedoraonline.it/viewtopic.php?pid=237447#p237447):
1) if a group of eights has a single note in the second line, the beam ends on the steam, how it should be, rather than over it;
2) I slightly increased the length of beam prolong at begin and end of the group, because it seems more like the printed sheet.

Comment 4 Brendan Jones 2016-04-26 06:02:25 UTC
Thanks again, I have reviewed the bug upstream. To me it looks like it is only halfway fixed, so I'm hesitant to apply it. Besides, I will not be updating 2.0.1 anymore. This package is a nightmare as it is :)

As for upstream, I agree with there concerns that you are using a signals/slots where they do not use it elsewhere in the code base. Consistency is kind of key in an open source project. However, if they are using Qt I don't understand why they are not using this mechanism. As it stands, they are pretty tied to the framework already and using signals/slots is IMO the strength of this framework (if you can get over having to use a meta compiler)

Comment 5 Brendan Jones 2016-04-26 06:21:52 UTC
After (more carefully reading) looking at your patch it seems sound to me. Can you rebase off 2.0.3?

Comment 6 Marco Motta 2016-04-27 15:31:39 UTC
Created attachment 1151458 [details]
Patch to test in MuseScore 2.0.3 (for maintainer)

This is the patch for MuseScore 2.0.3 (MuseScore-2.0.3-beam-multiline.patch).
Note that this patch is not my work, except for some minor changes, and I tested it in 2.0.1, but not in 2.0.3. To test the patch in MuseScore 2.0.3, you must change the another 7 patch too, because the code is changed, and replacing only useScore-2.0.3-beam-multiline.patch I can't compile.

Comment 7 Marco Motta 2016-05-21 18:52:35 UTC
I applied the patch "Patch to test in MuseScore 2.0.3 (for maintainer)" to mscore-2.0.3-2.fc24.x86_64, and it works fine. But the fonts used by MuseScore 2.0.3 are wrong in some way, so that Articulations, Clefs, Key signatures, Time Signatures and other are not visible in "Palettes" (but they are visible in score). Furthermore, Tempo items show only equals and numbers, whereas notes are replaced by squares and diagonals. Also Dynamics are replaced by squares and diagonals in score.
But this is true in both original and patched mscore-2.0.3-2.fc24.x86_64. Then this patch can be applied to 2.0.3, but you must solve the font problem, before updating Musescore 2.0.1 in the repository.
Note that MuseScore-2.0.3-x86_64.AppImage shows the proper fonts.

Comment 8 Marco Motta 2016-05-21 20:35:06 UTC
The font problem is this: https://bugzilla.redhat.com/show_bug.cgi?id=1330862
When it is solved, you can apply this patch too.

Comment 9 Fedora End Of Life 2016-11-25 07:28:11 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Fedora End Of Life 2016-12-20 20:08:18 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.