MuseScore Studio 4.4.2 is now available!
Hi everyone,
We're pleased to announce that MuseScore Studio 4.4.2 is now available. This update addresses stability issues, fixes a problem with MuseScore Studio's online functionality, improves playback quality especially on less powerful computers, and includes several other enhancements and fixes in various areas.
Online functionality & MuseScore.com
- Some users reported that MuseScore Studio 4.4 was unable to connect to the internet and that they could not log in to their MuseScore.com and Audio.com accounts. This has been resolved.
- This update includes changes that facilitate a fix for the "Send to YouTube" feature on MuseScore.com.
Stability improvements
- A crash has been fixed that occurred when opening a score containing a rest beamed together with the next two notes
- A crash and a corruption that occurred when changing the actual length of a measure have been fixed
- A crash when hiding staves with lyrics has been fixed
- A crash when closing a score under specific circumstances has been solved
- A problem that caused all parts of the UI to be detached from the main window, sometimes resulting in crashes upon further interaction, is now prevented
Engraving and score interaction fixes
- You can now drag multiple hairpins at the same time to move them around
- Dynamics can now smoothly be dragged across barlines again
- Dragging dynamics or expression text no longer affects adjoining hairpins when snapping has been turned off
- Vertical centering of dynamics no longer interferes with harp pedal diagrams
- Layout issues related to the 'Combine with voices that share the same stem direction' property have been fixed
- Repositioning images by dragging them with the mouse works again
- Joining measures no longer causes certain elements to be shifted or lost
- Undoing after joining measures no longer results in unexpected behaviour
- Beams no longer (dis)appear unexpectedly under specific circumstances in continuous view
- No unexpectedly large brackets/braces appear anymore when deleting staves under certain circumstances
Playback fixes & improvements
- The audio engine has been further tweaked, improving performance on all devices but especially on less powerful hardware (note: to get the most out of this, you need the latest version of MuseSampler, which is the engine behind Muse Sounds. To receive the latest version, close MuseScore Studio and then open Muse Hub, which will install the update in the background.)
- Pedal playback for VST has been fixed
- An issue involving tempo markings and measures with a reduced duration has been fixed
- Metronome markings containing 'c.' (in the meaning of 'circa') after the '=' sign are now also accepted; thanks @pacebes for your contribution!
- Preview playback of chord symbols just after entering them is back again
- You'll hear no more unexpected portamento effects when clicking on notes to preview their sound
- In MuseScore Studio 4.4, the 'Solo' button for the metronome track was intentionally removed. However, for existing scores where the metronome track was already solo'ed, this meant that it couldn't be unsolo'ed again, leaving all other channels stuck in silence. In MuseScore Studio 4.4.2, such scores are now automatically fixed.
Miscellaneous fixes
- Chord symbols are now exported to MIDI again
- The state of the Loop button in the playback panel correctly updates again when opening a different score
- When running the AppImage on Linux, the app name and icon are correctly recognised again
- In the Properties panel for fretboard diagrams, hovering the preview diagram no longer results in the fingerings disappearing
- MuseScore Studio 4.4 contained a fix that prevented chord symbols to be rendered wrongly in scores with custom chords XML files after saving and reopening such scores. Version 4.4.2 goes a step further, by also automatically fixing scores from older versions when opening them.
For even more detail, see the MuseScore Studio 4.4.2 project on GitHub.
With thanks to everyone who constructively helped us identifying and resolving these issues!
A look into the future
We are planning to release one more version in the 4.4 series, namely 4.4.3, which will available in a couple of weeks. This update will mainly bring more bug fixes, but we might include some small new features as well. After that, we will focus on the development of MuseScore Studio 4.5, which will bring a long-awaited overhaul to the percussion input flow, among other things. Stay tuned!
Comments
Now available via Muse Hub
In reply to Now available via Muse Hub by Jojo-Schmitz
Thank You !
Congratulations on the new release!
While there seems to be much anticipation of the changes coming to percussion input flow, I can't find any description of them other than that they are being "improved". Is there more information on these planned changes available somewhere?
For example, I'm trying to understand if the mapping of percussion instruments (such as drumkit) to different VSTs is being addressed. Today, moving to a different VST for drums can require edits to the drum part (since the MIDI notes used by drumkits isn't always the same). Will the new percussion system include "look-up" functionality, so when I enter a note for "hi-hat" it will always play that way as I move to different drumkit VSTs?
In reply to Congratulations on the new… by mdeluca
A VST drum kit that uses a mapping other than general MIDI is outside our control
Sound libraries in the Muse Hub are in our control and can be mapped to "play nice" with eachother for easy switching.
There are long-term potential improvements to this (possibly via a database of known VSTs and their sounds/instrument/technique mapping) but that is in the more distant future.
In reply to When a VST drum kit that… by Zac
Understand. So I assume this means that 4.5 will reconcile open / closed hi-hat between Musesounds and MS Basic. (Today, Musesounds uses an articulation to show open, but MS Basic uses a different note). Does this also mean that the MIDI mapping for open hi-hat in the Musesounds drumkit will be fixed in 4.5? Today, you get this by entering "hi-hat" and adding the "open" articulation. But when exporting MIDI, open and closed both export as MIDI note 42, so there is no distinction between them.
And to my original question, is there a place where these plans are documented?
In reply to Understand. So I assume this… by mdeluca
No, the plans are are still a bit generalized.
The advantage of MuseSounds is that it doesn't need a different midi-pitch to change the open-ness of a hi-hat. This could be good or bad depending on what you want to do, but the midi pitch that gets written is what gets sent out.
A legacy MIDI open hi-hat might be a good idea for import-export purposes
In reply to No, the plans are are still… by Zac
@ mdeluca wrote
> Does this also means that the MIDI mapping for open hi-hat in the Musesounds drumkit will be fixed in 4.5? Today, you get this by entering "hi-hat" and adding the "open" articulation. But when exporting MIDI, open and closed both export as MIDI note 42, so there is no distinction between them.
@Zac wrote
> A legacy MIDI open hi-hat might be a good idea for import-export purposes
Ya think?
Just seems odd that MuseScore has such a predilection to sidestep MIDI.
People have grown accustomed to MIDI since it started working with instruments about 40 years ago.
"Legacy" hi-hat?
In reply to No, the plans are are still… by Zac
Thanks @zac for this information. If I understand your note correctly, this means that means composers need to choose between two competing options when writing for hi-hat - the "standard" way that historically has been supported (with different MIDI notes for open and closed), vs the "new MuseSounds" way that is not currently backward compatible.
If I write a part for any other instrument (violin, trumpet, etc.) I have assurance that I can easily switch between MuseSounds and any other VST and retain the notes I put in. But when writing for hi-hat in a drum kit, it seems I now need to choose whether to keep the part compatible with all other VSTs, or write exclusively for MuseSounds. If this is correct, I have trouble seeing how I would use the MuseSounds drum kit with any regularity.
For reference, this is entered as a bug in GitHub at https://github.com/musescore/MuseScore/issues/24669
Is there something I'm misunderstanding here?
In reply to Thanks for this information… by mdeluca
@mdeluca wrote
> when writing for hi-hat in a drum kit, it seems I now need to choose whether to keep the part compatible with all other VSTs, or write exclusively for MuseSounds. If this is correct, I have trouble seeing how I would use the MuseSounds drum kit with any regularity.
That's my question precisely ...
@mdeluca wrote in a Github post
> What is not clear is whether this is an artifact of the move to a new percussion system (started in v4.4, expected to be completed in v4.5), with the new code being added in 4.5 providing an interface to address this issue. But as currently configured, drum export for open / closed hi-hat is broken when using the Muse Sounds drumkit.
Well said. And thanks for posting to Github.
Perhaps in 4.4.2 we currently have another example of "un oeuf insuffisamment cuits."
In reply to Thanks for this information… by mdeluca
To be clear, this is problem is solvable, but there is some nuance and room for improvement. MuseSounds can recognize the MIDI pitch for open hi-hat, that can be done in a simple library update independent of MuseScore Studio.
"Standard" is a funny word in non-pitched percussion. In a way, as things stand, we are being forced to choose between MIDI standards and notation standards (and even notation standards for drum kits is a hotly debated topic). MuseScore's philosophy has been to prioritize notation standards. Also, many VST's have some departure from General MIDI (VST drum kits can vary greatly, some have several Hi-Hats)
The legacy way was to use x on a different line: a human drumset player would not recognize that as an open hi-hat (assuming you know what I am referring to, that notation would be considered a different cymbal by a human). It was actually more difficult to write the notation for a standard open hi-hat then and it was often a
point of ridicule for MuseScore. Perhaps in the not-so-distant future can also add some logic that changes the pitches of hi-hats with open articulations on MIDI export.
In MuseSounds, the sampler recognizes that the user put an "open" articulation on a hi-hat and that makes playback happen. This is a good user experience for many people. However, as you know, this only changes what the sampler plays, not the midi pitch itself and it is not backwards compatible as you stated. The advantage of some departure from general midi is:
1. Smoother writing experience for drummers and people who don't even think about general midi
2. Composer will be able to get even more detailed playback options. In some of our MuseHub Libraries, you can control how open/loose/tight the hi-hat is, what hand you play the hi-hat with, strike with the shaft or the tip...etc. MIDI General cannot do that.
TL;DR I hear your complaint and understand the issue, in the very near future, we can add open hi-hat MIDI to MuseSounds drum kits but it will not be "standard" notation. We have a long and ambitious list of improvements for the percussion writing experience but the timeline is not locked-in at the present moment but I am sure more details will be shared soon.
In reply to To be clear, this is problem… by Zac
Why not translate the hi-hat note with an “open” articulation into the correct MIDI pitch when emitting MIDI data? (VST drum kits that deviate from the standard would need the ability to customize the mapping, but this can be implemented later down the line.)
In reply to To be clear, this is problem… by Zac
Thanks very much for your detailed reply. And my apologies if this discussion of 4.5 features is hijacking the 4.4.2 thread - I'm happy to move this discussion to a different location if that makes more sense.
Here's my understanding of the situation:
(1) It's hard to point to a single "standard" for non-pitched percussion (I am in full agreement here).
(2) General MIDI (GM) defines open and closed hi-hat with two separate notes (specifically, 42 and 46 respectively).
(3) Historically, open and closed hi-hat were represented in MS Studio using different notes on the drumset staff. In v4.2, for example, closed was a cross notehead above the top line (staff line -1), and open in the top space of the staff (staff line 1). This system allowed export using the appropriate GM note, but did not adhere to more "standard" notation, where open is shown as a note in the same location as closed but with the "open" articulation symbol.
(4) MuseSounds is moving to this more "standard" notation system, where Muse Sampler can read the articulation symbol and render the "open" sound. This allows for the more standard notation to play back appropriately when using MuseSounds, and provides access to other options available in MuseSounds libraries (variation of how far open, etc.)
(5) Because the underlying note for "open" and "closed" are the same (staff line -1), however, MuseScore Studio does not (currently) have a way to differentiate between open and closed notes when exporting, even though "open" has an articulation symbol. This also presents a problem when switching between MuseScore libraries and VSTs, as the VSTs can not "read" the open articulation symbol.
You outline a few potential options to address this:
(A) Logic could be added to the MIDI export process in Studio to intercept "hi-hat with open articulation" and map this to MIDI note 42. You suggest above that this might be possible in the "not too-distant future".
This option would definitely clean up MIDI export and support the ability to transfer parts to a DAW, as the export would follow GM conventions (with whatever modifications would be needed for the VST being used). But it sounds like this would still retain an incompatibility within the program when changing from MuseSounds to a VST. In other words, if I wrote a note using an articulation for "open", it would still be played as "closed" when switching from MuseSounds to a VST inside MuseScore Studio. Is that right?
(B) MuseScore Studio could add a second way to trigger "open" hi-hat, and MuseSounds could be updated to play "open" either when using the "open" articulation symbol or a separate note location. As a composer, I would have a choice to make: the articulation symbol (which would look "right" but would not export properly), or a separate note location (which would export properly for VSTs in a DAW, but would not look "right").
There are a few things that are not clear from your description. Both of these notes should play properly (as "open") when using MuseSounds. But what about MS Basic, or a VST? And what would happen if I start writing using "MuseSounds" notation (with the articulation notation) but then switch to a VST for a different sound?
(C) Leave things as they are. (You don't call this out specifically, but it is an obvious potential option). While I don't recommend this, it would need to be accompanied by good documentation, describing some of the points and restrictions above. In fact, careful documentation would be needed for any of these options to make sure users know how to work in the new system.
++++++++++++
The other option, of course, is to change "hi-hat with open articulation" to a separate MIDI note within the core code for MuseScore Studio. You don't mention this above, suggesting that this may be difficult (or more) to implement. If it is possible, however, this would seem to address all issues - MuseSounds would see a note with an articulation symbol, allowing control of the hi-hat as you outline (partially open, etc.), and VSTs and export would see this "MIDI note 42", allowing for proper playback and notation.
++++++++++++
Again, I appreciate your time to help describe what's going on and planned here. I've added a pointer in the GitHub issue to this thread as additional background, and hope that a good solution that cleans up notation, interfaces well with MuseSounds and other VSTs, and is implementable in code can be found.