Drag rests like notes?

• Mar 12, 2024 - 08:10

Hey guys,

MS 4 is fantastic, but one quirk I've noticed:
When a bar starts with a note or chord, you can drag it horizontally to add leading space (to add a chord symbol, Segno, text, etc.).
But try that with a leading rest, and it floats freely, leaving the rest of the bar unchanged.
In these screenshots, I've dragged the leading G to the right to add space for the chord symbol. But when I dragged the rest, only the rest moved—and its movement isn't even constrained horizontally, as the note's was:

MS_rest_drag.png

In fact, rests behave this way, everywhere.
It can be "gotten around" by temporarily making the rest a note, dragging it, then restoring it. But is this intentional behaviour? Why? Thanks!


Comments

Better add an x-Offset to the Chord symbols or the rehearsal mark. Actually I wonder why colission avoidance doesn't work here?
And really dragging notes horizontally should be forbidden/disabled, there too it should be done via their properties and there only

In reply to by cadiz1

Guys, I'm guessing you don't work with multiple scores under intense time pressure, as some of us do.

Simply being able to move rests horizontally, as one can notes, would be vastly quicker and easier than:

  1. Opening a palette

  2. Selecting an input box

  3. Clicking an "up" or "down" arrow any number of times, and or typing estimated values into the input box, which may or may not need re-clicking and/or adjusting to move the rest the actual distance you want

...each time we just want to, you know, move a rest in a normal, non-exotic way.

This also requires one to remember that rests behave differently this way than notes. Which I never do—so you can add an "Undo" command to the list above. 😄

There didn't seem to be any reason for this inconsistency, so I always assumed it was an oversight rather than an intentional "feature". Under normal circumstances, why would anyone want to "freely" misalign a rest with everything else? (On the rare occasions when that might actually be desired, couldn't those people use the "Properties" boxes?)

Anyway, this behaviour continues, and I don't understand why. Maybe you don't either, but thanks for trying to help.

(Sorry it's taken me so long to get back here about this, too—I'm finally catching up!)

In reply to by bobjp

"There didn't seem to be any reason for this inconsistency, so I always assumed it was an oversight rather than an intentional "feature""
Your arguments are valid. There is nothing stopping you from requesting this feature on GitHub, here: https://github.com/musescore/MuseScore/issues
On Github, images will be attachable as on this forum. However, if you want to attach an .mscz file (very short...a few measures), you will need to zip it.

In reply to by bobjp

Sorry—but every page (every measure, for that matter!) of music is different, and I've been used to dragging notes right and left since notation software appeared that supported mice.

And again, it seems pointlessly wacky to be able to drag notes with impunity, but have rests flying all over when you try the same thing. (Because they don't have names? Or what?)

Telling people "don't drag anything" reminds me of the joke about the guy who goes to the doctor and says, "It hurts when I do this!", and the doctor replies, "So don't do that!" 😄

In reply to by bobjp

"With impunity"? I'm just referring to adjusting your score's appearance as you wish.

MS's auto-spacing is great—but nothing's perfect, and I'm sure I needn't mention that any notation app's default spacing can sometimes create scores that look pretty amateurish. Maybe that'll change as they become AI-assisted—but for now, we peeps still have a purpose. 😊

In reply to by Andy Fielding

I was just quoting you.
Ah, you mean the AI that uses wrong verb tense, and often terrible sentence construction, is going to make sense of notation?
There can be a difference between making a score look as you wish, and having the score correct. I'm not saying MuseScore spacing is correct. I suspect everyone's opinion on correct might be a bit different.

In reply to by bobjp

Oh, LOL, Bob, you're right, I did say that. Well, somebody has to quote me now and then, I guess! 😊

Re AI using wrong verb tenses, etc.: I don't know which ones you chat with, but those I consult (Google Gemini, Microsoft Copilot, Pi.ai) are always teaching me to write better—and I'm a technical writer with decades of experience. 🤷‍♂️ But that's beyond the scope of our topic.

All I'm saying is—and as I'm sure you realize—every page of music is different, which is why one can't apply rigid rules to notation but must approach them more holistically. And that's a kind of thing AI, once adequately "trained" on examples whose comparative subtleties it's been able to analyze, can be particularly good at. I can't speak for everyone—but as good a notator as I consider myself, I'd be quite pleased to have an "AI, check my score" button that opened a dialog box where I could step through and actually discuss its recommendations.

And of course you're right, that everyone has their own idea of what "correct" notation is. But assuming one's prepared to disagree with it when necessary (as one should be, with anything esthetics-based), I can't see it as anything but positive, especially considering some of the fundamental oversights I see at MuseScore.com. (And I hope I don't sound snobby or elitist by saying that; it's not my intention.) Cheers!

In reply to by Andy Fielding

And it reminds me of those Word users who insert a paragraph mark at the end of every line in their texts as a line break, and then wonder why their lovely Word doesn't support justified text?

Of course, every bar in music is different, but the whole point of computer-based music notation is that the computer adjusts the formatting of the music, so that each bar has its own size and each line has the appropriate number of bars. That's what makes a good music notation program stand out. Using the mouse to push bars together or stretch them is Stone Age technology.

In reply to by rhalstenbach

Ehhhhhhhh, I can't agree with you here. I have great admiration for the degree to which MS puts things where they make sense. And if I do nothing to the layout, it's pretty good. But I have some quite specific visual standards that MS will not give me without some tweaking — nothing like your self-defeating analogy here, just plain it-ain't-quite-right tweaking.

Here's an example: In Screenshot 1 — the sax part — to m10 have been attached a Segno, rehearsal mark, and system text (RHUMBA). They're all there, but the segno is off the margin, and "RHUMBA" is too close to the chord symbol for my taste. I guess I could live with it — although I'll lose part of the segno on my iPad.

So let me push the RHUMBA marking up a bit by hand. Two things happen: 1) The marking jumps up to the previous system AND/OR 2) a second marking gets added below the original system (see Screenshot 2). Now, I got rid of the second marking, but look at what happened to the score in Screenshot 3. Right, of course: the marking jumped up to the previous system. But just TRY and tweak that in the score and it becomes clear that it's impossible to do so by dragging. It jumps up to the previous system and becomes tethered to a different measure and/or staff.

As you can see, I was able to drag the segno & rehearsal mark by hand without complication, but in other situations I've had similar results to what happened here with the system text.

YES, I can do the tweaking by adjusting the offset in Properties — which is what I do now, usually — but why should it not work both ways: either drag or adjust the offset? Why when I drag should the element get tethered to a different measure? If I had entered it incorrectly to begin with, I would simply delete and tether it to the correct measure. That's maybe 2% of the tweaks I find myself doing ("Oops, I put that in the wrong measure!" I realize, and I fix it). The other 98% of the time, MS needs a little help. It just refuses to admit that it was wrong. "NO! You must be mistaken. You must have wanted that element in the previous system!" it tells me. In this case, I don't know if the AI is too smart or not smart enough, but it's not behaving sensibly.

Attachment Size
Screeshot 1.png 44.16 KB
Screenshot 2.png 48.72 KB
Screenshot 3.png 171.83 KB

In reply to by tombersax

> that it's impossible to do so by dragging. It jumps up to the previous system and becomes tethered to a different measure and/or staff.

1) In many cases, it is sufficient to disable automatic positioning for the element. You have to try it out.

2) If that is not enough and you do not want the anchor to jump automatically, do not move it with the mouse, but via “Appearance” and the values offered there in the dialog box. The anchor jumping is only one option activated via mouse move.

In reply to by Jojo-Schmitz

Yes, I've recently discovered that nudging in the properties menu usually works better than dragging – for text, DS signs, rehearsal letters, etc. But why is it that the design does not allow one to just grab something and drag it – such that when you move it, the offsets are adjusted automatically? Like the same thing would happen to the definition of the element, except that the control point could be either the properties dialog, or just grabbing the darn thing and dragging it.

This is how things work when editing graphics in Pages, for example. It also works that way in Sparkle, the website-building app. Would such an upgrade be possible here?

In reply to by tombersax

Upgrade, or fixing an oversight? Again, I can't imagine why it'd be intentional. Avant-garde notation, possibly... But in such relatively uncommon cases, couldn't it be selected and "Auto-place" be cleared? (I have a single-key shortcut for that, BTW, and recommend everyone do.)

And I'm not mentioning this to be picky, guys. It doesn't happen often. But when it does, stopping to change a rest to a note, dragging it, then changing it back to a rest seems like an interruption to work flow that we could do without. (And each time it's happened, I've wanted to ask about it here, but was too busy. 😄) Thanks for considering it, oh great MS devs!

So I went back to your original post and images. You're right, if the measure starts with a rest, the spacing is off. I suggested not dragging anything because you seemed to think there was a problem. I don't much care about spacing because I don't publish my scores.
So I tried it myself. I set up a measure as in your image. I had no trouble dragging the G note right. I was also able to drag the rest without problem.

In reply to by bobjp

Yes, of course "the spacing is off"—that was my point. I was showing how you can't drag a rest left or right and keep it horizontally constrained, or have the rest of the system adjust accordingly, as you can with notes. Rather, the rest is free-floating.

It'd make sense if this happened when dragging it vertically, as we often move rests vertically to compensate for spacing in multi-voice staves. Horizontally, though, I don't understand why it should behave any differently, and it wastes time having to temporarily change it to a note, drag it, then change it back.

bobjp> I suggested not dragging anything because you seemed to think there was a problem. I don't much care about spacing because I don't publish my scores.

I don't think it's about "publishing", Bob, as much as it is about preparing one's scores the way one (and one's client, if relevant) wishes. If the floating-rest thing is indeed an oversight (and if it's not, I'd be interested to know why), it'd save considerable time to fix it.

bobjp> So I tried it myself. I set up a measure as in your image. I had no trouble dragging the G note right. I was also able to drag the rest without problem.

First, it wasn't about dragging the G, or any of the other notes, just the quarter rest. And I've just tried dragging a rest again, in the current MS version (4.5.2-something), and it still moves independently—as if it was, say, text that could be placed in any of several horizontal positions relative to the music and still make sense. So that's what I don't get.

In reply to by bobjp

Sorry, you've lost me... I'm just talking about consistency in programming and object behaviour, and not needlessly interrupting one's work flow.

If you or others want rests to behave differently from everything else when they're dragged, that could remain an option for you. But it's behaviour I've never seen in any of the other many notation apps I've used.

I'm afraid I don't have any more time for this topic. I've expressed what I meant; it's up to everyone else to do what they will with it. Cheers!

In reply to by Andy Fielding

Rests ARE different to notes. If you move rests vertically, its still the same rest. If you move a note vertically, it is transposed, its not the same anymore.

Therefore they behave not the same when moved, but as well the rest as the note keeps their attributes. A G remains a G, a quarter rest remains a quarter rest. Not so unlogical.

Take it or leave it - as we say in Germany: "Einem geschenkten Gaul schaut man nicht ins Maul". There are plenty of professional score editors out there, feel free to pick a better one.

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