Tuplet font size issue from score to part(s)
This has been an issue for at least the last 3 updates (Mac). When I create part(s) the tuplet font reduces in size rendering it virtually unreadable. The only "fix" is to eliminate the tuplet on the part and re-enter it. But that turns the font in the score to almost double. It has to be a coding issue, but it's driving me nuts!!
Comments
BTW, the notes of the tuplet remain the correct size font. Is anyone else having this issue?
Which 3 updates? Are you by chance talking about commits to or delete development build an of the master branch?
In reply to Which 3 updates? Are you by… by Jojo-Schmitz
Truthfully, I'm not certain. I'm running 2.1.0 - Revision 871c8ce. And...I had an upgrade issue on this Mac necessitating a High Sierra re-install: 10.13.3. But this glitch has been around (on my system, at least) for roughly a year. I have been upgrading regularly to non-beta versions. Thanks for responding. I do a LOT of writing; so this gremlin just gets nastier....
In reply to Truthfully, I'm not certain… by pn.rawlins@gmail.com
And...the tuplet rendered on the parts can't be edited. I've tried to change the font size in Style/Text in the part, and nothing happens...
In reply to Truthfully, I'm not certain… by pn.rawlins@gmail.com
So it is 2.1, 2.0.3.1 and 2.0.3 I guess
Tried the 2.2RC already?
In reply to So it is 2.1, 2.0.3.1 and 2… by Jojo-Schmitz
I haven't downloaded 2.2RC yet, but I used 2.2 build OS: Windows , Arch.: x86_64, MuseScore version (32-bit): 2.2.0, revision: 5f6b17b which is about a 10 days old.
Edited:
I just did a quick test on a string quartet I am currently working on.
When I extract part the numbers are small, but when I enter tuplets after the parts are extracted, the numbers are normal sized. I'm working on recreating the problem but I can't figure out what is triggering this. When I create another simple quartet, there are not small numbers.
Workaround: In the part, select the measure(s) with a small tuplet number then cut and paste without clicking anything else and the proper tuplet numbers will be displayed. Note: you cannot copy and paste because MuseScore will give you an error if you attempt to paste into a measure with a tuplet.
In reply to I just did a quick test and… by mike320
I've figured out "workarounds"; but this issue raised it's ugly head after the release of 2.0. I wrote a 40 tune score for a Christmas musical from July - December last year, and did a LOT of cussing.
In reply to I've figured out … by pn.rawlins@gmail.com
Unfortunately if the issue were fixed today it would not likely make it into version 2.2 when it is released in about 10 days. The release candidate is named only to assure bugs that are claimed to be fixed really are, new fixes are extremely unlikely to be included. Having said all of that, I will enter a bug report so the issue can be fixed and hopefully be included in the release after 2.2.
There is another workaround that I alluded to that can be less than ideal in large scores. Extract the parts before you enter the score. The only drawback to this is that it will slowdown MuseScore's response and on some systems, including mine, will eventually become so slow that it is unacceptable. This happens on some large orchestral scores without the parts being extracted already.
The reason the issue became evident in 2.0 is that the tuplet code was completely rewritten for version 2.0 and no one said anything in all of these years. I am included in those who are guilty of seeing it and not saying anything. When I noticed it I was doing other things and did not think to make a bug report.
In reply to Unfortunately if the issue… by mike320
Well, now we're all aware. I'm guilty of not saying anything (with the exception of yelling loudly @ my Mac). And for the record, I really appreciate all you guys do. I have probably 100 students (including college level) who are not only users, but major fans!!
In reply to Unfortunately if the issue… by mike320
There are problems with a workaround. In my string quartet I am working on, when I use the cut + paste method for fixing the tuplet number in the part, the tuplet number in the score becomes large and roams (moves somewhere else in the score). Clicking the roaming 3 and pressing ctrl+r to return it to it's place keeps the numbers large. Using the cut + paste method to return the numbers to normal also returns the numbers in the part to small. It seems at this point the only good workaround is to extract parts before entering the score. I'm still trying to figure out what in the score triggers this change in displays for the tuplets in parts. I have added several items and cannot reproduce the problem from scratch. I'm still working on it and will continue to make notes here until I'm ready to submit the bug report.
Here is a picture of a score with the frame that holds the title reduced in size.
![Tuplet numbers 1.png]( "Tuplet numbers 1.png")
Notice the tuplet numbers on a couple are moved. (they hidden by the tuplet). This is only the first instrument in the score.
See what happens when I look at all of the other instruments in the score.
![Tuplet numbers 2.png]( "Tuplet numbers 2.png")
Notice that all of the tuplet numbers on the first system are moved. Take my word that all of the other systems are OK.
In reply to Here is a picture of a score… by mike320
"When I create part(s) the tuplet font reduces in size rendering it virtually unreadable."
It's needed that you attach a score showing this.
In reply to "When I create part(s) the… by cadiz1
@Cadiz1, I have a score that shows this. It's 261KB in size to it's too big for a programmer to go through, but maybe you can figure out why it happens. It starts in measure 86 of Violin II. I can't seem to recreate the problem from scratch.
In reply to @Cadiz1, I have a score that… by mike320
What is exactly the problem in measure 86 of Violin II?
At the same time, the first message was about "When I create part(s) the tuplet font reduces in size rendering it virtually unreadable."
And in your previous comment, you "notice the tuplet numbers on a couple are moved. (they hidden by the tuplet)"
All that goes in all directions, and I would be curious first to go back to the beginning with the first report of reduced size of the tuplets virtually unreadable in parts.
In reply to What is exactly the problem… by cadiz1
If you look at the part on Violin II you will see that the 3 in the tuplet is much smaller than on the score with all the parts like in pn.rawlins@gmail.com's picture. If you cut and paste that measure in the port you will see that the 3 becomes the same size as in the score.
As far as the tuplet number moving, I was trying to create the problem from scratch. Among the tests I did was to make changes to the title frame, since none of the other changes I made to the staff were causing it. The only thing I could make happen was for some of the tuplets to move in the parts when I adjusted the title from in the main score. As I said in a previous post, I was using this post to make notes on what I was trying along with the results. Perhaps someone else will try something similar but different and be able to recreate the problem. Perhaps this info will help a programmer figure out what's happening.
What I didn't yet mention is that reason I was adjusting the title frame is because of this conversation: https://musescore.org/en/node/270358
In reply to "When I create part(s) the… by cadiz1
I'm attaching 2 screenshots showing the same spot in the score before and after the part conversion. Although this section is legible, I have several scores containing "busy" sax section lines where legibility is questionable at best. As stated earlier, the tuplet indicator (once the part is rendered) is uneditable as well.
In reply to I'm attaching 2 screenshots… by pn.rawlins@gmail.com
Thanks, but images are not really useful. The real score would be. Attach the score is necessary for testing and understanding what going on.
In reply to Images are not really useful… by cadiz1
OK...I've attached the score (including a test part) containing the screen shots I just sent. Hopefully this helps.
In reply to OK...I've attached the score… by pn.rawlins@gmail.com
Ok, so I think you observe this: when creating parts, the tuplet (its number/bracket) adopts the scaling of the main score (eg 1.000mm).
In part, the default scaling is 1.764mm. And so, the size of the tuplet number doesn't correspond with its "environment", notes, and others. Hence this discrepancy of the display in the parts between notes vs. tuplets numbers/brackets.
But the scaling ot this tuplet number reverts correct after save, close and reload the score.
Concretely: your score without parts: You'veGot, without parts.mscz
(in Layout/Page Settings/Scaling Staff space, the value is 1.000mm):
1) Create parts -> New all -> Ok
![alto.jpg]( "alto.jpg")
![alto1.jpg]( "alto1.jpg")
Result: eg in first part, Alto Sax, B rehearsal mark, you see this (so a "reduced size" of the tuplet number/bracket, while in part the scaling is 1.764)
But after save the score with the parts, it's now correct, as expected: You'veGot, with parts after save.mscz
Exactly the same behaviour in the reverse case. From scratch.
![Soprano tuplet.jpg]( "Soprano tuplet.jpg")
![part save.jpg]( "part save.jpg")
1) SATB template, with "big" scaling in main score ie, 3,564: SATB triplet.mscz
2) Create parts -> New all -> Ok
Result in Soprano part: a "big" size of the tuplet number.
3) Save/Close and reload the score:
1SATB triplet.mscz
Result: the tuplet returns to the 1.764mm scaling as expected in part.
I don't know if this behavior was already reported? (Probably, but I don't remember)
NB: and so, when you say, "the only "fix" is to eliminate the tuplet on the part and re-enter it", it's because when you re-enter the tuplet in part, its scaling is the one of the part (eg 1.764) and no more the scaling of the main score.
So, prefer first to save the score (less time consuming) :)
In reply to Ok, so I think you observe… by cadiz1
I have done exactly as you suggested more than a lot. On this end of the planet, that "fix" hasn't worked here. I just re-accomplished the same procedure with the same result.
In reply to I have done exactly as you… by pn.rawlins@gmail.com
Steps:
1) Load your attached file
2) Create parts -> New all -> Ok
At this step, the tuplets in parts appear (eg in Sax instruments) in a "reduced size."
3) Save your score -> Close -> Reload
Result: as expected now in parts
Same result with Windows7/10 here, and with various versions R.C 2.2, 2.1, 2.0.3 and so on.
Reproducible as shown previously from a blank score.
And from what I see, it's a very former issue/behaviour.
In reply to Steps:… by cadiz1
After some search, I see a thread - maybe others - with similar described results (in the attached file, "Crescend Moon Dance", the scaling in main score is 0,650mm, and so, after creating parts, due to this issue, the tuplets numbers are "super small")
https://musescore.org/en/node/155201
But as far I know, it is not reported in the Issue Tracker. Done soon.
In reply to After some search, I see a… by cadiz1
Issue submitted: #270476: Tuplets numbers, when creating parts, obey first to the scaling in main score instead of the default parts scaling
In reply to Steps:… by cadiz1
OK, you win!! (and so do I). This is a fresh day, and I just took the score from which you extracted all the parts. I deleted all the parts...saved...and closed (and quit MuseScore). ...reopened MS, loaded the sore, created parts (New All)...saved, exited MS...reopened...and voila!! My (normal?) procedure has/had been to immediately edit the parts, rather than to exit and reopen. I thank you for the time...and the solution!!!