Items disappear from palettes after being inserted into a score multiple times
S3 - Major
Insert a certain palette item such as a dynamic like "ff" or an articulation like "Marcato-staccato above" or a "Rehearsal mark" multiple times into a score. After a half-dozen or so insertions, the item disappears from the palette. By "disappear" I mean it is no longer visible, and the space it occupied is now blank. Hovering over or clicking on the blank space does nothing. No further insertions of this item into the score are possible.
The item can be restored by hiding the palette that contains it, then adding that palette again. However, the item will disappear again if the above causative steps are repeated.
Attached screen shot shows the Articulations palette with the "Marcato-staccato above" symbol missing.
|Screen Shot 2023-01-11 at 1.24.09 PM.png||38.4 KB|
I assume you are using drag&drop instead of simply clicking the marking? This does seem to happen on rare occasions, but so far no one has found precise steps to reproduce the problem. In any event, it is easily solved by just clicking instead of dragging which of more efficient anyhow both because you don't need to drag, and because you can apply to multiple notes at once). Also, if it ever does occur again, an easer fix is to reset the palette from its "..." menu.
In reply to (No subject) by Jojo-Schmitz
I have this issue as well. Even if it is minor, please fix it because it is still a glitch after all.
(Ignore the workaround yes -> no, im new to forums)
(no workaround is mentioned, so that change seems OK)
The workaround is to reset the palette, or remove/re-add it, or restart MuseScore. Or to use click instead of drag & drop, which is more efficient and more powerful anyhow.
Anyhow, indeed, it would be great to be able to ti fix this, but it's still the case that no one has been able to produce precise steps to reproduce the problem. As soon as someone is able to do that, then it can be reported on GitHub where the developers can begin investigating and hopefully fixing it.
In reply to The workaround is to reset… by Marc Sabatella
Thanks for the info and comments, Marc. In case it might be related to my computer configuration:
OS: macOS 12.6, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223472200, revision: 5485621
Mac Pro 2013 ("trash can" model).
Processor: 3.5 GHz 6-Core Intel Xeon E5
Memory: 32 GB 1866 MHz DDR3 (8 GB x 4)
Graphics: AMD FirePro D500 3GB
Display: Apple LED Cinema Display, 27-inch (2560 x 1440)
Thanks for the info! But, I think it's not related to configuration, at least not completely, because I think many of us with very different configurations have seen it from time to time - we just don't know yet how to reproduce it on command.
Based on some prior investigation of this and some knowledge of how the code was structured in MU3, I think it's most like about the specific timing and motion of the drag operation. When you first start a drag, MuseScore assumes you are trying to customize your palette, because normally that's the only reason you would ever drag anything in the palette. So it starts rearranging the palette as you drag. But as soon as your mouse leaves the palette area, it suddenly realizes you aren't trying to customize the palette at all, but are actually using drag & drop to add elements to your score. At that point it attempts to restore the palette back the way it was. And somehow that is what is not working right.
So the bug is probably triggered pretty specific about the way in which you are dragging - like whether the drag moves through different rows of the or columns of the current palette, whether you change direction in the middle of the drag, whether at any point the dragged element passes through another palette on the way to your score, etc. Some specific type of palette customization that is performed during the drag that for whatever reason isn't restored properly when you leave the palette panel.
Probably the simplest fix would be just to disable drag & drop to the score since it hasn't been needed for years and as mentioned is less powerful than simply clicking and less efficient as well. But, I realize some people are still accustomed to doing this.
Great explanation, thank you. As a fairly recent user of MuseScore, I just got used to dragging and dropping, but after reading your initial suggestions about just selecting the event in the score, then clicking in the palette, I agree that the latter is more efficient, and thus I would support the elimination of the "drag out of the palette and drop into the score" functionality. But the MuseScore team would have to assess how much of the longer-term user base would be negatively affected by doing that. If a lot of people have been dragging and dropping, I'm surprised the disappearing palette item issue has not been previously reported!
It's not a really serious suggestion. The obvious downside is, people would try to drag & drop and end up messing up their palettes. And we'd get tons of complaints about removing something for no good reason.
But for the record, the disappearing palette item has been reported a number of times over the years, sometimes here in the issue tracker, sometimes on the forum, sometimes on social media. We managed to find one specific reproducible case a couple of years ago and fixed that (I think it had to do with how long you waited between the point where you clicked and the point where you started the drag), but still reports come in maybe once every few months. Just nothing reproducible yet.
To be clear, in addition to being more efficient, the real advantage of clicking to add palette items is that you can add an item to multiple elements at once - eg, dynamics across all staves, tenuto-accent to multiple notes, or a volta across several measures.
In reply to It's not a really serious… by Marc Sabatella
I can make it happen any time. Click on a palette item and almost immediately do a fairly rapid drag onto the score element until I see a "+" sign, then release. Haven't tried it with that many palette elements but have done it reproducibly with articulations and dynamics. If it would help, I guess I could do a video...
I also have this happen fairly frequently on drag and drop. It is very inconsistent on my win 0 3.6.
I, too, am having the same issue.
I can consistently reproduce the issue by dragging the element from the toolbar very quickly ("too quickly"). Seems to have to be quick enough to prevent the element from being repositioned within the toolbar's grid. It only seems to affect the first element selected (see attached images), as I can't seem to make it happen to two elements within the same toolbar group. I believe the issue is related to the fact that the "enable editing" option is selected by default when you click on the "..." in its menu (see image). If I deselect the "enable editing" option, then the elements do not disappear. Perhaps the best solution would be to default all options to deselected. Is there a way to change this behavior globally and save it as a default setting so that we don't have to reset each toolbar menu?
I have always changed the key and time signatures using the drag-and-drop method. I honestly didn't realize I could just select the measure and click the markings - I will try to get used to doing that now. The workarounds are either (1) deactivate the "enable editing" option from the "..." palette's menu or (2) to simply click on the element in the toolbar instead of drag-and-drop.
This glitch is a bit frustrating as I developed the (bad?) habit of dragging the element to the measure instead of clicking. If there is a way for us to change the default behavior on loading (to have "enable editing" deselected by default), please let me know.