MuseScore Studio 4.4.2 is now available!

• 2024년 9월 12일 - 14:49

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!


논평

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 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 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 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 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 its relatively deep 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 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 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 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 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 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.

Any new development on Muse Drumline coming to Linux? In the original 4.4 post, They said that they would make a post on the forum about it, but I haven't seen anything about it. Also the play back on linux is SO much better. Thank you for fixing that on lower end computers, to hear my scores I would have to export a .wav file but now I can just listen and I hear everything. Amazing work.

In reply to by pearsonisasim

A new version of Muse Sounds Manager is being worked on at the moment, which will unblock the release of drumline for Linux users. This is actively being worked on, and we've been told to expect a release in the coming 3-4 weeks. We'll post a forum update on this when it's ready.
And very good news about the playback improvements! Very glad to hear this :-)

That's a fantastic news! Is there any chance to have the performance issues with kind of big project fixed? I posted an issue on github, but got no answer at all. Thank you again for the great work!
EDIT: They answered.

Hi, any chance that ara plugin full support will be added in the future? for programs like synth 5? currently, it's available to put in but doesn't work.
Thanks

In reply to by Marc Sabatella

Does this mean
1. Playback for MuseScore Studio 4.4.2 for Linux will be disabled? Or that
2. Only enhancement introduced by the upgrade to MuseSampler by MuseHub for Windows and Mac will be missing from 4.4.2 for Linux, that otherwise playback will be as it has been for 4.4.1 (excluding any bug fixes included in 4.4.2)?

Hope this is clear.

I struggle with the accessibility of the new Muse Hub. In general, dark themes are very difficult to read for me. Is there a setting somewhere that I overlook that allows to switch to a light theme?

My laptop speakers stopped working last night and only output a bunch of noise. After eliminating many options, I'm sure it's due to Musescore. After I updated to 4.4.2 yesterday, whenever I open Musescore, the speakers stop working, and then work again when I close it. Please take a look at this issue, I can only try to use a lower version now.
I'm using a Dell Inspiron 15 3520 and Intel® SST OED.

I submitted a comment earlier fretting over certain Muse Sounds not downloading, only for them to work perfectly twenty seconds after submitting the comment… the universe loves pranking me 🤣

Since updating(meaning before, this glitch was not happening) my score randomly crashes and does not save, it closes the app entirely. As I said this has not happened before updating it.

Greetings

I noticed a long time ago that the new versions of Musescore Studio have made a function that existed in the mixer disappear, so to speak. Let me explain, in older versions, for example, when you added a pizzicato to the strings, another MIDI channel was automatically added to the mixer as if it were an instrument change and it sounded like the pizzicato. However, with the new updates, that has disappeared, now, when you add a pizzicato, you can clearly hear the sound change, but it remains on the same MIDI Channel as the strings. This resulted in the fact that when it is exported in MIDI format to open in another software, it does not recognize the pizzicato, but instead it appears next to the same MIDI channel as the strings, causing confusion when assigning the sounds.

My point is, I don't know if they did it this way to reduce space in the mixer, or if it was something they overlooked. And if there is a solution in musescore itself, or how can I take this question to the developers so they can give me a clear answer or if they can fix it.

첨부 파일 파일 크기
Mezclador 3.png 82.94 KB

Hey MuseScore!

I'm a new user and loving this software! Having used Finale for nearly 20 years and having just recently purchased my first Mac in years, the two together are great, so thank you all!

Quick question, is MuseScore 4.4.2 compatible with Mac OS 15 (Sequoia)?

In reply to by simonfield

Based on the technical release notes of macOS 15, I expected no issues for MuseScore Studio, and in practice, in five days, I have indeed not seen any issues. So it looks like it's fully compatible! We might post an 'official' statement about this next week, if we decide that that's necessary.

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