Some dynamics in MS 4.5.2 are nonfunctional

• Apr 29, 2025 - 08:55

The second line of this score doesn't respond to dynamics. Can anyone tell why that is?

https://musescore.com/user/35880724/scores/24974236

Comments

• Apr 29, 2025 - 18:21

@Cadiz1 wrote > This score or excerpt comes from some user on MuseScore.com. Export it in MusicXM format, and the dynamics will return as expected

Actually the provenance of the score is:

   • A piece I originally learned by ear
   • Recorded it in real-time into a sequencer (approx. 30 years ago)
   • Exported to MIDI
   • Imported to the Encore notation app
   • Exported to from Encore to XML
   • Imported the XML to MuseScore Studio 4.5.2

Upon noticing the dynamics issue I created the short score (embedded in the original post.) I added the initial line to make sure that dynamics were working. Then I pasted a phrase from the MS4.5.2 score produced by MusicXML import—then I added dynamics to that phrase and again found they do not work at all.

Reply

• Apr 29, 2025 - 18:51

In such cases, you have to ask yourself: am I able to reproduce the problem ("Some dynamics" that wouldn't work in 4.5.2?) from scratch? The answer is no: if I manually write the same line with 4.5.2, all's well. See the file: MS4-5-2_scorster(2).mscz
I don't know when something went wrong, but given the file's eventful history, it's hardly surprising :)
MusicXML export is often useful in case of doubt. It acts as a kind of file reset.

Reply

• Apr 29, 2025 - 21:15

@cadiz1 > In such cases, you have to ask yourself: am I able to reproduce the problem ("Some dynamics" that wouldn't work in 4.5.2?) from scratch? The answer is no

Correct. And that's precisely why I started with a fresh score and entered the notes on line 1, which work with dynamics as expected.

> ...if I manually write the same line with 4.5.2, all's well.

Understood. Of course, manually rewriting the score is the last thing I want to do. I'd rather invest time in removing the stumbling stone so others don't stub their toe.

> MusicXML export is often useful in case of doubt. It acts as a kind of file reset.

Unfortunately exporting to MusicXML and importing back to 5.2 doesn't cure the dynamic issue.

Reply

• May 4, 2025 - 06:49

Import bug reported on Github

     https://github.com/musescore/MuseScore/issues/27934

Note that the Github report also includes a workaround that makes the dynamics functional:

  • Export to uncompressed MusicXML
  • Delete every dynamics="88.89" attribute
  • Open the MusicXML the the score in the original score play

Result: The dynamics are functional

I've included comments in the Github post that explain why I'd rather not use this type of "repair." I'd rather that MuseScore flag issues that cause dynamic conflicts, and in this case, fix the issue by deleting the problematic attributes.

Reply

• Apr 29, 2025 - 19:03

Seems like I recall something about notes with velocity applied (e.g., in MIDI format) would sometimes not recognize MuS's written dynamics. I don't recall the details and probably never really understood them, but that seems a possibility to consider?

Reply

• Apr 29, 2025 - 21:58

@Jojo-Schmitz

Thanks for this link, but the steps don't solve the reported dynamic problem in MS4.5.2.

Currently in MS5.4.5.2 Properties>Note only contains Head, Stem and Beam tabs

Velocity is now hidden (I guess because it is SO poorly supported in MS4) in General>Playback. And pressing Reset does change all values to 64, it does not fix the initially reported velocity issue. Seems that the How-to needs updating.

Indeed the score embedded in the original posed opened with velocities of User type at varying values. (Offset type is no longer a thing in MS4). I set all values to 64 to see if that alienated the dynamic anomal, but that made no difference.

Reply

• Apr 30, 2025 - 07:48

I wish it was like that on MacOS, MS 4.5.2

Here's MS4.5.2's Properties panel on MacOS

with Playback closed

      MS4-5-2 Properties panel.png

with Playback toggled open 

      MS4-5-2 Properties-Notes-Velocity panel.png

Regarding my comment about being hidden, I was referring to the object I'll call the Playback Button-Tab

Anytime I select something other than a note or a rest:

    • the Playback Button-Tab closes
    • its contents remain hidden until the user reopens the Playback Button-Tab
    • AND there's no checkbox to enable Playback Button-Tab "keep open" property

Users encounter a tedious workflow when editing velocities. And that's caused by automatic of closure Playback Button-Tab. This is triggered when the user clicks on anything other than a note or rest.

Reply

• Apr 30, 2025 - 08:16

> I see Velocity in your 2nd image

Correct. The issue is that on opening Properties>General the velocity properties are hidden in the Playback popup. (I think popup is the object type.)

Said differently, the popup is closed whenever the user opens Properties>General—as shown in the first image—unless a note or rest is currently selected. That's the default behavior; and there's no option to have the velocity properties popup display whenever the General Tab is open.

All that's needed is a keep open checkbox or property. Kinda like a disclose triangle that remembers its past state.

That would solve it—I'd check "keep open" and leave it that way. Previously requested on Github, I think ... somewhere.

My encounters with MuseScore's first attempts with popups have been awkward.

Reply

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