why I still use v2.3
Recently I've upgraded to v3.4 (3.4.1.25011, revision20414b2 on Mac OS X.11.6 exactly) to see if there are still problems I've encountered with all of Version3 so far.
- automatic placement still causes more work than it saves because of undesired expanding of staff margins
- placement of both Line and Page Breaks only works if you manage to spot an empty area of the desired bar
- while placing Line or Page Breaks the according elements of a palette will frequently vanish graphically and are no longer usable
- while adding those elements again from Master Palette the placeholders of the vanished elements are still occupied
-- this affects both default and manually created/edited palettes, but not the Master Palette; the vanished elements will show again after programm restart, in addition to all manually added ones
- worst of all, with obscure conditions musescore will crash often while working with Line/Page Breaks
- so far the measure editing elements seem to be the only ones causing trouble, ie all former points are also valid for the 'repeat single measure' sign
I've never encountered so many crashes since v1.x, and since Break elements are important to me for making easily readable sheets v3.x is still a no go to me. So I'll still use v2.3, which works fine and hasn't so far crashed for once.
Note that this is not meant as a request, I'm thankful for all the work of musescore.org. I'm aware that I'm using a fairly old system, so an older program version makes sense on many levels.
Anyone having the same problems on newer systems is invited to add them here. Before opening a request I want to be sure that it is not just me and my old stuff causing trouble ;-)
Comments
Not sure what issues you're having with autoplace, please elaborate.
It is at times in the way though when importing 2.x scores, esp. when in those the layout has been heavly modified by drgagging elements out of their default place.
I don't hink adding system and page breaks is any differtent in 2.3.2 vs 3.4.1?
Better avoid dragging hem though, select measure, double-click break in palette.
Yen another level easier than using the Palette though is to use Return and Ctrl+Return instead.
Neither is applying the repeat measure sign any different, here again better use double-click than drag.
As to crashes: here too you'd need to elaborate, with steps to reproduce, else those crashes will probably never get fixed
In reply to Not sure what issues you're… by Jojo-Schmitz
I have opened v2.3 scores in v3.x, but I didn't convert them. However, described effects happen in a genuine v3.4 score.
Using the keyboard instead of dragging seems not to cover my workflow properly, see my reply to Marc Sabatella below.
crashes happened sometimes while dragging the mentioned elements to their designated measure and it didn't work because of misplacement, that is, letting go the mouse button when cursor is over an already 'occupied' spot of that measure (a note head, a rest, a beam, anything). Though, more often the elements will vanish from the palette, as descriebed initially.
In v2.3 it is of no consequence where on the desired measure you drop the element. This is also reflected in the way the measure is highlighted when hovering the d&d mouse cursor over the measure. In v2.3 the measure is highlighted as soon as the cursor hovers above. In v3.x the highlight will go on and off while hovering the cursor over the measure, depending on free space or already occupied spots of that measure.
The previous complaint I made is this: https://musescore.org/en/node/291707
It is about a slightly different subject. But we are still experiencing this (the examples there are old, a few still valid, even many new ones) .
In reply to The previous complaint I… by Ziya Mete Demircan
As always, if you have a specific reproduce case where something isn't working as expected, please report them as separate bug reports with precise steps to reproduce. We cannot fix what no one reports. But FWIW<,by any objective measure, 3.4 is far less buggy than 2.3 ever was. Sureliterally thousands of 2.3 bugs have been fixed. In the process, undoubtedly a handful of new ones have shown up. We fix these as people report them. So, instead of general complaints about things not working, the same amount of time would be far better spent actually reporting the specific bugs you are encountering.
In reply to As always, if you have a… by Marc Sabatella
I added this article to the "Development and Technology Preview" section; Not as a "bug report".
In reply to I added this article to the … by Ziya Mete Demircan
Indeed. But it doesn’t accomplish anything more there than anywhere else. We can’t do anything about bugs no one reports, no matter which forum one posts to while not reporting bugs.
In order to help you see how automatic placement and the other new features of MuseScore can save you enormous amounts of time, we'd need for you be more specific. Like, attach a sample score and explain a particular task you are finding hard. Then we can show you the easy way. :-)
As for breaks, I'm not understanding, they are actually far more flexible in 3.4 than in 2.3. Like, you can enter them while still in note input, you can enter them with a note selected, etc.
In reply to In order to help you see how… by Marc Sabatella
re automatic placement:
layout-wise I strongly prefer even stave margins on a page, but if there are, say, some dynamics at the bottom of stave 4 of a page and rehearsal marks at the top of stave 5 the vertical margin between staves 4 and 5 will explode due to automatic placement. Then I need to manually adjust all those elements to get a smooth overall layout of the page. I don't declare this as buggy per se, but in my workflow it is not as much help as I thought it would be, and in some cases I find it downright irritating. As an example, correcting some dynamics in a score may (or may not) cause layout changes in the individual parts. Some individual parts may not fit to one page anymore, and add a second page just for the last stave, all because of a crescendo sign.
re breaks:
that part of layout I do either before writing anything; say, transposing a simple lead sheet, as an example here I want a four measure grid first. Or, if I'm doing a piece for quintet, there is obviously the score and then parts are generated via file->parts, those then need individual layout with note writing already completed.
In both cases drag&drop the break elements seems the fastest way to me. Which has the described issues in v3.x, and none in v2.3; of course most of the time with second case, making a grid out of empty bars seldom causes trouble ;-)
In reply to re automatic placement:… by flomba
In that case, you can easily disable that aspect of automatic (increasing staff distance to avoid collision) by setting a negative value for "Min. vertical distance" in Format / Style / Score. So you can retain all the other benefits of automatic placement while still maintaining consistent spacing. Of course, that means you may have collisions, and you'll need to adjust to avoid them anyhow, but that was true in 2.3 as well. Anyhow, the point is, MsueScore 3 gives you the choice.
Changing position of dynamics in a score will never affect parts, however. Not in 2.3, not in 3.4. The only thing that does is actually changing which note the dynamic applies to, and in that case, presumably you'd want it to affect the part as well.
Regarding the breaks, I still don't understand, but feel to attach a score and describe in more detai. Drag & drop is never the fastest way to add - selecting something in the measure and hitting Enter or clicking the break in the palette is far faster. And as I said, MuseScore is far more flexible in this, as you can select almost anything in the measure and it works. And if the goal is consistent four bars per system, Format / Add/Remove System Breaks is faster still, both in 2.3 and 3.4. But even if you are resorting drag & drop for whatever reason, I'm not understanding what you perceive has changed. Dragging to absolutely anywhere in the general vicinity of the measure highlights the entire measure (across all staves) and dropping works just as expected.
In reply to In that case, you can easily… by Marc Sabatella
Surprise, I've never noticed that entry add/remove System Breaks in the Format menu, seems I've had a blind spot here, so thanks a lot for that one :-)
Still, dragging 'near' a measure won't work. I have to hit the rectangle of the measure defined by upper line, lower line and the bar lines. In 2.3, that's it; in 3.x the cursor and the highlight vanish as described when hovering over some written element in the desired measure (note head, rest, beam, whatever), I must hit an empty space of that measure to make it work.
If time allows I'll try your other suggestions this weekend or in another few days, be sure your help is really appreciated.
Thank you very much :-)
In reply to Surprise, I've never noticed… by flomba
You're welcome! I think you'll find these other methods improve things greatly. BTW, the add/remove breaks was in Edit / Tools for 2.3. But FWIW, I do see what you mean that while the drop zone is huge, it does exlcude the areas within the measure that have other element. Still, it's by far the slowest way to add breaks anyhow, which is probably why no one else has reported on this yet. Feel free to submit an official bug report to the issue tracker.