MuseScore Studio 4.4.4 is now available!
Hi everyone,
As work on MuseScore Studio 4.5 continues at full pace, we've prepared a small extra update in the meantime: MuseScore Studio 4.4.4.
This update brings stability improvements and bug fixes, as well as some smaller features that we felt were suitable to include in a patch.
Engraving
- All combinations of dynamics and expression text are now properly centred between staves (#25451)
- Offset applied to lyrics is now taken into account when positioning other elements around them (#25485)
Usability
- Pressing an arrow key while nothing is selected in the score will select the note or rest nearest your previous selection instead of jumping to the beginning or end of the score (#24157, #25371)
- After pressing Esc to exit fingering input, the fingering element stays selected, so that you can (for example) use the arrow keys to move it around if desired (#25413)
- Scroll wheel & scroll gestures are now solely used for scrolling, i.e. not for changing the values of sliders and knobs (e.g. in the Mixer) (#11128)
- Muse Sound libraries can have now have nested categories of sounds for easier navigation in the Mixer (#25546)
Import & export
- MusicXML: Certain score titles are no longer incorrectly identified as subtitles (#24553)
- MEI: Various fixes and minor improvements (#25557)
User interface
- Incorrect size calculations, resulting in the undo/redo buttons falling off the screen, were fixed. (#24344)
- Toolbar buttons no longer cut off after relaunch with small window size (#24344)
- Tab names (e.g. 'Home', 'Score', 'Publish', etc.) are no longer truncated when viewed in certain fonts (#25502)
- Lilypond Lyrics plugin dialog is fixed (#25482)
Miscellaneous
- Parts are now saved correctly for display on MuseScore.com
- Links to more sounds are displayed on the Home screen and Mixer
- Advanced users can now disable the creation of backup files when saving scores, via Preferences > Advanced (#14973)
Keyboard shortcuts on macOS
The following shortcuts are now working, which were broken for some users in 4.4.3:
- T shortcut for ties (#25321)
- Delete key (#25373)
- Shortcuts involving multiple modifier keys, such as Shift+Option (#25314, #24497)
Stability improvements
Crashes are fixed that used to occur when:
- Attempting to edit part scores immediately after creating a score from a custom template that contains part scores with measure numbers on every measure (#25169)
- Interacting with corrupted measures in certain very old scores imported from MuseScore 1 and 2 (#25031)
- Navigating around vertical frames using the arrow keys in horizontal continuous mode (where vertical frames are of course not visible) (#24234)
- Dragging a range selection containing guitar bends (#25424)
- Pasting notes after replacing an unpitched percussion instrument with a different instrument (#25657)
- Viewing a score after certain spanner elements have been added and then removed (#25708)
- Opening a MusicXML file that contains a
measure-layout
tag in the first measure (#25710) - Changing the tempo of a score while the Pianoteq VST plugin was loaded (#25579)
Mitigation for score file corruption
Over the years, we've received a handful of reports from Windows users about corrupted score files that contain only binary zeros, or are zero bytes in length. This could be caused by any combination of factors, including:
- MuseScore Studio's code
- Qt or other software libraries
- Windows or its filesystem (usually NTFS or FAT)
- Specific hardware or drivers
- Other software on the computer (including viruses)
- User error (e.g. overwriting a file, or unplugging a flash drive without unmounting it first)
Unfortunately, we've never been able to reproduce the problem ourselves in order to understand and fix it.
While we can't stop the problem happening, community member @krasko78 came up with a clever idea that will help to mitigate it if it does occur. According to his implementation, every time you save a file, MuseScore Studio will perform a quick check to see whether the saved file is valid. If not, a warning dialog will appear with the option to "Try again" at the same location, or "Save as..." at a new location. If this is unsuccessful then the dialog will pop up again and again until the score is successfully saved, or you choose to "Cancel".
This means MuseScore Studio 4.4.4 does everything it possibly can to protect your data from corruption. However, corruption can still occur after the file is saved for reasons that are outside of MuseScore Studio's control. As always, we recommend that you keep a backup copy of all important files in the cloud, for example via the Save to Cloud feature in MuseScore Studio.
What's next
You can install this update via MuseHub today, or via MuseScore Studio's built-in update notification in a few day's time.
If you haven't seen it yet, you may be interested in our upcoming changes to the MuseScore Studio Handbook.
Soon, we will publish a blog post about our progress on version 4.5 and beyond.
Thank you for using MuseScore Studio!
Megjegyzések
Cheers everyone,
If you need more info and/or help on the mitigation of corrupted scores, there is a dedicated thread in the "Support and bug reports" forum: https://musescore.org/en/node/372713 :)
In reply to "Community member Krasimir" … by krasko78
Thanks! I've updated the post to clarify that the dialog will keep reappearing until the score is successfully saved or the user chooses to cancel.
@shoogle wrote > Pressing an arrow key while nothing is selected in the score will restore the previous selection instead of jumping to the beginning or end of the score (#24157, #25371)
Here on MacOS 13.5.2 in MuseScore Studio 4.4.4:
• With nothing selected, pressing up arrow does not jump to the start of the score, which is good.
• Regarding "previous selection restoration" I don't see the selection restored when pressing the up arrow. I tried with a single note List selection, a multi-note List selection, and a Range Selection.
Is the new functionality supposed to work with all of those selection types?
In reply to @shoogle wrote > Pressing an… by scorster
@scorster, technically it selects the nearest note or rest to whatever was previously selected, so really it recovers your position in the score rather than the exact selection. I've updated the post to clarify this. Thanks!
In reply to @scorster, technically what… by shoogle
@shoogle wrote > really it recovers your position in the score rather than the exact selection. I've updated the post to clarify this.
With the following score state:
• A prior selection has been made
• Then I click a blank area (or press escape) to dismiss the selection
on MacOS 13.5.2, MuseScore 4.4.4, I observe the following:
After pressing the up arrow the score doesn't scroll to the area of the prior selection. Nor do I see any selection in the score—not sure if there's suppose to be one. And with subsequent up/down arrows I don't hear any transposition, again "confirming" no selection.
Can you point me to the official documentation on this behavior? Perhaps I just need to better understand the feature.
BTW, a function that restores the previous selection would be a welcomed feature. I'd like to see that!
In reply to @shoogle wrote > really it… by scorster
@scorster, sorry, I missed your reference to the up arrow key before. It's only the behaviour of the left and right arrow keys that has changed. These were the keys that used to take you to the beginning or end of the score. Now they don't. The behaviour of the up and down arrow keys has not changed.
The mitigation for empty saved files is great!
I have never suffered from the issue myself, but I can imagine how frustrating it can be.
For the anti-corruption feature—if it doesn’t work after several tries, could it create a new file with duplicate information, but do it as if copying and pasting instead of simply duplicating the file? Copy-pasting into a new score usually works…
In reply to For the anti-corruption… by Asher S.
That would be a terrible idea until musescore is able to copy paste everything, which it doesn't until now.
But, if you are able to get the new dialog telling you that save failed, and if save as still doesn't work, that would mean that you are able to reproduce the issue with a score still opened and available for debug and the devs will then be able to finally understand the root cause, so in a way that would be great.
In reply to For the anti-corruption… by Asher S.
If it does not work after a few tries, there is no guarantee it will work if the score is copied. Let's first see what people who encounter this issue will report to us over time so we (hopefully) have at least some clues as to what might be going on because right now the issue is a mystery. I myself have not seen it (luckily).
In the thread I have linked above, I have described what to do if several tries do not help: save as an "Uncompressed MuseScore folder (experimental)" - steps 6 through 13. There is a very good chance that this will work. If not, then either open your last available backup losing the latest changes - and/or - seek help here.
Can you fix this one vulnerability?
In the first step, make the musescore smaller
The second step is to drag another window to the side of the screen so that Windows expands this window
The third step is to let Windows automatically change the window size of MuseScore
Next, you'll see that musescore's taskbar isn't fully displayed (which should be correct if it could be collapsed), and there's a large blank space at the bottom of the musescore window, with the supposed mixer at the bottom moving up instead of sitting where it should be.
In reply to Can you fix this one… by Diamond20091229
This screenshot was made by following the steps above
Did the stability enhancements for this update help to resolve issues with intermittent events of MS4 failing to respond, on larger scores? I've recently encountered an issue, while using either my windows laptop, or, my windows gaming desktop (beefy hardware), where interacting with things within a larger score (for instance, my project is currently 12:45 minutes long, has 28 parts, and is almost 200 measures in length), causes the studio to freeze, windows to paint the window a translucent white color, and add the tag (not responding) at the top of the window. However, if playback was set to play, it would still play the playback accurately while not responding, and when it does come back, it just picks up with the playback bar where it was when the program wakes back up again, and continues as normal.
I also noticed that if I spend a lengthy period of time working on a singular large scale score, progressively, interaction latency becomes unbearably delayed... (ex. attempting to select a note or measure via Shift+ L click, or L click, the selection isn't selected after the command is issued for approx. 800ms - 1000ms... at times it's been even longer. Force quitting the application and reloading tends to resolve the issue, temporarily. however, the intermittent application crashes still occurred no matter how long I was in my scores. This happened across ALL of my scores, during the last build release. I'm going to do some independent testing with this new build to see if it performs any better. But I figured I'd at least make mention of the problem. It seems program related, given that it happened on both my desktop and laptop at around the same frequency.)
In reply to Did the stability… by UncleRed99
I used to have the same issue with my laptop
"Scroll wheel & scroll gestures are now solely used for scrolling, i.e. not for changing the values of sliders and knobs (e.g. in the Mixer) (#11128)"
This creates a big new problem in the mixer. For those who have a mouse wheel with a gear-like mechanism we could feel how much we were sliding the volume up and down and keep track of it in order to make precise adjustments. Now we can't. And the mixer volume value doesn't have a type-able number like the panning has. So we are completely lost about how much we increase or decrease volume in the mixer.
FYI...
I've noticed this with the previous version of Musescore and this one also, when using the application my cpu% increases about 25%, I've closed all other applications and restarted the computer, with the same result. I can end the application and the cpu% drops back down to the 5-7% range.
In reply to FYI... I've noticed this… by cshook9x9
I have seen similar in the past on systems with Muse Hub installed, but never on systems without Muse Hub.
Selecting a measure that has a dynamic marking like piano or forte and changing it to something else just puts it over the previous marking, not removing it and replacing it.
In reply to Selecting a measure that has… by Sprinkiler
I created a report, thank you: https://github.com/musescore/MuseScore/issues/25846#issue-2741040688.
Still hadn't fixed the "m" Dynamic marker? ;w;
In reply to Still hadn't fixed the "m"… by pavelowotsm55
.
In reply to Still hadn't fixed the "m"… by pavelowotsm55
If you mean the mezzo dynamic playback, it's in the list for version 4.5. See https://github.com/musescore/MuseScore/issues/25309#issue-2613881180.