Some features from MuseScore 1.3

• May 25, 2015 - 04:12

So far I'm pretty satisfied with MuseScore 2.0, but there are some features which didn't translate smoothly to the new version. The following list contains bugs and missing features, so I had to choose a section. It should help improve MuseScore.

1. Superscript: It isn't really "super"; it puts the text somewhere in the middle.

2. Centering text (not page layout, but inside a text box): It would be nice to have this feature back insteading of creating a new textbox and moving it manually. Maybe it's hidden somewhere and I can't find it.

3. Zooming with mouse wheel + Ctrl and dragging the sheet around with mouse click simultaneously: This still works if you hold the mouse button first. However, I usually need to press and release it several times because the pointer reaches the edge of the screen. The second time I use the mouse click, moving the sheet is not possible. The already pressed Ctrl key prevents this and you have to release it before doing anything else. This was not limited in MuseScore 1.3.

(4. Overview of all pages: There used to be a bar you could pull from the bottom which gave you an overview of all pages and helped you navigate.)

(5. Opening a 1.3 file which was extracted from a MIDI file: When you extracted the score from an original MIDI file In MuseScore 1.3, instruments would be simply empty (not even rests) after their last notes (while other instruments continued). If you open a file like that in MuseScore 2.0, the score is corrupted and detects mistakes in those empty bars. You obviously can't fix empty bars with the suggested guide online. The only way would be to copy all voices with notes and paste them in new bars with rests. I wish MuseScore 2.0 would put the rests automatically, but I know this is something very complicated. This is not a big issue for me since I have already transferred all scores to 2.0.)

6. Note stem doesn't move: If you need to move note heads due to space reasons, the stems don't move along. Maybe someone doesn't want that if they want to create some crazy-looking scores, but the default setting shouldn't be that. At least make it possible to move stems horizontally with the double-click edit mode otherwise you need to open the inspector every time.

7. Disappearing articulation signs: This issue was known in MuseScore 1.3 too. If you move articulation signs too far from the note, they disappear. If you zoom out, it becomes visible again, but you can't select the sign again unless you reopen the file. You can prevent this by moving the sign in bits (enter and quit edit mode several times), but sometimes you have to stop when the sign is covered by the note. Then it becomes unselectable (selection filter doesn't help). So you need to be careful.

(In addition to fixing the problem itself, you can also reduce the situations in which we need to adjust articulation manually. If you use X to turn the marcato/staccatissimo sign, it would be more sensible to not only turn the tip but also the placement (top to bottom and vice versa). This is already implemented with the fermata sign.)

8. Decreasing stretch: If you decrease the stretch too much, the notes overlap. I know there is a limit, but it seems that MuseScore 1.3 allows more stretch decreasings before it becomes a mess. I discovered this when I compared the same score in both versions.

9. Style-General-Accidentals-Naturals in key signatures: There are situations in which I don't want to see the naturals even if it changes to C major/A minor. There should be another option. You can't use the right mouse button to properly hide naturals anymore. Setting them invisible often result in unwanted spaces.

(10. I attached a file to visualize several above-mentioned problems. Having set the naturals in the treble clef invisible, I added a bass staff, which still shows them, however. If I set them invisible too, the naturals in the treble clef become visible again.)

11. If two voices share the same notes but have different values, there is a considerable gap unlike in MuseScore 1.3. I know this is a preference, but I have never seen this in published works. The default setting shouldn't be like this. Options in style preferences would be nice.

(12. Voices don't align with each other automatically: Maybe a result of number 12. The note in the bass clef should align with either voice 1 or 2 in the treble clef, but now it's in between. This doesn't happen in MuseScore 1.3.)

13. Precise placement of text: When you move dynamics, a reference line appears. This should happen with normal text too. You could go further and show a right angle when a text box aligns perfectly with something (90°). Or something else as a reference like a grid or ruler. So we wouldn't need to use a real ruler.

14. I only know staccatissimo as a triangle-shaped sign, but in MuseScore it looks like a drop of water. Maybe you can add a option like the different note heads we can choose.

Thank you for reading this and keep up the good work!

Attachment Size
Bugs and Features.mscz 17.81 KB

Comments

ad 1. that one wasn't using superscript. select, Ctrl-A and use the superscript icon in the text tool bar (bottom left corner of screen

ad 2. center to what? title and sub title are centered to page, composer is right aligned. You can certainly center it too, but it'd then clash with subtitle. I guess you want the 2nd line to center to the first, right? That indeed doesn't work, use trailing spaced

ad 4. you can get the Navigator back my using the View menu or pressing F12

ad 5. those score most probably were corrupt in 1.x too, only 2.0 detects that corruption. To fix select the last intact measure, 28, shift click the last measure, swap voices 1 and 2, delete the voice 2 rest in measure 28

ad 6. works the same as in 1.3. Hmmm, maybe now for chords (or more than one note)?

ad 7. they do move when using x, so I don't see the problem

ad 9. select, hit 'v' or use the inspector. Or right click and check courtesy signature or, again, use the inspector

ad 10. select only one of them using shift click, then v

ad 11. this is a feature, in 1.x they were too close toghether to tell them appart

ad 12. this too is a featuire, in 1.x seconds in voices overlappend

ad 13. use the inspector rather than dragging things around. a 'snap to grid' is available there too

ad 14. check the symbols palette in the master palette, I guess you may find that symbol there

In reply to by Jojo-Schmitz

1. The "st" in "1st" was already superscript.

2. It is common to put the dates centered under the composer. This was possible in 1.x when this feature was still in the bottom left corner.

6. Yes, it happens if there is more than one note.

7. The signs are turned, but they don't move to the opposite end.

9. If you check courtesy signature, the naturals just move to the end of the previous bar. Updated in new file.

11. You don't need to tell them apart because it's the same note. Besides, you know that the stem going up belongs to the quarter note. I don't ask you to change this back. Just an option with which you can change the default gap would be sufficient.

12. One voice must align with the bottom even if the other voice is off. Having them in between as a compromise goes against the customs.

13. Can you please tell me what the snap-to-grid does? I enabled both of them, but I don't see how they work.

14. There is no variation of the staccatissimo sign in the master palette.

Attachment Size
Bugs and Features2.mscz 14.38 KB

In reply to by Pian O

ad 1. Ah, that one... it is still higher in superscript than without
ad 2. OK, it indeed was, never used nor noticed that.
ad 6. could well be a bug, not sure
ad 7. they do if set to auto rather then above, the 2nd fermata does not move automatically, as it too is not set to auto
ad 9. you could use the 'no key sig' instead?
ad 11. no, it is not, it is a different length. You can force them to overlap by changing the not head type of the half note to a quarter. Then you do lose the ability to gel the lenght of these notes apart though.
ad 12. seconds should not overlap, this was a bug in 1.x that got fixed. Also you increased the distance by an additional 0.4 space
ad 13. if enabled you can move elements only in certain incremtents
ad 14. this should mean that this sign is not part of SMuFL

Thanks for your comments! For future reference, it's better to start separate threads for separate issue - maybe grouping a few related ones together. Otherwise threads quickly become very difficult to follow. But I'll try to respond point by point.

1) I agree, you should file an official bug report to the Issue tracker (Help / Report a bBug)

2) Centering text can be done via text style or text properties.

3) I don't understand what you mean. Zooming works fine for me. So does moving the score. These are two separate activities; what does it mean to do them "simultaneously"

5) If you have a MIDI file that produces corrupts once loaded into 2.0, that's a bug. Please report it with the MIDI file and steps to reproduce. But it sounds liek the bug was actually in 1.3, which created the corrupt score but just didn't warn you about it like 2.0 does.

6) The wonderful thing about the Inspector is that you don't *have* to open and close it. You can leave it up all the time. Or, if you prefer, it *can* be opened and closed via keybaord shortcut which automatically transfers focus to it as well. So it's a much more efficient way of making adjustments - especially for chords. But aside from that, 2.0 includes a large numebr of very signaificant layout improvements such that is virtually never necessary to adjust positions of notes any more to achieve the correct results. See 11) and 12) below, for example.

7) I can't reproduce any problems with dragging articulations. If you have a specific score and a precise series of steps that show a problem, please report this as a bug to the issue tracker. You are right that only a few symbols automatically change from note head side to stem side. That requires special case handling - how far above the head, etc - so it's only implemented for the signs most likely to be flipped. If you have specific cases you'd like to see added, feel free to file an official feature request to the issue tracker, preferably with examples from published scores to help us understand the need for the function and how it should work.

8) 1.3 definitely had bugs that allowed one to easily shoot oneself in th foot by reducing stretch too far. 2.0 shoudl be better in that respect. It also provides more Style options to control different aspects of note spacing. If you have a specific score where you feel you were able to accomplish something in 1.3 that you are having trouble figuring out how to do in 2.0, that's definitely worth a separate thread, with sameple score and precise steps to reproduce. Chances are it is still possible, but might requie you to change on of the new Style settings.

9) I don't understand what situations would exist where you want a change to C major but don't want to see the naturals. Perhaps you are referirng to different movements of a work? The new Section Break facility is designed for this. If you have a use case in mind that is not handled by the Section Break facility, this too seems best suited to a separate thread with real world sample score.

10) Note that "V" is a toggle, so anything in the selection currently visible becomes invisible and vice versa. To set everything visible or invisible regardless of the current state, use the Inspector.

11) This was a bug in 1.3 that is fixed in 2.0. It is incorrect not to show space in this situation. FYI, the definitive reference used by most publishers and music notation software today is Elaine Gould's "Behind Bars". We follow these guidelines very closely.

12) There were bugs in this area too that are fixed in 2.0. The rule is, the non-offset notes should align, independent of which "voice" they are in. But in your sample file, you inappropriately applied a horizontal offset to the first note. Reset it to 0.0 and that is the correct alignment (which I now see you have already discovered).

13) While a grid could occasionally be useful,. it really isn't needed at all for text. Simply use the Inspector to move all selected texts at once, or by the same amount. Also, the new text style facility allows you to change the position of all elements of a given type at once. The ease with which you can align elements in 2.0 comapred to 1.3 is one of the great things about 2.0.

14) Are you sure? Did you check the "Symbols" section? It's enormous, and it's easy to miss things. But FWIW, rather than providing different options for individual symbols, the usual way to handle this sort of thing would be to choose a different music font in Style / General where the symbol has the shape you want. 2.0 supports three different music fonts: Emmentaler (the default, the same as 1.3), Bravura (the open source font that provides most of the glyphs found in the Symbols section of the Master Palette) and Gonville (another font contributed to the MuseScore project). Looks like Gonville has the more triangular symbol you apparently prefer (I am much more accustomed to the version in Emmentaler & Bravura).

In reply to by Marc Sabatella

I thought it would be too much opening many topics at once.

2. I can go to Style-Text-Compser and set the alignment to the center. This puts the text in the middle of page. I still want the text in the top right corner, but with the text inside centered. You could change the alignment within a textbox in MuseScore 1.3.

3. Hold Ctrl and try to move your sheet with the left mouse button, it won't work. You have to release Ctrl first unlike in the previous version.

6. I've been transferring scores to MuseScore 2.0 lately, so I don't know what it's like to work with 2.0 exclusively. However, the fact that the note stem doesn't move along when you adjust the note head (if it's a chord) is a bug.

9. Thank you, the new section break function does indeed solve this. I often have some short passages put together in one score and don't want to see key changes and naturals at all because it's not one single piece.

10. I didn't know that you could use Shift + click. Problem 5 and 10 are solved with this.

14. I looked in the "Articulations & Ornaments" section, that's why I didn't find it. Thank you.

In reply to by Pian O

Yes, it is good to be concerend with flooding the forum with lots of threads. Posting issues as you encounter them is the best way to go.

Anyhow:

2) OK, I get what you mean. The way to do this in 2.0 is with a frame within a frame. It's slightly more work for this particular special case, but should be more flexible overall.

3) I don't understand what Ctrl has to do with moving the score. As far as I know, it was never meant to work that way. I can see that it happened to work in 1.3, but I suspect that was more an accident than a feature. I don't understand of having two different ways of doing the same thing, but if you have some sort of use case, this too is worth a separate thread with more explanation.

6) It's not a bug. One of the improvements in 2.0 is more independent control of the various parts of a note (head, stem, flag, beam, etc) if you want it. If you don't want that independent control, then don't move the parts separately - use the Inspector. That is what it is for. I think because the Inspector is new, you may not be realizing how fundamental it is to how adjustments are made in 2.0 and aren't taking full advantage of it.

In reply to by Marc Sabatella

3. It's not having two different ways of doing the same thing. The left mouse button is used for moving the sheet around. Ctrl + mouse wheel was for zooming. I liked to use both together to navigate. It was fast and practical.

You zoom out. Everything is smaller, so moving the sheet is faster. When you are done, you zoom in to the bars you wish to change. In MuseScore 1.3, you wouldn't need to press Ctrl again when zooming in because you would hold the key since zooming out. Now it has to be interrupted as moving the sheet while Ctrl is held is not possible. If there is no reason to block the left mouse button from moving the score while Ctrl is hold, it would be nice to have it back.

6. I just found out. Thank you again.

In reply to by Pian O

OK, I get your use case now. It would never have occured to me to try perforning those operations in that sequence - I don't use zoom as a navigation tool. And I guess I still don't see how having to lift your finger off the Ctrl key is a hardship. And yes, this *does* count as two ways of doing the same thing - because the normal supported way to drag the score is drag alone, not Ctrl+drag. Ctrl+drag has a new meaning in 2.0 - it is how you constrain drag operations to be horiztonal only. But it also continues to have the same function it did in 1.3 - not of dragging the canvas (which was purely an accident, I would bet), but of retaining a multi-selection when initiating a drag. So you are not only asking for there to be two different ways of dragging the canvas - drag and Ctrl+drag - but you are asking asking for Ctrl+drag to have a *third* meaning in addition to the two it already has. I'm not crazy about that either.

That said, there is definitely room for improvement in how the dragging actions work. Right now, drag already does two different things, depending on whether you grab an empty area of the canvas (moves canvas) or a score element (moves element). This has caused complaints because soemtimes you mean to do one but actually do the other. Shift+drag also does two different things depending on the same factor - selects a region if you start on an empty area, moves element but constrains the motion vertically when moving a score element. Ctrl+drag also currently has two different functions as mentioned above.

I think there should probably be a re-thinking of how this all works to make things more consistent - but once again, it should really be the subject of a new thread.

In reply to by Pian O

I have to thank you for pointing out the CTL+wheel zoom thing; that's either a new shortcut for me, or one I'd forgotten. Either way, it's useful, so thanks.

Perhaps I can return the favour by pointing out (if you don't already know) that SHIFT+wheel scrolls pages horizontally, so you can move quickly right & left without having to click and drag anywhere. You can also of course, move up & down with the wheel alone, not holding down shift. But I think everyone knows that because most programs work that way.

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