MuseScore 3.3 Release Candidate
No more words!
Just download MuseScore 3.3 Release Candidate and feel the power of the new palettes
|
|
|
|
| Windows 64-bit | Windows 32-bit | macOS 10.10 or higher |
Linux AppImage (64-bit only) |
Feedback
"The palettes have now reached a point where it's painful to have to go back to 3.2.3 😊" - Happy User
"This is just the coolest thing ever. No need to bother [palettes] searching ever again." - Another Happy User
| Release Notes | MuseScore 3.3 Beta | MuseScore 3.3 Beta Update |
Comments
There is no documentation available yet for the new palettes, correct? I'd like to make sure I know how things are supposed to behave before I start reporting bugs…
Just posted a bug report about incorrect spacing between roman numeral analysis and barline:
https://musescore.org/en/node/295500
In reply to Just posted a bug report… by josiasmat
Please report that in the issue tracker
Edit: thanks for #295504: Roman Numeral Analysis with numbers only not formatted correctly
Quick comments:
A) I think the 'Add to [palette name]' button is unnecessary. The text at the bottom of the 'more' panel explains the user that the element can be dragged to the palette or directly to the score. Why is there also a button for this action?
B) There is happening some weird stuff when clicking on the text. the palette is becoming blue but is not folding-out. When the user keeps clicking on the text there is a certain rhythm in which the palette will fold-in, fold-out or being colored. Sometimes it will fold-in, sometimes out, sometimes it gets colored, it seems not yet to work how it's supposed to.
C) Maybe the 'more' button can be changed to a plus symbol instead of a word to free up some space. that cell should have a different background-color to indicate its a button.
In reply to Quick comments: A) I think… by Philip Bergwerf
B) I see when on the palette-text the user has to double click to open or close a section. So I think it's working like how it's supposed to.
I'm downloading 3.3-RC right now to see how it works. I'm eager to see and to use a stable 3.3 version. It's working very nicely.
There's just an issue happening here in Linux. I have used 3.3-beta-update since it was released and at the advanced workspace I remove some palettes that I never use. It's automatically renamed Advanced_Edited and goes on working right. But after several days the palettes I had removed appear again in Advanced_edited.
It seems to happen specially after I open a file that was created before modifying the workspace, but I couldn't duplicate this bug on purpose and I'm not sure if the reason is really this.
In reply to I'm downloading 3.3-RC right… by fernandoamartin
Did they appear after you opened 3.2.3? 3.2.3 and 3.3-RC seem to share palette info.
In reply to Did they appear after you… by mike320
They share all settings indeed
In reply to Did they appear after you… by mike320
Oh! Yeah! That's it!
If I click on a mscz file on Dolphin it automatically opens in Musescore 3.2.3 that is my system version. Then next time I open 3.3-RC in Appimage, hidden palettes are shown again.
As Jojo_Schmitz wrote 3.3 and 3.2 share the same settings. I use the appimage confidently, knowing that it takes my user configs and it's very good. But sometimes there are things that get a little messed.
Example: Even if when my system install and the appimage were in the same version I was not able to type portuguese characters in lyrics like ã, ç á etc, using the appimage. On the other hand on Manjaro install I'm not able to change the fonts of title, subtitle etc as I do in the appimage. It's easy to workaround it switching between both.
But know there's really this new situation. Simply opening 3.2.3 changes settings of 3.3 palettes.
There is still one big issue in terms of annoying things.
I like to use a shortcut to quickly show and hide the palette. Since musescore 3 was released there was also a search bar in the palette. The annoying thing is that after opening the palette the search bar is automatically focussed so hitting the shortcut again(to close palette) will type the shortcut in the search bar instead of closing.
Also after opening the palette, it's not possible to use any one-key-shortcut(like entering notation mode using 'n') because it will result in typing the shortcut in the search bar. I really really hope this can be put on the list of small fixes. Make the search bar not autofocus after opening the palette.
Philip Bergwerf
In reply to There is still one big issue… by Philip Bergwerf
I'm confused, why would you open the palette if you don't intend to immediately use it? And as soon as you use it, focus returns to the score. The advantage of having the focus in the palette is then you can immediately start searching or navigating it - a boon to blind users or anyone else who likes to navigate or search the palettes, should be irrelevant to others since focus returns to score as soon as the palette has done its job. So to me, the focus in the search box is a feature, not a problem, chanbigng this would be a step backwards.
Can you explain more about your usage - the sequence of operations you are perfroming in which this features causes a problem? Do you often open the palette then immediately close it without performing any action?
Even this shouldn't cause a problem, unless, hmm, have you redefined the shortcut for opening/closing the palette to be a typable character? I would indeed recommend against that.
In reply to I'm confused, why would you… by Marc Sabatella
Hi Mark. It is important not to question userspace actions. "why would you do.." should not be a starting point, as we all work differently. It is a coders' response. Rather question the user experience and see if it can be improved. I see this alot - Just my 2c.
In reply to Hi Mark. It is important not… by songshop
Understanding why someone does things a certain way is needed find the real underlying issue
In reply to Hi Mark. It is important not… by songshop
Actually is very import to question user actions. Someone does something expecting a given result simply because they don't understand there is a better way to get that result, and the action they performed works the way it does for a reason (to get a different result). Or if the request to change the behavior of a given command because it isn't optimum to one particular use case, it is absolutely vital to understand that use case - what real world scenario causes it to come up and get a sense of how common that scenario is compared to the scenario the command is optimized for. And to understand how big the difference in optimziation is. If a command can be used for use case A and B, and right now it's optimized for case A and B takes 5% longer, but optimizing it for case B would make case A take 80% longer, it could potentially be worth continuing to optimize for A even B is slightly more common.
So, bottom line, understand is key, and yes, any good coder would seek that understanding, so I would hope a coder would respond that way by seeking that understanding.
In reply to Actually is very import to… by Marc Sabatella
I don't mean t be rude but :
"I'm confused, why would you open the palette if you don't intend to immediately use it?"
Really? So you must use a palette if you open it? No.
the real point is that MS defaults to an active search dialogue when the palette is opened. And I agree with Phillip entirely on this point.. it's the only point to be made imho. That's all I was alluding to.
In reply to I don't mean t be rude but :… by songshop
Nothing rude about sharing information and asking for clarification so no worries.
I get that not every time one opens a new window does one then choose to use it - some percentage of the time, one changes one's mind. What I am asking is, does you really find yourself changing your mind more than half the time? If so, do you have the same experience with other windows in MuseScore - say, Tools / Transpose, or Edit / Instruments, or Format / Style? And are you in the habit of pressing Esc to tell MuseScore you have changed your mind in those other cases?
I'm truly trying to understand here. It's the norm in all windows of all programs I can think of to take focus immediately upon being opened, if they support keyboard navigation. So I'm struggling to understand what seems unique this for you. Nothing rude about helping each other understand.
In reply to I'm confused, why would you… by Marc Sabatella
Well I am working on a small screen so I like to have control over the big side panels. Toggling it on or off. In a normal workflow I sometimes peek in the inspector window and sometimes in the palette.
1. Let's say I want to add a not common used symbol so I press the shortcut to open palette.
2. before I start searching I decide to first insert a slur or whatever other function. maybe I want to enter a note. In this case, the autofocus is annoying. And this happens a lot when puzzling how to write something down. I am not a computer who is following a script while using the program;-)
So the problem is that I was used to have full control over opening and closing the palette panel no matter what I was doing and this changed since MS3.
And I don't think it's a step back. Because the search bar is sometimes handy. Removing the search bar should be a step backwards.
In reply to Well I am working on a small… by Philip Bergwerf
OK, as I guessed, the problem happens only in the special case where you open the palette, then decide not to use it, correct? I am still not sure that is worth making the experience worse for the majority of other cases where you actually do use the palette after opening it. And taking focus away is definitely a step backwards, having the focus go to the window when opening it is very useful for many.
In cases where you change your mind about using the palette after oepning it (and usure, we all change our minds sometimes) you can simply hit Esc to return focus to the score. To me this is no different than, say, opening a dialog box and finding you can't then use shortcuts in the score. It's normal the dialog would take focus, if you change your mind and wish to interact with the score instead, just hit Esc to close the dialog.
So again, I would personally recommend against such a change, as it would be a step backwards and the usual way one changes their mind about focus after opening a window is to press Esc.
In reply to OK, as I guessed, the… by Marc Sabatella
Agree with Marc that opening the palette must give focus to the search field.
We only have a bug (yes a bug) if the shortcut to close the palette doesn't work without additionnal action. ( to keep the palette opened and come back to score we have esc to keep palette opened and give focus back to score)
Does the default close palette shorcut work when focus is in search field or not?
If yes we are good, with the logical and explainable "limitation" that changing that shortcut to a letter instead of a Fn key will breaks that specific functionality as the search field will consume that letter.
But not being able to close the palette with a letter shortcut when focus is in text field is always true anyway ! With or without autofocus. So reassigning that shortcut to a letter is a bad idea in the first place.
In reply to Agree with Marc that opening… by frfancha
To be clear: the default shortcut F9 works just fine regardless of where focus is. Only if you've reassigned to tto something alphanumeric would there a problem closing the palette by pressing it again - u less there is a bug with some specific sequence of keypresses, and that bug should be reported separately. But in general it works exactly as it is supposed to.
Also, I should clarify that I don't actually care if the search field specifically is where the focus is when you open the palette window. I'd be just as happy if it were the top palette, or the last used element (same as when you transfer focus to an already-open palette via Shift+Tab). And also, I am not saying it "must" do any of this. I'm saying there are extremely good reasons why it does this currently, and if this important functionality is going to be taken away from one group of users, we need to fully understand the tradeoffs - just how common the two use cases are, the respective penalties for having a non-optimal implementation for one use case versus the other, et It would be foolish and harmful to change any aspect of a UI just because a handful users say they personally would prefer it to work differently, without considering the full context.
FWIW, I think it's a worthwhile discussion, but it belongs in a separate thread.
Help me, please! Everything was going very fine with 3.3 RC, specially on palettes until I created a new score and after writing some measures I wanted to change to a time signature that doesn't exist by default. I opened the time signature palette, clicked more and then create time signature button and Musescore crashed. I tried it again and again and crashed. I tried simply opening a new session of Musescore and pressing only shift+F9 and it crashed. I tried to repeat it all over again in 3.2.3 and it also crashed!
Perhaps it is a bug inherited from 3.3 or maybe 3.3 config is getting messed with previous versions configs. I don't know but I can't use shift+F9 anymore. The menu View / Master palette also crashes. No way to get there.
In reply to Help me, please! Everything… by fernandoamartin
First update to the new RC2 just released a few hours ago. If that doesn't fit it, try Help / Revert to Factory Settings. If that doesn't help please start a new thread in the Support so we can assist you better without getting that discussion mixed up with this one.
In reply to First update to the new RC2… by Marc Sabatella
Reset to default worked. Thank you.
3.3 is SOOO SLOW! It is ridiculous how slow it is. Needs fixing!
In reply to 3.3 is SOOO SLOW! It is… by musicbomb012
More details needed, when is it slow?
Startup, when having MDL installed? That's a known issue, no cure in sight.
In reply to 3.3 is SOOO SLOW! It is… by musicbomb012
To be more specific: the MDL soundfonts are large and take a long time to load, so startup can be slow indeed if you've installed MDL. Other than that, things should be very fast, and nothing got slower in 3.3 compared to previous releases, and ever since 3.1 it's been way faster than any previous release. So if you have some specific score and some specific operation that is slow on your particular system, we would need you to attach the score and give us the steps to reproduce the problem, to see if we can reproduce it on our systems.
In reply to To be more specific: the MDL… by Marc Sabatella
From my own experience I can say that 3.3 is working right. I set a 1.0 GB soundfont as default in mixer and I was able to open and write scores in a PC that has only 2GB RAM and dual-core processor. Of course, I didn't use many instruments at the same time, but Musescore started as fast as it did when using smaller soundfonts and played the score I was writing without lags.
In reply to From my own experience I can… by fernandoamartin
How exactly do you set SoundFont sizes in musescore? This may solve my problem
In reply to How exactly do you set… by musicbomb012
You don't. A soundfont has a certain size, you can't change that, just tell MuseScore to load it or not.
"I set a 1.0 GB soundfont as default in mixer" is not about setting a max. soundfont size, but about taking/loading a soundfont that is 1.0 GB in size.