Allow pedal hooks to attach when custom horizontal spacing has been utilized
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
The user may want to put the hooks of pedal marks not on a particular note but slightly after (before another note). This is easily achieved via CTRL+R/L or dragging with mouse, yet the problem is that if there's another pedal mark to be following, its being placed will be assigned to the default position rather than that custom positioning of the previous mark. This should be updated so that instead of this, for instance:
this would be the result without having to do anything extra:
Comments
M. Sabatella suggested some context for this. The use case of slightly shifted pedal off/on hooks is merely to emphasize that the player is to lift off pedal after the note has played, not during note-activation or before. This would appear to be decent default practice to begin with for a player, but the notator should be able to emphasize something like this by explicitly moving the hooks, and they may do this by extending the terminal point of the line. The only problem here is the difficulty in connecting to a following pedal line with a hook/hooks. They aren't magnetized toward each other, but rather with the notes to which they are attached. It's just a suggestion, but the opinion here is that pedal lines should connect with each other and not in mere appearance as it stands but like in a magnetic sense: when they are aligned with each other, the following one moves along with it (almost like how a dynamic mark moves along with a crescendo hairpin under given circumstances). Maybe it's a bad idea? It seems decent over here.
But unless I'm misunderstanding something, what you describe - pedal change after note - is the interpretation all pianists already know and use for the standard notation, where the bracket is directly under the note.
If you create something different from the standard appearance, the logical conclusion for the player is that you want him to do something different from what they already normally do. Best case is you'll confuse them but they'll assume you simply didn't know what you were doing; they'll try their best not to be thrown off but will likely be a bit more mistake-prone than usual. Worst (and not unlikely) case is they will notice the non-standard notation and attempt to guess what you mean, whatever and they guess you might have meant would be wrong since you actually just mean the standard interpretation; thus they will go out of their way to do something different and thus wrong.
I'm not sure MuseSciore should be in the business of making it that much easier to create one particular non-standard notation. After all, it's just as likely that someone inventing their own notation would actually want something like your first picture.
Am I missing something?
Right, but what if a composer wanted pedaling to be mid-way in a stream of notes? So instead of right after note performance, how about a dotted half-note with a quick damper shift toward the end a little before the next note? This isn't so non-standard in that it's merely an attempt at directing a hopefully precise position of pedaling, often accompanied with things like half-pedaling which may easily be used not in the standard sense of right after a note is played.
Doing something like this:
![pedal.png]( "pedal.png")
shouldn't be too confusing to someone, and to facilitate the ability to do something like this doesn't seem off the mark with a notation editor such as MS. As it stands, the alignment isn't so easy compared to, again, the way MuseScore facilitates crescendo lines connecting in with dynamic markings.
In reply to Right, but what if a… by worldwideweary
As a professional pianist, it would confuse me. But then I don't specialize in experimental notated music.
Anyhow, my point stands: this is an extremely rare non-standard use case, and offhand I see no reason to expect your particular experimental notation would be significantly more common than another experimemtal notation for which the current behavior is more efficient.
In reply to As a professional pianist,… by Marc Sabatella
Ok. Next time this style is come across, will just have to wing it with using the mouse as a means to modify the terminal points.
Well the mouse won't be very precise, far better to use the keyboard to guarantee the same non-standard shift on both sides. Still not clear when this ever comes up though.
That's one of the problems, Marc. They don't align well using keyboard only commands such as CTRL/SHIFT + Direction, and the mouse is indeed very much difficult because of the non-snap like behavior. To illustrate, here are some notes with pedal marks added to each of them with default positioning:
![ped_1.png]( "ped_1.png")
![ped_2.png]( "ped_2.png")
It is easy to link these up, just SHIFT+RIGHT the first pedal marks of the measures and they connect in like:
For most use cases where they align on the notes themselves, this works very well so far.
If for instance the first pedal markings of the measures don't extend to the next note but are about only 3/4 by Shift+Lefting their right end points before the next note, e.g.:
![ped_3.png]( "ped_3.png")
Then taking the second pair of pedal marks and trying to shift+left will over do it by bringing it to the beginning of the measure, so the user can use Ctrl+left instead, but that more often than not doesn't align. With the previous example, doing so results in this:
![ped_4.png]( "ped_4.png")
And hence the requirement to attempt by mouse to align the hooks (often requiring a zoom in), unless there's something missing in the method not being utilized.
P.S. Let's just say I've had to deal with some pretty weird scores lately.
In reply to That's one of the problems,… by worldwideweary
Attaching the actual score rather than a picture would help. Not sure why you're trying to mix the shift+right/left method for creating standard markings with your non-standard experimental notation, but it should work just fine to stick with one or the other. If you want to line up normally, use shift+left/right only. If you want to line up at some arbitrary other non-standard arbitrary location. Use plain right/left to move points 0.1sp, or with Ctrl to move by 1sp - same as any other manual adjustment. So start with the two segments aligned, then move them both by the same amount. E.g., one Ctrl+left and three plains lefts to move by 1.3sp - do this to the end of the first segment and the start of the next, and they will continue to align perfectly. If it isn't in your particular score, something else must be going on.
Yeah, non ctrl/shift arrows will work, though it seems faster at times to use the mouse when dealing with 0.1pt edits. And it may be a little unfair to describe applying pedaling half-way between one note and the next as arbitrary, as the pedal markings could be deliberately placed for that purpose for performance instruction, but sure, otherwise stick to convention (as usual...)
Suppose the suggestion can be shut down to have the pedal markings be snappable so that they move in conjunction when using ctrl/shift/regular+left/right, especially when using a custom offset (or even without, as they still don't connect to move in conjunction), but it seemed like a decent idea to speed up the process.
I can't see how having to zoom and fiddling with the mouse could be faster than a handful of presses of Right arrow, particularly given that the whole goal is to line up two different elements, so you'll have to make the exact same adjustment twice (mouse could be faster if it's only on adjustment that doesn't need to align with anything). But you are free to make that choice.
If you had some evidence that this is anything but a time event (one person working on one non-standard experimental score) but is something of general interest, that would certainly raise the priority here. As I said, I still have concerns that there might be just as many cases where the current behavior actually works better for some other non-standard experimental notation. If this were an easy/safe one line change, it might not matter. But it's a much more significant change to have the layout of a pedal segment suddenly have to start depending on the layout of other pedal segments (and this happens in an entirely different place in the code than the vertical alignment of segments on a system). So it doesn't come without effort or risk or the downside of breaking someone else's equally rare use case. Still, if the evidence surfaces that this really is a good thing to do in general, it's good to have this issue logged.
In reply to I can't see how having to… by Marc Sabatella
I still don't see how having pedal marks being linked with each-other when applied to the same note so that they move in unison when a user applies a custom offsetting with mouse/keys should be considered potentially causative of incorrect behavior rather than the way it is currently, but I have no desire to continue this discussion. If it's not standard to do so and no one has any desire for such linkage, it makes sense to make the suggestion void or dormant.
Maybe some other chaps will come back here in the future and add their concerns or lack thereof :)
To be clear for future reference:
You have your brand of non-standard experimental notation that involves the hooks pointing to a location other than a note, and your particular notation is easier to create if we do take on this effort and risk and make the change. But, someone else may well have their own brand of non-standard experimental notation that actually relies on the hooks not being aligned when they modify one but not the other. So making this change would suddenly make their hooks align, thus breaking their existing scores that rely on the current behavior, and causing them to have to work harder to create their special unique notation in future scores in the same way that you are now.
In reply to To be clear for future… by Marc Sabatella
And a final P.S. as related to Marc's post:
if it were decided to keep the current behavior as default, maybe having this as an option for pedal marks with the \ and / hooks could stop from breaking the previous behavior and also enable the suggestion. Something like a "Link terminal hooks" as an enable/disable attribute could be potentially useful without being too obtrusive.
Now don't get me started on having regular lines have a set as vertical attribute :)