[MU4 Issue] Palette selection is not honoured in new scores until Musescore is closed and restarted

[SteveBlower]

Describe the bug
If you change the palettes shown in the side bar by adding or hiding a palette and then (without closing MuseScore) create a new score or open an existing score, the new instance of MuseScore reverts to the "old" palette selection.

To Reproduce

Steps to reproduce the behavior:

1. Ensure there are no running instances of Musescore
2. Start MuseScore
3. Create a new score
4. Save the score - call it "OLD"
5. Add a palette to the side bar by clicking on the "+" and selecting a palette
6. Create a new score
7. Note that the palette added in step 5 is not shown.
8. Close all instances of MuseScore
9. Restart Musescore
10. Create a new Score
11. Note that palette added in step 5 is shown
12. Open "OLD" score created in step 4
13. Note that palette added in step 5 (after "OLD" was saved) is shown.

Expected behavior

Palette setup should be preserved when a new score (and new instance of Musescore) is created.

Palette setup should be saved with the score and used when the score is re-opened.

Screenshots
If applicable, add screenshots to help explain your problem.

Platform information
OS: Windows 10 Version 2009, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-3278824640, revision: github-musescore-musescore-abc123456

Additional context

Having created a useful set up, a user wishing to create a new score and take advantage of the new setup will be disappointed unless Musescore is closed and re-opened as otherwise that carefully crafted set up will not be used for the new score.

[MarcSabatella]

FWIW, this same basic issue affects any number of other GUI elements, like the state of the mixer etc. Not sure there is a great / clean solution, but whatever it is, it would be nice if it were applied consistently.

[bebobebo]

It is also not possible to save palettes (WIndows 11) as admin permissions are required to save into the (default) C:\Program Files\MuseScore 4\bin folder. If you save anywhere else permissible, then MuseScore doesn't look there.

There are other things affected by the inability to save a palette - e.g. renaming a palette, Closing and re-opening Musescore does not show any of the customisations made before closing.

[bebobebo]

PS this bug should be renamed with the correct spelling of "palette" so that is can be found via search.

A "pallet" is a wooden tray for moving goods.

[MarcSabatella]

I'm not sure what you mean. MuseScore doesn't look for palettes at all. Saving them is for your own personal use, such as to then load into another workspace or another system or whatever. You can save them wherever you like for this purpose.

[MarcSabatella]

I can confirm, though, that name changes (made via the palette properties under "...") are not saved, unless you also change the the content of the palette. This presumably has nothing to do with permissions - certainly nothing to do with saving the palette separately, since the palette would be saved as part of the workspace. I assume the code to decide when a workspace is worth saving isn't smart enough to recognize a name change as making the workspace "dirty".

[bebobebo]

I had assumed that the name was a display property of the palette, not a renaming of a palette file until I found that it was one of many customisations that doesn't dirty the workspace to get the change saved. Since it's a renaming that changes the entire palette, this should be distinguished from other Properties.

I also assumed Musescore auto-loaded such user customisations the same way other programs I use do. I did not experiment with this in v3, but given the massive changes to behaviour in v4, I wouldn't assume replication of v3 behaviours.

I found a thread that suggested that Musecore saved palettes into the user's roaming Appdata folder but that doesn't happen in v4 - it sends you to the C:\Program Files\MuseScore 4\bin instead. The documentation is very thin https://musescore.org/en/handbook/4/palettes#save-load-palettes

[MarcSabatella]

I think you are still misunderstanding how this works. Of course MuseScore normally remembers your customizations - it's just that this has nothing to do with the completely separate and completely optional action of also saving a copy of your customizations to an XML file for purposes other than the automatic tracking of changes. You should never need to "save" these customization at all, except for the specific purposes I mentioned (copying them to other computer, etc). Everything else should be completely automatic. There is just that limitation that currently, as I mentioned, name changes don't trigger this automatic remembering unless also accompanied by another change. This has absolutely nothing whatsoever to do with saving or loading palettes, absolutely nothing whatsoever to do with the permissions on the folder you mention.

I recommend starting a new thread in the Support forum if you have continued questions about how palette customization works.

[bebobebo]

I added this because a thread in the support forum directed me here.

Of course MuseScore (4) normally remembers your customizations" except it doesn't, because nothing is "normal" between all the undocumented MS4 feature changes and the partly-documented bugs. There are so many palette changes that aren't remembered in addition to display name property. It's just that there seems to be additional design and implementation bugs of having changing display names have the unfortunate side effect of requiring a palette file rename, and then the additional bug of MS directing me to a non-editable folder. The bugs just pile up.

[MarcSabatella]

As I said, if you have further questions, please start a thread on the Support forum to ask. There may indeed be bugs, but also, as mentioned, it seems you are simply misunderstanding something. So let's use the forum to clear up the misunderstandings, to avoid cluttering the issue trackers with support discussions. Then, if as the result of the support discussions, it turns out there are new additional bugs to report (things that are not simply misunderstandings), then you can open a new issue to report those.

[bebobebo]

You chose to respond to me here rather than on the Support forum....

[MarcSabatella]

I monitor the issue tracker more closely. Please keep support discussions in the forum, and keep the GitHub issue tracker focused on confirmed bugs. Otherwise it makes it unnecessarily hard for the developers to follow the steps to reproduce the bug. We all have the same goal - to make MsueScore better. That is why these procedures are in place, so please honor them.

[jacekgajek]

I'd like to mention that it's also not honoured in already opened scores if multiple scores are opened.

Steps to reproduce the behavior

1. Open two (or more) scores S1 and S2,
2. Customize a palette in a window with S1

Expected behavior
A pallette can be used in S2

Actual behavior
A pallette in the window with S2 open is not customized

This becomes a problem when many (eg 20) scores are open and some of them edited, because reopening MS forces user to save and also deletes all undo/redo history.

I didn't check but I guess this applies to all changes to global preferences because each scores is opened in a separate instance. Chromium browsers somehow mange global preferences and single user interface while still having seperate processes for tabs so it IS possible.

[bkunda]

Also relevant: #16660

[wizofaus]

Just been struggling with this myself, but for me I very typically have multiple MuseScore instances running at once, and I'm having a hard time getting it to save/remember my palette customizations at all, or to discern an obvious pattern in when it does and doesn't work.
I would think that palette customizations should be a) saved instantly at the moment you make them b) should never be overwritten by other instances that haven't loaded those customizations yet (certainly in the case that no changes have been made to the palette configuration in those instances!). Perhaps might even be worth having them sync'd automatically between all running instances (using the same workspace).