Is it a bug or not?

• Feb 19, 2021 - 13:06

With all the improvements of Musescore 3.6, which I really appreciate, there is, what I'd call a nasty bug.
When creating a new score, so far Musescore offers no way to set "swing"-settings. You have to add it afterwards. That's O.K! However, when I save my individual style settings (with the "swing" attribute), and later on reload it to a new score, the "swing" is automatically set to "on". But the "swing" attribute is not shown, despite it is active. From mere looking at the score, it looks like a "straight" setting. No great problem with a new score, for you realize it when listening for the first time to what you have input.
I saved my personal new 3.6 style settings (with "swing") and later applied it to older scores prior to 3.6, which so far had a straight attribute (actually it means: no attribute at all was to be seen, neither "straight" nor "swing"). Only after re-uploading some scores withe the adapted 3.6 style-setting, I noticed by chance, that they suddenly replayed in "swing", which spoiled the tune.
As I wasn't aware of that issue I had saved the new style settings without naming the style file as "with swing" and when applying it to the older scores I was not conscious of every single individual setting that was contained. I was in good believe, the style still would be "straight", as nothing other did show up.
That's no coherent behaviour! If Musecore with standard-setting from the very beginning applies a "straight" style without explicit indication and applies a "swing" style only when explicitly assigning it to a note, then I expect the same behaviour with a saved style setting. That means when a loaded style set contains a "swing" style with the first note it has to be explicitly shown above this note!!!
Moreover, there is no possibility to set neither the "swing" nor the "straight" attribute in the style dialogue, it only can be done by explicitly assigning the respective attributes from the text palette. Therefore it would be ok, too, if the "swing" attribute would never be saved with the settings at all. Either so or the other way. But not as it momentarily is the case.
Please do correct this quickly. it is a nasty trap other users may tread into, too.


Comments

In reply to by Mr Fox

@Mr Fox
Thank you! I was looking for that twice but indeed missed it - probably because in the German-style dialogue it is right at the bottom of it almost outside the visible part. My fault, sorry. At least it makes it easy to heal the situation. That part of my next comment (which I wrote before recognizing your hint) may, therefore, be unjustified.
But it does not reduce the faulty behavior (in my opinion) that the "swing" settings are saved and again applied when reloading without explicitly indicating that "swing" is set to "on" whereas the "straight" setting (swing=off), when saved, and reloaded afterwards does not apply.
If there exist two possible states/modes, it has to become clear which one is valid! A convention may be that one of them is "default" and therefore isn't indicated explicitly. But the other state /mode has to be explicitly pointed to!
Imagine a musician has only a PDF output of a score and cannot check by listening to Musescore replaying the score. He will play it wrong. Or - vice versa - he plays it correctly from the PDF but gets irritated after listening to Musescore replaying it in "swing" mode without indication!

Worse still, once I have applied an individual style setting (with "jazz" attribute, that, however, does not show up) and "swing" mode has become active undesirably, I can only heal the situation by explicitly assigning "straight" to the very first note. Then I saved the style settings anew while naming the style file as "straight".
Afterwards, I reloaded the straight settings to a score that erroneously had become "swing". Again, no attribute showed up, neither "swing" nor "straight"! But the "swing" mode WAS NOT reset to "straight" as expected. It stayed in "swing" mode. Obviously, in this case (with a "straight" setting) these mode-settings have not been saved The only way to get rid of that "swing" now is to explicitly apply the "straight" attribute from the text palette to the first note. That is not acceptable.
By the way, but that's not so important, prior to 3.6 there was with a german language setting there was a german name "gerade" for the "straight" attribute, too.
Again: As style settings prior to version 3.6 cannot be applied any longer, everyone who works with different style settings has to save his personal preferences anew and hence is prone to falling into that trap.

The described behavior has been tested with the following environment:
Musescore OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34

Attachment Size
MuseMG36.mss 60.96 KB
MuseMG36-straight.mss 60.96 KB

As the handbook describes there are 2 ways to set swing, one with a Swing text (unset with Straight), and another to do it globally, as a score style setting, (only) the latter saves (resp. gets taken from ) a template, and indeed is invisble, as it is a score style setting.

(Translating "Straight" as "Gerade" was a mistake, "Swing" is not translated either and really shouldn't be)

The settings in both your .mss files are:

    <swingRatio>62</swingRatio>
    <swingUnit>eighth</swingUnit>

You'd need to get rid of it in MuseMG36Straight.mss

Actually it is just one of those, swing:

    <swingUnit>eighth</swingUnit>

straight, either:

    <swingUnit></swingUnit>

or none

In reply to by Jojo-Schmitz

@Jojo-Schmitz
Thank you, too. I did as you advised and it worked. Then I did some systematical testing in order to find out what initially went wrong with my saved style settings.
Now I must admit that Musescore is consequent in saving all the global style settings, the swing/straight mode inclusively, but nothing else.
I created two simple scores with some eighth notes and swing set to off globally in the one score and set to on globally in the other score. Therefrom I saved 2 basic style settings. Then I explicitly assigned to the first note in both scores the reciprocal attribute, saved the style settings of both before saving the whole score. After reloading both scores I again saved the style settings. All 3 respectively 6 setting-files show the same settings, i. e. when swing was "off" initially, the XML-tag remained empty disregarding any explicitly assigned attribute.

The same is true when the swing was set "on" globally. It remained fille in all 3 cases.
eighth
There must have been a bug in that regard between versions 3.6 and 3.6.2. With the former, I created the "wrongly working" settings-file, with the latter I tested. I would admit mistakes on my side, but I know that I never manipulated swing settings via global style dialog - so far I even did not realize that such a possibility existed. Therefore I have no other explanation for the settings saved with 3.6 containing a swing=on setting. There was, at best, a swing attribute explicitly assigned to the first note at that score where I saved the settings from. But that should not have been reflected - according to my present tests - in the settings file.
However, this consideration is only for soothing my mind and is irrelevant to the issue. The present version of Musescore works correctly and I have to withdraw my posting (gnashing my teeth) and apologize for the fuss.

In reply to by archer533

Only thing I can guess is you were working a score created by someone else that had this turned on. Or perhaps a score created by you from a template created by someone else. Anyhow, there were certainly bugs fixed between 3.6.0 and 3.6.0, like one where if you saved a score switch swing on in in the score but off in the parts, swing might turn itself on in the parts upon reload. But there has never been any bug resulting in swing magically turning itself on in a score where it wasn't on at all ever. Another common mistake is to add Swing text from the palette because you want some bold text, and then change it to read what you want it to read, not realizing it affects playback.

Do you still have an unanswered question? Please log in first to post your question.