missing entry "Swing" in Palette "text"

• Sep 28, 2018 - 11:40
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S5 - Suggestion
Status
closed
Regression
No
Workaround
No
Project
MuseScore

In V2 there was an entry "swing" under palette "text" for direct inserting a system text as swing attribute. It's no more present in V3. Would be nice to have it again for direct access - without first creating a system text, then set the swing attribute and the text itself...

Comments

• Sep 28, 2018 - 22:05

Yes, I agree that this was a useful feature that should still be in the text palette. It was there up until this commit a couple of months ago. I feel like leaving it commented out was probably unintentional. Can anyone confirm this so I can re-implement the swing text and submit a PR?

Reply

• Sep 29, 2018 - 08:11
Status (old) active ⇒ patch (code needs review)
Status active ⇒  

Fixed: https://github.com/musescore/MuseScore/pull/4005

What had happened was that in that same commit, one of the constructors for StaffText had been changed from a format that had the Score argument second to one that had the score argument first. The swing text was trying to be constructed from a call with the Score second, calling a constructor that didn't exist. Probably to save time, instead of fixing this, it was commented out. All I did was switch around the StaffText arguments in the one swing text call, and uncomment it.

Reply

• Oct 17, 2018 - 10:04

Maybe, on top, we should disable that swing settings tab for staff text (just like we disable the Channel change tab for system text), or does it make any sense to swing one staff but not swing the others in the system?

Reply

• Oct 18, 2018 - 09:10

Swinging one instrument against others that are straight is a real world situation; so swing should indeed remain a staff-based option.

Reply

• Nov 19, 2018 - 21:52
Status closed ⇒ active
Regression ⇒ No
Workaround ⇒ No

Actually, even though this change was made to the code, that function isn't actually used any more from what I can see, now that the new expanded workspace functionality is in place. We need to actually edit the workspaces themselves. Probably should do a once-over to make sure nothing else fell through the cracks during the time between when the workspaces were cloned for the expanded functionality and when that change was merged.

For the record, my take is that even though there are some situations where you might want, we already allow that with a little extra work by adding a staff text then changing the staff text properties manually. But by far the more common use case will be to want it to apply to the whole system, so that is how it should work by default when added from the palette.

Reply