Multiple-measure pedal

• Nov 9, 2017 - 21:00

I'm composing a piece for piano that involves holding down the pedal for two measures at a time, but when I try to add pedal notation in musescore and play it back, the pedal always cuts out after one measure, even when I change the length of the line to stretch across both measures. Does anyone know a way to fix this?
[UPDATE: I got the problem fixed. Thanks everyone who helped!]


Comments

My guess is you didn't add/lengthen the pedal line correctly - you probably just dragged it with the mosue which only extends it visually. To actually affect the meaning of the line, you need to either attach it to both measures in the first palces (eg, select them then double click the pedal icon in the palette), or extend it using double click then Shift+right. See the Handbook under Lines for more info.

Is there a necessary reason that this has cannot properly react to being dragged by the mouse? This behaviour has been consistent since very early in MS, but perhaps it should be changed to include dragging.

If I can remember that far back, it seems to me that it was much more intuitive to just drag it.

In reply to by xavierjazz

It is definitely worth thinking about this and other related questions and coming up with a consistent strategy. The thing is, we need to support fine tuning the position of the line (which is what dragging currently does, or cursor key alone while in Edit mode) and also support actually changing the anchor point (which is what Shift+cursor does). In cases where people added the line correctly in the first place - selecting the full range, then double clicking the icon - then the fine tuning is going to be by far the more common operation, so it makes sense for it be the easiest. Only in the cases where someone added the line incorrectly first (eg, not selecting the full range before double clicking, or using drag & drop, either of which requires MuseScore to guess the range) would adjusting the range be the more common operation. Basically, the current behavior favors experienced users but confuses beginners, a change would favor beginners but make things harder for experienced users.

We should also consider how this relates to other elements. Currently in 2.1, dragging most elements just adjusts position, and for the most part we all seem OK with that - only lines seem to cause confusion for some reason. But dynamics and slurs work differently, where dragging will actually change the anchor. Frankly, that drives me crazy, and I know it does others too - which is what I mean when I say changing the behavior for lines would make life harder for experienced users. But it would be nice to have a more consistent story here.

In reply to by Marc Sabatella

There is much to consider here.

As a start, I am interested in your observation "In cases where people added the line correctly in the first place - selecting the full range, then double clicking the icon - .....".

Even though I am a long time user I had no idea that that was the "correct' manner to do this.

It points to the many paths to the same result and to the complexity of the user interface including the difficulty of agreeing how to describe things.

On another note, given MuseScore's stated goal of providing a professional quality notation program I would vote for making it easier for the more expert. This is not to deny the need for making it as easy as possible for everyone.

Best regards,

In reply to by xavierjazz

Perhaps "correctly" isn't the correct word. Adding it "the best way" is to apply it to the entire range in the first place. Everything Marc said is true for all items in the lines palette. This is explained rather well in the handbook in my opinion. Both methods of changing the length of a line/hairpin are useful in the correct situation. I don't think this is an expert verses novice issue, but rather a case of reading the handbook when doing something new or uncommon for the user. I still refer to the handbook when doing things I don't commonly do.

Having multiple options on doing most tasks is normal in every program I've used. Most people will select a subset of the interface as use that. When they run into something new, they can usually find what they need in the handbook and always have the option to ask questions here.

In reply to by mike320

Good points, well stated.

I haven't read the handbook for a long time, but I shall reread it again, thanks.

In my case, I have found numerous "work arounds" to achieve what I needed but I am sure that many of these are clumsy compared to how MS works now.

I do think that the issue Marc raised, of trying to simplify access generally, whether novice or old hand is really important.

An idea that has come to me re: moving the anchor point or fine tuning the relationship between the anchor point and the symbol is, perhaps there could be a key/mouse scenario with, for example, "mouse-only dragging" adjusting the spacial relationship and, shift/mouse moving the anchor points, shift/mouse being an example, not a direct suggestion. If this is possible, that may help differentiate between the two states.

In reply to by mike320

Indeed, my use of the word "correctly" was unfortunate. I didn't mean "in the correct manner" but "attached to the correct notes". And indeed, prior to 2.0.2 (or maybe it was 2.0.1, I forget) it generally was not possible to attach many lines "correctly" in this sense - you had to attach them to a single note or measure first then adjust. The double-click method was only supported fairly recently.

In reply to by Marc Sabatella

I almost fully agree, except for the favor experienced users here.
The issue with lines (especially Volta) being dragged "incorrectly" pops up quite often into the forums. And for the specific case where I do need to change the visual position of a (part of a) line so much that it would no longer "line up" with it's anchor point, I'm experienced enough to use the inspector.
Eyeballing that stuff only guarantees me that I won't have a consistent result throughout my scores.

So my opinion here is that we should favor the beginner with the intuitive drag-and-change-anchor, experienced users are more likely to know of and use the inspector anyhow.
If enough experienced users (or just you :-p) do wish to be able to drag for visual changes only, then as xavierjazz proposed in his latest post, I'd think using a modifier key makes more sense. (Ctrl-drag would be my proposal then)

In reply to by jeetee

@jeetee... you wrote:
The issue with lines (especially Volta) being dragged "incorrectly" pops up quite often into the forums.

How true that is...
When I discovered MuseScore (ver. 0.9x), and its WYSIWYG 'intuitive design' (what novice uses the handbook! 😂), I tossed my pencil/eraser - for notating lead sheets - and started using my computer keyboard for note entry, and my mouse to happily drag stuff, especially volta lines, to 'look good' for printing purposes. After all, what you see is what you get (WYSIWYG). Occasionally, I did use the 'piano only' playback to confirm the pitches; and, to save time, the 'play repeats' function was turned off.
It was only until I became involved with the forums (and turned 'play repeats' on) that I discovered this issue with lines, anchor points and their effect on correct playback.

Regards.

In reply to by jeetee

I'm not necessarily opposed to favoring new users either - I would just like to do so in a way that doesn't actually make life harder for more other users. I almost never use drgging for this, or anything really - I'm more likely to use the keyboard for fine adjustments. But I do see people trying to drag dynamic markings and being surprised and annoyed by how this changes the anchor and I'm concerned about making that problem worse by adding to the list of things that might change anchor when all you are trying to do is make a fine adjustment. So I'd just like to see a good overall plan in place that ends up being reasonably intuitive for beginners but still easy to use for more experienced users, and both of these things imply some more consistency than we currently have. If dragging dynamics and lines changes anchor, should this be true for staff text too? Articulations? Clefs?

In reply to by Marc Sabatella

A couple of people have talked about fine tuning lines and hairpins using the inspector. Unless I'm missing something, the inspector lacks the facilities to adjust for example a decrescendo. It is fairly common in Classical music for the decrescendo to be placed on the the last beat or two of a longer note, such as the last two beats of a whole note. This is a picture of one complete measure of a score I am currently transcribing.

late crescendo.png

I placed the decrescendo on the bottom line under the dotted 1/2 note. The only way I know to shorten it is to either drag it or use ctrl-right arrow. As I stated before, using ctrl-drag to resize a line (without moving an anchor) is very acceptable. In fact it is actually more consistent with using ctrl+arrow to resize it.

In reply to by mike320

This is indeed a consistency issue. The Inspector can be used for some fine tuning of lines, but it is seldom what you want. OPn the other hand, it is exactly what you want for dynamics and other markings.

For hairpins, I am finding the best approach currently to be to used an invisible second voice full of rests so I can anchor to arbitrary metric positions within the bar. I like this because it will do the right thing as layout changes, and will also do the right thing with regard to parts. But it's a pain, so I only do this when the task is big enough to warrant the extra work. If it's just a matter of starting a crescendo right after a dynamic marking on a whole note, it's not worth it to me - I'll do the manual adjustment and repeat as necessary in parts. This much at least MuseScore promises to improve. But for the more general case where you might want hairpins starting and ending at arbitrary positions within the measure, I wonder if allowing hairpins to work more like chord symbols, where we have shortcuts to advance to the next beat etc even if there is no note, would be the best way to handle this. In principle it's possible, and might not even require any incompatible changes to the file format, although I could be wrong about that.

Anyhow, these are all the bigger picture concerns I'd like to consider before jumping into anything.

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