How to put pedal marks and lines between two selected notes.
Before I post this as an absolutely 100% you've-to-be-kidding-it's-not-there essential feature request, perhaps someone can instruct me how to put pedal marks and lines (rit., rall., accelerando, etc) between two selected notes, the same way you enter hairpins. I have hunted high and low and can't find either documentation for this or a shortcut.
Comments
If you mean, select the notes first then add the line, as opposed to add the line then adjust the length with shift+arrow, no it's not there. I don't see what could possibly be considered "essential" about it, though. Seems it would be at most a slight time saver. But feel free to submit the request. More significant, I think, would be a way to add these lines without requiring drag & drop. That's definitely being considered.
BTW, it's also fairly complicated to get right. Consider all the different possibilities - what if you select notes on different staves, an odd number of notes, range versus individual notes, etc. This method of entering hairpins only works correctly when selecting a range, not individual notes.
In reply to If you mean, select the notes by Marc Sabatella
Imagine you have a score in 4/4 with a passage 8 bars long composed of 16ths that have to be pedaled every 4 notes. By my calculations, that's 408 (51 x 8) Shift+Arrows to adjust the pedal marks' right anchors! I hate to complain, but the lack of the "slight time saver" is costing me hours upon hours of working time. The problem is worsened by the sluggishness of the Shift+Arrow operation. If I hit the combo 13 times in rapid succession, which should speed things up, I have to twiddle my thumbs for several seconds before the 13 anchor-shifts finish.
Programming issues aside, it doesn't make sense, musically, to assume that a pedal mark is always intended to run to the end of a bar, which is MuseScore's way of doing things. A composer/engraver naturally expects to be able to select the note for pedal-down, select the note for pedal-up, and add a pedal marking which sensibly runs the length between the two notes.
I'm not sure that adding "these lines without requiring drag&drop" is more significant, rather "as significant".
I'm glad you raised the "fairly complicated" issue, because it points to another liability, i.e. the very complication of which you write. As an example, consider a standard piano score with a whole-note chord in the base staff and a passage of 16 16th-notes in the treble. If one wants to add pedal marks every four 16ths, one has to anchor them to the treble staff because if one anchors a pedal mark to the whole-note in the bass staff, it is impossible to pull the right anchor back to a desired 16th-note. One then has to manually relocate the pedal marks to underneath the bass staff. The alternative is to have a hidden voice in the bass staff composed exclusively of rests of the appropriate lengths so that the pedal marks, when attached as one expects to the bass staff, have anchors in the bass staff.
Complicated to implement or not, the ideal would be that every note or rest, regardless of staff, constitutes a valid anchor point for any pedal mark (or other line)—again, regardless of staff.
BTW, Marc, congrats on the book.
In reply to Imagine you have a score in by Peter Schaffter
Thanks for the congrats :-)
Yes, I get that adjusting lots of pedal markings takes time. But, so does selecting the range of notes to apply to in the first place. And if there were a keybaord-driven way of adding lines, the process of adding the line *plus* the extension would instantly become faster than the current drag & drop method. As for the relative importance, it's an accessibility issue. Blind users, or people who have disablilites that make mouse usage impractical, currently cannot add lines at all. So it's the difference being entirely unusable versus saving a couple of seconds.
As for the initial length of a line - well, it has to default to *something*. End of measure is as good a choice as any, and I'd argue *better* than any other default one might propose in its place.
In any case, do keep in mind the primary purpose of MuseScore is notation, not playback. Very few scores would ever actually include all those lines - they would add a couple then say "simile", most likely. Improving a process that currently only takes, say, 5 seconds and making it takes, say, only 2 seconds, would literally literally *thousands* of such liens before you would ever save a single hour of your time. So I think you may be overstating the case. In any case, it is the fact that most people would never have reason to enter *nearly* so many lines that makes this not quite the "you've-to-be-kidding-it's-not-there essential" feature it might seem to you. For most people, it might save them a couple of minutes over the course of a year, tops.
BTW, the fact that pedal lines can't be added below the bass staff if no note exists on that staff has been raised as an issue already - see #15513: Pedal markings under grand staff can only be attached to notes in staff attached to.
In reply to Thanks for the congrats by Marc Sabatella
I've re-read your first paragraph several times and honestly can't see the point you're making. Could you re-phrase?
Respectfully, I disagree with your feelings about pedal marks. Let me try to convince you. (Arguments are not in any particular order).
I'm attaching a screenshot of one bar so you can at least empathize with my position. :)
I stand accused and guilty of being an exception. :) I can't imagine there are many users who push MuseScore quite the way I do. I confess that my last score, which you saw, and the one I'm working on, were chosen to see what 2.0 was made of. I expected the work to be labourious and painstaking because the scores are complex and pose a lot of notational (and playback) problems. But I expected the hard work to be where the work was hard, not while performing routine operations like adding pedaling. MuseScore 2.0 has risen AWESOMELY to every challenge, and I'm thrilled, but the pedaling thing means I have to give it a B, instead of the A+ it deserves.
In reply to I've re-read your first by Peter Schaffter
Let me try to rephrase my points:
My main concern is accessibility. We take it very seriously. Right now, Lines are perhaps the single least accessible aspect of the MuseScore interface. The need to use drag and drop makes them completely and totally impossible for people with certain disabilities (eg, blind users, also people who are unable to perform the drag and drop operation because of motor control issues. For these people, we're not quibbling over a couple of seconds here or there - the elements on the Lines palette are completely and totally unusable. To me, solving that is far more important than potentially saving a couple of seconds. But realistically, solving that *would* for them save time for the rest of us too. So to me, this is the no-brainer improvement that needs to be made.
Anyhow, I don't disagree that a way to select the range first for pedal and other lines would be useful. I think for *most* people, it would save at most a minute or so per month, but I certainly get that for you it might be more. But it's the fact that for *most* people, it just is not a big deal, that to me explains why we're not kidding you that this is not there already - it just hasn't seemed particularly important.
As for the default, I would disagree that per-beat makes more sense. I think "most" of the music to which "most" people would be likely to want to apply pedal markings only requires a pedal change once per measure, and needing to shorten the markings is more the exception than the rule.
Similarly, I recognize that *some* music requires more extensive pedal marks than just a basic guide at the beginning and the word "simile", but even though this might be 2015, the vast majority of piano music people simply does not contain such specific markings. 18th-19th century classical music and pop music are quite big, and in neither case are pedal markings that pervasive. Again, that said, obviously there are exceptions.
So once more, none of this is to say it isn't a fine idea. Realistically, it would only be a slight time saver for *most* people, because the sort of situations you describe just aren't *that* common. So I'm far more more interested in solving the basic accessibility problems. If that also happens to benefit the rest of us, great!
In reply to Let me try to rephrase my by Marc Sabatella
Thanks for taking the time to clarify. I thought that's what you meant, but I couldn't be sure.
No need to hammer home the "somes" and "mosts". I more than aware I'm colouring outside the lines. :) To my mind, not that far outside—I'm not trying to create a spiral score in the style of R. Murray Shafer–but I acknowledge I'm not in the "most" category.
Still, it's worth remembering that a great program meets the requirements of the somes while satisfying the needs of the mosts.
Again, thanks for responding to my questions.