MuseScore 3.4 Beta Release

• 12월 26, 2019 - 18:37

Try out the new features and improvements introduced in the new version of MuseScore 3.4!

Download MuseScore 3.4 Beta Release

Windows 64-bit Windows 32-bit macOS 10.10 or higher Linux AppImage
(64-bit only)

MuseScore 3.4 Beta announcement

Single click interactions

We all know that MuseScore is powerful notation software that can do almost everything in terms of music notation. We conducted a dozen of user testing activities with the ones who never used MuseScore and found that "double click" is an interaction pattern that is absolutely hidden for newbies. Respondents could not edit slurs and hairpins to adjust their positions; they couldn't even apply elements from the palettes. Double click is rarely used in touch interfaces as well (that's why the young audience isn't familiar with the double click interaction pattern.)

We aim to improve usability and make MuseScore as easy as possible for newcomers keeping all the fine-tuning features for professionals. We are glad to introduce the single click concept designed by Martin Keary (Tantacrul). The new approach provides an easy way to edit elements with a single click and makes double click unnecessary.

Check out the new approach and let us know what you think! We are always here to listen to your feedback and support.

Telemetry

There is a separate topic dedicated to introducing Telemetry in MuseScore.

Release notes

New

  • Apply palette elements with a single click if there is a selection in the score
  • Allow dragging notes horizontally
  • Slurs, hairpins and other elements can be edited after a single click

Improvements

  • Double click is no longer needed to enter Edit Mode
  • Introduce bend properties in the Inspector
  • Name of the newly created custom palette can be specified
  • Accessibility: improve speech for elements with spanners

Fixes

  • "Don't play trill" option silenced the note playback
  • Slurs on small staves were displaced in some cases
  • Barline handles were drawn incorrectly after dragging one
  • Strings in the Parts dialog were ambiguous
  • Y Offset value of fretboards didn't restore after undoing the values being changed from Edit Mode
  • Replacing a note with an accidental left the accidental on the new note
  • Adding Intervals (above/below) didn't take into consideration the accidental toggle state
  • Multiple chord symbols attached to same note didn't copy as part of the range
  • Strings in fret diagrams without "X" or "O" displayed as "?" on Linux

A full list of changes is available here.


논평

I hope to find time to check the beta version in the next few days. Furthermore @Anatoly-o's excuse for this little aside (and not really important for development): Thanks for noticing the concerns about the change of composer pictograms and spelling of MuseScore, it isn't important, but I really appreciate it :-)

Dear MuseScore,

I will keep pestering you about this. I love MuseScore for the desktop, and I love the UX improvements that have been made recently. However the mobile app is full of bugs and completely unstable. There is no public bug tracker for it, which means there is no visible, official place to report bugs. So bugs will occasionally be reported in random forum threads, in App Store / Play Store reviews, at support@musescore.com, at https://musescore.com/contact, but mostly, bugs will not be reported at all. The solution, IMO, would require two steps:
1. Start doing QA. The mobile app has had serious bugs in so basic features I cannot imagine how you could release it in that state. You should not rely on the userbase to do your QA testing. That's why I am not reporting any concrete bugs in this post. I will report all of the bugs I find if you:
2. Set up a public bug tracker. A Github repository can be used as an issue tracker even if there's no source code.

In reply to by [DELETED] 30992681

Hi Márton, thanks for this. As some others here have mentioned, MuseScore.org is dedicated to the desktop app only. I understand that this is pretty difficult to figure out since the .com and .org sites look almost identical and neither clearly spell out what they are for (we're working on that!). Regarding the mobile app, I agree that it also needs a lot of work and we are beginning to look at redesigning it. Would you be interested in helping us test new versions to let us know what you think? If so, send an email to info.tantacrul@gmail.com and I'll get in touch. It would be great to also get your perspective on what is wrong with the existing version too.

Thanks!

In reply to by Howard-C

They shouldn't get rid of double-clicking just because kids don't know how to do it because they use touch screens too much. When I was in school in the 90s, we were taught the basics of pointing, clicking, dragging, and double-clicking in the computer lab, as well as Mavis Beacon Teaches Typing 8, whatever was being used in the late 90s/early 2000s.

I'm used to double-clicking on a part of the score to edit it. https://tvtropes.org/pmwiki/pmwiki.php/TheyChangedItNowItSucks/Websites…

In reply to by Howard-C

Time for some official documentation about this detail? Let me get this straight --- this is supposed to be less confusing? (Repeat old joke about lecturing math professor who says a proof is trivial, and a student says "no, it's not trivial", so the professor goes out of the room for 20 minutes, returns, and says, "it's trivial").

In reply to by Howard-C

Just noticed, if you select a note and after that a second time you can change the leading space of the segment via mouse. But via double-click (in proper sense), you can change the vertical/horizontal offset of the chord with the mouse (Not sure, if this could lead to confusion).

In reply to by Dogman15

There is actually another reason we've moved over to single click, which is that it allows us to create powerful multi-editing features in the future. For example, in MuseScore you can't drag to extend multiple hairpins at once and it's impossible to build this feature when the drag interaction is hidden behind double-click. Moving over to single-click unlocks this, along with a bunch of other multi-editing features (which we now need to go and build!)

In reply to by Dogman15

Dogman15: "Single-clicking is for selecting."

This has been the standard behavior for PC software for so long that it should be regarded as THE standard behavior. PC software, tablet software and phone software are different things and should keep on being different things.

I don't like this new single-click feature.
Do what you like with my statement, but I had to state it.

In reply to by Aldo

It would really help if people could state something specific that they find problematic about a selected item going into edit mode. So far I haven't into anything that doesn't work as expected. But if there is some specific action where behavior isn't as it should be, that can always be corrected.

As for single-click being THE standard, I don't know, there are plenty of other applications (drawing apps, for instance) where a single click gives you edit handles and allows moving elements with the cursor keys). I was skeptical at first, but I'm not seeing the harm in this here.

In reply to by Justin M. Bornais

So far, Dogman hasn't responded to JeeTee's question as to what you could do in single-clicking that you can't do now. Rather than saying "I want", is there something more specific? It would be nice to understand why someone would want the old behavior beyond merely "I like it" or "it's easier" with an explanation of how it's easier, providing some logical use case(s) allowing for others to agree. But whatever, 'tis just my chip into the pool.

In reply to by worldwideweary

There are countless things, just enumerated (e.g., lyrics, text strings, dynamics ...) that do not go into edit mode on single-click, for good reasons. Understanding the rules so far is an open "science project". The old rule was simple -- double-click to open.

In reply to by BSG

The rule is pretty simple: single click shows grips (handles) whenever it's possible. If an element assumes text editing (staff/system/expression texts, dynamics, lyrics, text frames, etc), double click is used to enter text editing mode.

Special cases are notes, rests and barlines that implement the horizontal dragging behaviour to adjust measure size, but this behaviour has nothing to do with single/double click.

In reply to by worldwideweary

I am used to single clicking to select, and double clicking to edit or open something. Just like selecting and opening files in Windows. Now that's changed. I am already accustomed to this method, so it's easier to stick with it rather than changing to something else. Regardless of whether or not it's generally better, I like the old method, and there should simply be an option to enable/disable the single click option so me and other people like me can stay accustom to the old method, while the younger people can use the new option. Automatically check the box so the new method is applied by default for the younger users, and I can uncheck it to stay with the old method.

This does not have to be a problem. Just add the button to make it easier (explanation of why it's easier is above).

The biggest problem I have with MuseScore is the speed and the Start Center.

1) The speed is still effected by the size of the score, though I will say the speed has improved immensely, so while it can be a problem at larger scores, it isn't nearly as bad as before.
2) The Start Center looks cheesy. The entire screen is devoted to recent scores. Because of this, I usually disable the Start Center and click on "Continue last session" under Program Start in Edit/Preferences/General.

There is one feature I would love to see: When it comes to creating a new score, even if I'm creating a quick piano solo score, I have to go through the process of clicking "Create New Score" to add all the details instead of automatically clicking on a template. Maybe the Start Center should be divided into two sections: one for creating new scores off of favorited and recently used templates, and the other for opening recent scores like it already does. This shouldn't be two separate tabs or pages of the start center, but rather just increase the size of the Start Center and put a vertical divider splitting the page into two pages.

Also, could there be an option to display the Start Center in list view instead of large icon view? I like that option more than icon view.

Other than that, thank you for all of your hard work and have a merry Christmas and a happy new year!

In reply to by BSG

Exactly. That's my point. Why have a Start Center at all? That's why I want them to add the Create New Score section where you can easily click on a template and go. That would make the Start Center actually useful because that would save LOTS of time. It would give the Start Center some actual use.

Like I said, I enabled "restore lass session." That way, it saves time on startup and shutdown. For startup, it takes extra time to load the Start Center to simply select to open a recent score, where I could just leave those scores open when exiting the software instead of closing them, and then when I relaunch the software, all those scores are automatically opened. It saves me time when clicking the scores to reopen, and it saves startup time since it doesn't have to open the Start Center. It's practically completely useless.

In reply to by Howard-C

"So hopefully it will be done for 3.5 or 3.6". I don't undrestand MuseScore versions. 3.4 is small or big release? Or the next version after 3.3.X? Why unfinished improvements/ideas are added to the stable releases? The stable big releases look like a prototype, never ending test version...
I don't understand yours policy of developement.

In reply to by [DELETED] 33823742

"Big" and "small" are not the only two sizes for releases. It's as big as it needs to be to fit the main two changes described (single-click interactions and telemetry), plus bug fixes. The single-click change is kind of big, but also kind of not, so call it what you want. Not sure what you mean about unfinished ideas, nothing is ever finished, hopefully. We continue to improve everything we can and have done this since day one. Only releasing software that we have no intention of improving even further is not a good strategy. Luckily no one does that.

I'm using the this beta on Mac OS and the update to dynamics (where the volume changes over one note) doesn't work for me even when using the default soundfont. Can anyone help?

In reply to by [DELETED] 12900971

Never mind, I fixed that issue somehow. I've been stuck using Musescore 2.3.2 because of a separate issue. I hadn't used a version with the dynamics update and I went to try it out and it didn't work right away for some reason, but after deleting and re-adding the default soundfont, it fixed the issue. I'm going to make a post about the major issue that has been preventing me from using Musescore 3 in a bit and I'll figure out how to provide an audio recording for what's happening.

I liked the single-click edit feature right from the first sight. Very practical.
However, in 3.3 I could define a shortcut to launch a plugin and it worked. In 3.4 beta (appimage in kubuntu 19.10) if I define any shortcut for any plugin, when I try to launch the plugin using the shortcut Musescore crashes. I can launch any plugin from the menu but not using a shortcut.
I went back to 3.3 and plugins shortcuts are working there.

In reply to by fernandoamartin

I can reproduce on WIndows. Right now there is also a crash that happens on Linux and Windows at least if you try to open a menu using the keyboard mnemonic (Alt+F for File, etc). It seems to be connected to the telemetry module so I can't reproduce when debugging unfortunately, but we expect to sort it out before release for sure. Anyhow, very possibly this is related.

In reply to by BSG

I have no insight into what telemetry does or does not do - I've never bothered to look at the code except to attempt to isolate this crash (and then discovered I couldn't reproduce it in my debug builds). But I assume the crash reporters already has reported what it needed to, I can't see any value in having the telemetry than info.

In reply to by Marc Sabatella

Are you saying that there is a mechanism in place now (and heretofore) which sends crash info back here somehow? When MS crashes, I get a standard Mac dialog about sending the report to Apple (although it is possible to copy/paste it elsewhere, but I am unaware of such a place here).

In reply to by BSG

Might not be available on macOS, I guess, but yes, after a crash, a dialog should appear offering to send info to MuseScore, separate from any OS dialog. This facility has been in place for quite some time (was added via one of the Google Summer of Code projects some years back).

< < Allow dragging notes horizontally > >
Would it be possible to perform some configuration of this work so that the notes move individually to the right and left as well?
In this work dragging to the right for example the note drags every team so we have to make a setting to shrink the measure where the process took place.
Thanks!

In reply to by mjbartemusica1

Google translate tells me you have a question about moving notes horizontally, but it's not clear what your question is. Best to start a new thread and ask in English here or Portuguese elsewhere. I can tell you that you can move individual notes, or entire chords, or entire segments, so it's important to use the correct method for the particular desired effect.

The 3.4.0-Beta-AppImage crashes for me, if want to access the menu via keyboard navigation (pressing alt+the corresponding letter). There is no crash with other released versions or with the actual nightly.
Is it reproducible for someone other or is it already reported?

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