3.0 interface
After using 3.0 for a couple of days I miss 2.3.2. I haven't changed any settings in either of my version so this is all out of the box.
In 3.0:
When I select a range of measures it is less than a 50/50 chance I will successfully click to select the measure at the last end of the range while holding the shift key. In 2.x I had no difficulties finding an empty spot on the staff where the click would select the measure.
Dragging items to a chord is now an exact science. If it's actually possible to drag the item to the chord (see next comment), you must highlight the top note, all other notes are non existent as far as this goes. In 2.x I could drag to any note in the chord and the item would be applied.
It is impossible to drag a clef to a note mid measure. I must now exit note entry mode, select the first note for the new clef and double click the clef to apply it. It is still possible do drag a clef to affect the entire measure, even in note entry mode.
Version 3 quickly slows down. I am doing some testing to see if I can determine what slows it down. I'm working on an oratorio by Handel, so there are lyrics and figured bass as well as the usual items like slurs and dynamics, though these are far fewer than Romantic and later music.
Undo and backspace work differently. Doing any of these leave nothing selected. In version 2, doing these left the next note to be undone selected, so if I mess up the accidental and notice after a note is entered, I must now undo that note, reenter the note. In version 2 I could undo until the note that needed fixed was highlighted and fix it without reentering it first. Having the note highlighted also allowed for adding a tie to it by simply pressing + or duplicating the chord by pressing R.
Comments
Edit: if you read this before the edit, I discovered it works the same as 2.3.2. With my closer scrutiny in 3.0, I noticed there is no visual feedback in either version until you press ctrl+4 (or any other number for a different tuplet). In 2.x I knew what result I would get. It's amazing the detail you never notice doing something over and over again.
Entering lines on a single note is strange. In 2.x to enter a line on a single note, you selected the first then ctrl+click the next note and the line will be applied to the first line. This does not work. I tried just selecting the note (head), that didn't work. Finally I stumbled upon selecting the chord (by shift clicking a note) and was able to apply a line. 2.x's method was far better.
After typing this, I went back to my project and found several trill lines on my note. I guess they just weren't showing up immediately until I selected the chord and applied it.
In reply to Entering lines on a single… by mike320
Hmm, the Ctrl+click method works fine for me in 3.0. But I suspect maybe the layout performance enhancement that tries to only layout the change portion of your score is getting something wrong in your case. Feel free to attach a score and steps to reproduce.
Not that I ever used the Ctrl+click method - to me, simply range-selecting the first note only is simpler and more obvious. Not sure what makes needing to select two notes when you could select just one seem "far better"? But it would be nice to fix the layout glitch you seem to have experienced. I see plenty of others but don't have any real insight into what specifically might cause this.
In reply to Hmm, the Ctrl+click method… by Marc Sabatella
As I said in my edited comment, the trill lines added any way besides selecting a chord using shift+click didn't show up until sometime later, and I'm still not sure what triggers their sudden appearance. Same thing happens when I apply an accidental to a trill line.
I'm entering a score with only 33 staves and on measure 73 it is so SLOW that it's nearly impossible to wait for the notes to catch up with me. I've entered scores with twice as many parts in version 2 with these kinds of results. The theory that 3.0 is supposed to be faster than 2 is wrong. The score I'm currently working on has no lyrics or figured bass, so that's not what's slowing it down.
In reply to I'm entering a score with… by mike320
The theory that 3.0 is supposed to be faster than 2 is wrong.
Well, you are using an alpha version of MuseScore 3 VS. a 2.3.2 version of MuseScore 2. We made a lot of changes in the current MuseScore 3 to make it faster but we also added smart layout which should make it faster to create a beautiful score, but that comes with some sacrifice and probably a lot of optimisations are needed. In theory, when you add a note in MuseScore 3, we just layout what is needed but bugs happen, especially in alpha software...
So the theory is still valid but in practice, yes, optimisations and bug fixes are needed. Just an example, in the nightlies just after the alpha I heard Werner saying that he increased the speed of vertical layout of staves by about 20%.
In reply to The theory that 3.0 is… by [DELETED] 5
Perhaps some clarification of what I mean will help.
I base the speed on how long it is from the time I press a note key, to the amount of time it takes for the note to sound. In an empty score it is instantaneous and the note sounds for exactly the 300ms set in preferences. It is expected that everything will slow down as notes are added, simply because more code is required to update the score, to find the measure you are currently working on and so forth.
In MuseScore 2.x I seem to start noticing a slight delay in a 50 staff symphonic piece at about measure 50 and sometime around measure 125 the delay gets so bad that the note is sounding for more than a second. I don't put a stopwatch on it, but I assure you it is several times longer than the default 300ms. I can turn off the sound to speed things up, but then I don't realize when I've made errors as easily.
The current score I'm working on in version 3 has 33 staves and the slowdown started being noticeable around measure 25. Now at measure 75 the delay is unbearable like what happens after 125 in the version 2 score mentioned before.
In version 3, I get so far ahead of MuseScore that the Windows circle starts spinning and the score fades like its about to crash, but once MuseScore catches up to me it continues working slowly. I don't recall ever seeing this is version 2.
In reply to Perhaps some clarification… by mike320
When one hears about 3.0 being faster, the main thing is the aspect of "smart layout" that only lays out the changed portion of your score rather than needing to lay out the whole score. So after a one note change, whereas 2.x will recalculate the position of every single element in your score, 3.0 will only recalculate the portion of your score actually affected by the change, whether a single measure, system, page, or subset of pages as needed. But the actual time to lay out any particular element probably hasn't gotten faster, and on the contrary the autoplacement and collision detection probably makes layout of individual elements slower (reasonable conjecture, not based on actually measuring anything.
So in theory, if your change only affects the layout of the current system and doesn't have a ripple effect throughout your score, your edits should indeed be much faster in longer scores - basically, the time for an edit should be independent of the size of the score. But if your edit changes the width of a measure and thus results in a measure moving to the next r previous system, and this then affects the layout of every subsequent system, you can expect performance to be no better.
When I tested this shortly after Werner first implemented it, I found that certain edits were triggering a full layout of the whole score even though they didn't need to, simply because the "local relayout" code hadn't been added for that specific command. I forget the specific examples, but for instance, it was something like, adding an accidental via up/down arrows would do the local relayout fine, but adding them via the toolbar triggered a full relayout - again, not really that, but something along those lines. That was literally years ago, and I'm sure the local relayout is more fully implemented by now, but it wouldn't surprise me if there aren't some particular edits that still trigger a full relayout for whatever reason.
All of which is to say, if you have a specific case where particular edit seems unnecessarily slow, attaching the score and giving the steps is always a good idea.