Feature Request - make reapeat "R" and tie "+" commands accessible from "normal mode" please!
Hi,
I can't stress enough, how much more convenient it would be to have commands "R" for repeat "+" for make tie to be fully accessible in "normal mode" and in "range selection" mode. Right now that functionality is restricted to following scenarios:
For repeat command
1.
- from normal mode with a single notehead selected you cannot execute a repeat command. You can only do it if it is range selected, or you are in a note input mode.
Why is it an issue?
There are lot's of situations, where selecting a single notehead and pressing repeat is the fastest and most efficient way to enter the repetition. Having to do a range selection or enter "note input" mode is just an extra step, that could be pretty much spared.
Another issue:
- if you press on the note or chord, then enter note input mode, a "repeat" command will not create a repeated note at once, but will break the tie with the previous note which was there already. It is just not practical, and copying single chords or small note groups becomes a tedious process.
It is always faster to just "repeat" the chord, than input of copy it.
For "tie" command
2.
- the tie command is partially available in normal mode and in a range selection mode. However if a single notehead is selected, you can only make a tie if there is already the same note after the selected one.
If a single chord is range-selected (all notes are blue), the tie will only go from the last selected notehead and only if it was previously clicked. You cannot normally create ties from all the notes of the chord.
Why is it an issue:
- Particularly in combination with "repeat" command it is often a much more efficient way to create tied chords following each other, than through the note input, or via copy paste.
Select a chord - make ties from all notes - press repeat - finished. Super easy. With note input mode it often becomes much more finicky. You have to make sure you don't "destroy" the chord tie by pressing repeat, take care to switch to the correct note value, etc.
Finally you cannot tie the chords on more than one staff, which is something that you have to do a lot for piano music for example.
So my suggestions are:
- Make the Repeat and tie commands unrestrictedly functional in both "normal" mode and in the "range selection". I.e. Ability to "repeat" note, or chord in normal mode, without having to range select it.
- Make ties behave like a free toggle tool. so that the ties can be created at all times: from normal mode, and from range selection.
Comments
The behavior of "R" in normal mode was discussed at length in the forum recently, culminating in #304051: "Repeat a note" by clicking a notehead then pressing "R" in normal mode. I encourage you to check that out and if it seems the proposal there covers your expectations, let's close this as a duplicate. At least regarding "R". The "+" command is a totally separate matter. I'm not really understanding the suggestion in that case, "+" already adds ties to all selected notes just as I'd expected. Probably worth further discussion in the forum before making a formal proposal for a change in the current behavior.
Ok. Yes I agree about the R command, the other thread covers the matter pretty much. However I would still like to keep the tie command suggestion.
Let"s make sure we are on the same page here:
Right now in a normal mode you cannot create a tie from a notehead that has been ctrl selected unless there is a note of the same pitch following that note. Same thing with range selected notes or chords. Ties cannot be created if there is no note of the same pitch following the selection.
I would like to propose to take away this limitation as there are countless situation, where it is useful to have that functionality. The simplest example is when you have multiple staves with chords or notes range selected (piano music, or orchestra), you can easily create prolonged chords over the barline by creating a tie first and then hitting a repeat command to create a notes that instantly become tied. This is something that you cannot possibly achieve through step input and is pretty much a routine operation that is seamlessly implemented in Sibelius. So these two commands "R" and "tie" work in combination for that. I think this should become something like a standard for the music notation software at some point, as it is probably the simplest and most efficient way to do this.
Creatring a tie if there is nothing to tie to - so you are talking about one-sided ties, like at the end of a repeat, or into a second ending? If so, that is also covered by an existing issue. Although since you don't specifically mention that apsect, it's not totally clear what you mean., This is why, again, I suggest you start a forum thread to brainstorm with others how such a feature might actually work, and then upon reaching some sort of consensus, open a new issue with a concrete proposal that has support from others. That's much more likely to get higher priority.
In reply to Creatring a tie if there is… by Marc Sabatella
Ok, no I didn't mean ties at the end of repeats.
Something much more simple and common.
This is a fragment of a big-band score. On the first image you see a chord, played by some wind players above, and guitar + piano below. Now let's say I want to extend this chord over the barline.
Step 1 - Range select the chord
Step 2 - create "one sided tie", (which is just temporary)
Step 3 - hit repeat command - done.
In the current Musescore behaviour it would take:
So 6 commands versus 3.
And this is not some exceptional situation, but something the arranger ends up doing dozens of times. For piano music also. or pretty much any material that involves multi-staff editing. And that extra time adds up.
Sure I can open a thread for that, but this seems quiteself explaining with the illustrations.
Do you still think it is something we should discuss in the forum first?
In reply to Ok, no I didn't mean ties at… by antonjazzsax
You seem to have missed a step. How does the user define the duration of the added note? You don't always (or even often) want two equal durations tied over a barline.
Well, since it's not a step input, it's a different way of editing. It's a copy paste approach, rather then step input.
"Repeat" command literally means - repeat selection, which would be the duration of the selected note. While that's true, that you might need a different duration, this is in most cases easily done by pressing "W", or "Q", or "Shift Q" -"Shift W" afterwards.
Even though it is not as "correct" and "proper" as step input, the practicality and flexibility by far outweighs that. The thing is, by using step input method, it will be longer in most cases, so having to adjust the note duration via "Q" or "W" is a pretty minor drawback in comparison.
To me this seems likely to be faster only
in the rare situations where the duration happens to be the same, plus you overstated the complexity of the current steps - why note use “R” here? And why note not just press N to enter note input mode and then enter the tie in one more step? And of course normally you enter ties before you ever leave note input mode - entering ties in normal mode is itself rare to begin with.
So I am having trouble seeing how this could really much of a different in time spent entering ties. But since the hard part of this is supporting one sided ties to begin with, and that would be hugely useful to many people even if they never used the “R” command afterwards, it’s definitely something that should be considered. But we’d also need a way of creating one-side ties into a note, and we’d need to solve the layout and playback questions about how they should work.
So, absolutely this should be discussed in the forum, to be sure a design is created that really works for everyone.
In reply to To me this seems likely to… by Marc Sabatella
Ok, from everything we exchanged here, what information should i use for such a post in your opinion?
In reply to To me this seems likely to… by Marc Sabatella
Generally I think there is a bigger topic for discussion, which is about integrating three modes: the step input, normal modes and range selection functionality better with each other to allow smooth combined use. So repeat command and ties are just two of them. Some other would include range selection out of the input mode, (which isn't possible) and few others I've noticed. How would you propose to unite few such topics under the same hood? So that a bigger picture can be drawn out?
To me there are two completely separate things being discussed here. One is something about blurring the distinction between note input and normal mode. Thi goes 8way* beyond ties, or "R", and is a huge fundamental change to how MuseScore does things. Worth discussing for sure but best not to clutter that with specifics about ties - the discussion would really need to be much broader to be of much value.
Separately from that is a discussion about a new proposed feature for creating onesided ties. Whether one chooses to use this as a way of saving a click when entering ties in normal mode, or to actually create one-side ties for normal notation purposes, we need to agree on the behavior for that feature. Nothing about this feature requires major design changes to the overall behavior of note input versus normal mode, but it does affect layout and playback as well as the actual way the score is represented internally, very possibly also requiring a file format change.
And to be clear, the reason the forum is always recommended first is the audience is much larger. Only a tiny handful of people will ever see anything here in the issue tracker - it's mostly just developers.
In reply to To me there are two… by Marc Sabatella
Ok, I'm glad that you said your opinion, before i published anything,
So do you think there is anything that is worth posting for discussion from this chat?
For me there are three things that are somewhat counter intuitive in the current workflow and are in a way related:
The last two are on the agenda already as you say.
About the broader discussion, I didn't quite understand what exactly would be the fundamental change ?
So far my "broader" idea was to allow certain functions as range selection, tie (and partial tie for normal mode) as well as repeat command to become available in all three modes.
Thank for your input.
I think it's all worth posting. I am not sure much would come right away from any discussion of the broader issue of the workings of normal vs note input mode, but you never know. When I talk about fundamental change, though, realize that as soon as you talk about making a selection in note input mode, next you need to talk about what you can do with that selection, and then one wonders what the difference between the two modes really is or needs to be. It's certainly possible to imagine a workflow that doesn't separate the modes, but it's, as I said, a pretty fundamental change.
Note, though, that ties are already possible to create in both modes. So there really isn't anything much new to your idea except the idea of creating a one-side tie. And that is definitely relevant. One-side ties are wanted by a lot of people, but no one has really thought through how it might work. It's overdue.
Ok, Marc, I've read the thread you posted for me. I have an idea. But it would need a bit of support from your-and/developer side, due to a very obviously different way of thinking that causes sometimes (too) excessive discussion. It is normal and I think it's about coming to understanding between those two parties (users and developers). From reading your comments across different threads, here is what it looks like to me. I think as much as it is important for users to understand the way "developing" and "implementation" works in order to post meaningful proposals, it is important for you and others from "developer" team, to just observe and accept user habits and wishes as they are, not necessarily trying to justify them. There are certain practical reasons why experienced arrangers and composers want to work certain way that apparently not so easy to explain. So I would like to open a thread not to discuss the necessity, of why, should or should not a feature be implemented. But to see which changes are desired by users, who write music a lot, with the focus on things that don't need "fundamental" change, but easy for developers to implement. (Your input is most valuable for that). Musescore to me has already a great set of features, that need practical "real world" optimisation not a radical change. Little things, that would not need much change, but are sweet and helpful. The moto is: "If it isn't broken, don't fix it" I would like to make a list of those requests, referencing other threads discussions, and please if you know, where it was already discussed, please post it in. I don't mean to double those requests but put them together.
I agree with much of what you say here, but not one of the central tenets. If you want to say we should just observe and not ask for further explanation, that's fine, but then you must accept that no one is likely to actually implement the suggestions. Because we aren't likely to implement suggestions without a good understanding of the suggestion, the use case for it, and how it would benefit the average user. One or two people saying they would like to see a given feature is not sufficient reason to take development resources away from implementing things that will benefit thousands or millions. So if its only one or two people suggesting something, it really is important for them to explain the use case in sufficient detail that we can understand how will benefit all users and thus potentially rise in priority to join the ranks fo the very many other things we want to implement that we know will benefits all users.
In reply to I agree with much of what… by Marc Sabatella
Hi Marc. Thank you. What I mean by observing, is that in scientific and socio-economic fields is called a meta-analysis. Unlike a "normal" analysis, which attempts to make sense out of a certain input data, (in ourthis case analysing the feature requests for its "expedience"), the meta analysis is about evaluating the framework and methodology itself, based on statistical data. In other words, the question being asked is not "is this feature useful, beneficial, etc.?" but rather "what can we learn from these various feature requests, habits, contradictions etc. " Because at certain point it's also a combination and permutations, of different factors and feature sets as used by different types of users is what worth considering to make a good product. And while it's anly a couple users here and there, who actually request something, still they might represent a behaviour of a larger target groups. It's just about how to look at that. So this is helpful for a bigger picture at the end. Not only for quality of certain aspects, but the integration as the whole process across different user groups. When Adolf Sax created saxophone, he had no idea what kind of cultural and and esthetical role it will play in the 20th century music, he just wanted an extra orchestral instrument, but the result exceeded his expectations. I think at this point musescore has developed so much, that it becomes important how the features play with each other from the collective user practice.
Fair enough. I will say that Martin (@tantacrul) specializes in this sort of thing even if I don't, so rest assured this kind of data is being collected and analyzed in a number of ways that aren't obvious from individual feature request (he does controlled studies, surveys, plus we have telemetry data to crunch, etc).
Meanwhile, there is value in working towards understanding of individual requests, and value in making those request, and in doing what it takes to help us understand the use cases. Hopefully it all adds up to a continually improving product, and I think if you you follow the course of MuseScore's pretty stunning advances in both functionality and usability over the past ten years since its initial release, you will agree :-)
In reply to Fair enough. I will say… by Marc Sabatella
yes. I have been following it since few years, and the improvements are quite impressive. I have to say, for me musescore needs just a little more stability and polished workflow until professional arrangers and engravers producing a bulk volumes of score paper would consider it a serious alternative to "big cats" that sell for half a grand.
I have a tentative implementation of the basic R-with-single-note-selected-in-normal-mode portion of this. As such, I'm considering that to be a fix for #304051: "Repeat a note" by clicking a notehead then pressing "R" in normal mode. The other suggestions here still seem somewhat vague and still needing further forum discussion to flesh out and make concrete, and then turn into individual issues for each specific suggestion that arises as a consensus in that forum discussion. I'm leaving this issue open for now to make the discussion easier to find and refer to in any subsequent forum discussion, but leaving this as "Needs Info", because indeed it is still extremely unclear what else besides the basic "R" with a single note selected is involved here. And I think it will better to open new more specific issues once a consensus is reached.