Range Selection within note input mode.
Since there was quite a discussion about a feature request that would allow to do a quick range selection out of note input mode, and no clear agreement was achieved I would like to start a separate topic here to brainstorm some more advanced possibilities.
So here are some use cases for which this could be beneficial:
When inputing few notes, chords, or measures, it is common to do one of the following things
note input a passage _ range select _ then:
- add a slur to a phrase, or
- add articulations to notes, or
- copy paste the passage, or
- make a passage into a second voice, or
- change noteheads type, or
- toggle slash notation
- make small,
- add tremolos
- add a pin, or any other element from "linels" palette, like 1st or 2nd ending, 8vb , etc.
- add an interval
- change properties in inspector
- add arpeggiato to chords
- delete (yes sometimes we change our mind)
- change (most often diminish) note durations of selected notes using numbers
- ....
With the current note input behaviour, you have to first exit note input than do a range selection. Then possibly reenter note input mode and so on.
With this many different use cases It would be good to have a more efficient way to do it.
I would like to have a possibility to make a range selection right after I've entered the last note of the passage.
My ideas:
There were basically two possibilities discussed in the linked thread:
1. Allow a range selection command (currently "shift+arrow") to exit the note input and make a range selection at once.
2. Create some kind of hybrid note input mode, with the range selection functionality.
The first option seems like a quick and easy solution, with some drawbacks.
The second solution looks like would have to be built up from scratch.
So I see two possible routes (not necessarily excluding each other)
- Implement an extra command that would allow a "silly billy" exiting of note input mode and making a range selection at once. Leaving it a freely assignable to any shortcut (including a possibility to reassig it to "shift + arrow" thus replacing the current "swap notes" command in the note input mode )
or
- Since muse score already has few different options under the "N" enter notes menu,
I can imagine adding another one:
an extra hybrid note input mode, which would allow making a range selection, while remaining in an active note input mode.
That means a range selection can be made without exiting a note input mode.
Use scenario
enter the last note of the passage, make a range selection of a passage, apply articulation, hairpin 8va__ , for the lenfth of the passage. Then continue a note input as usual. No exiting, no reentry of note input mode. I believe there are no conflicts between commands in range selection and commands of note input mode (except for the "shift + arrow" which to point is what caused this discussion). Once the note input went on, the range selection is dismissed automatically. And so on. This might have the same disadvantages as the first solution option (potential confusion between note input and range selection functionality). However I think any of the options could be introduced as a n extra feature without radically affecting the familiar behaviour.
What are your thoughts?
Below is the link to original thread, which can be linked to this one.
https://musescore.org/en/node/304903
Comments
Interestingly, "Add stave above to selection" (Shift+up) and "Add stave below to selection" (Shift+down) do work in note input mode. So we already can extend range selections vertically to do things like add staccato to all notes on beat 1 in all staves. It would certainly make sense to me to be able to do the same horizontally. Indeed, that use case rather than vertical extension is probably more likely to be useful.
In reply to Interestingly, "Add stave… by SteveBlower
Well, this is generally a critique point I have for musescore. That a LOT of features are just partially implemented. So naturally users want full implementation of the features that are already there. I guess it's a peculiarity of community based development though. I have to say I'm really happy with what musescore is capable of at this point. But the consistency of feature behaviour and coherency should be seriously considered so that program's behaivior doesn't feel "sloppy" and "weird", especially for the new users. There is simply no reason to keep features partial it just makes getting used to the workflow longer, especially for those who "migrate" from paid software.
In reply to Well, this is generally a… by antonjazzsax
Not sure which features strike you as half-implemented. I guess you mean things like wishing "R" worked on more selection types. but I think characterizing it as "half-implemented" is unproductive. It's simply an opportunity to extend the feature in a way that wasn't originally conceived of.
Certainly the fact that range selection isn't implemented in note input mode doesn't mean anything is half-implemented. Again, it's just an opportunity to extend the original design in a way that no one has conceived of before. And this one is an extremely complex topic, so dismissing it as "half implemented" is especially unproductive.
That said, there are a very small number of features that truly are only half implemented in the sense that there are things that clearly could be done but weren't: local time signatures being one main example. The ability to associate linked parts with individual voices is another, but this is being addressed for 3.5.
Also, it is important to keep in mind that every notation program has its own set of features, and migrating from any program to any will make one aware at first of what is "missing" in comparison. Each of the major notation programs has features none of the others have.
In reply to Not sure which features… by Marc Sabatella
Dear Marc. I didn't mean to sound unproductive. In fact even calling it a "critique" point I do so because I see a potential in what musescore can bring, what the others cannot. And I do appreciate an open structure of the design, as it indeed makes new design solutions possible. I just share what I consider worth mentioning from the user perspective. I guess it's not a right thing for me being not a programmer to talk about half-implementation (although i used less harsh wording then "half- implemented") since I simply don't know the specifics and possible use terms not in a correct way, but I'll try to choose the words better. I believe it would not be wrong for me to say, that from user perspective I miss certain consistency in behaviour. Meaning: it's normal to expect the same command to do the same thing in all applicable situations and use cases. It's confusing when you can do a certain thing in one situation, but not in the other for no apparent reason for the user. It's normal for a user to rely on habits and "similarity" of behaviour, when the same command works the same way in all applicable situations and it sucks, when this is not the case in a small things like I was posting about lately. I think it's important to ensure such UI consistency in this aspect, to eliminate confusion and dissatisfaction during the learning process. Something you rightly seem to care about from the last thread about range selection. Now I hope you can accept this as an excuse and maybe we can exchange about the the the topic of this thread a little more.
In reply to Dear Marc. I didn't mean to… by antonjazzsax
Thanks for the clarification, and sorry for coming as a grouchy.
To me this meta-discussion is good to have, though, because there really is an important distinction to be made between things where anyone might reasonably expect a certain behavior, and expectations that are formed primarily because of prior familiarity with one particular program that happens to do things a particular way. People accustomed to how they did things in program X might expect one behavior, while people who were accustomed to program Y instead might expect something quite different, and people with no prior notation program experience might expect something else still. Balancing all of these is a complex thing.
And while, sure, consistency is good, the whole point of having separate modes in a program is as a way of clarifying the fact that certain things can be done in one mode whereas other things can be done in another, and this in itself is supposed to help set expectations. But, it seems to be an area where there is some disagreement among design experts - some are convinced modes are the best way to do this, others are convinced modes should be avoided at all costs. I don't actually have a horse in that race, but I do share your implied concern that forcing people into changing modes when not necessary is not a good thing.
I know Dorico has gone full-on with a mode-based approach and for the most part people seem to be responding well to it, and it does seem there is much to learn what they are doing. I'm not sure if you've checked out any of Tantacrul's videos - that's Martin Keary, who is now our head of design - but I highly recommend checking out his Dorico review to get an idea of where some of his thinking is:
https://www.youtube.com/watch?v=S-3wEC6Fj_8
Martin is actively working on new designs for MuseScore 4, with an emphasis on adding more playback-related features, and I have to believe the subject of modes is going to come up, whether we go that way or not.
So to me these larger issues are definitely worth discussing and getting handle on, really before we start talking too much about specifics. Not that looking at specifics can't also be useful, but it really is vital I think to not start out by looking only at the details but to see the bigger picture.
In reply to Thanks for the clarification… by Marc Sabatella
Aw.. that video :D!!!! too funny.
Anyway, here is what I wanted to share from my "first time" use experience with musescore.
I believe that music notation program has a lot in common with text editor. And despite all the fancy musical "speciality", we should not forget , that essentially it's a musical "typewriter" in the first place. To me Sibelius is something like a Microsoft Word of music notation. It has introduced some breakthrough workflow routines that work extremely well. It's strongest points to me is its note input/editing workflow + interactive layout adjustment. I'm a saxophonist, so I have a similar analogy. When "Selmer" sax company introduced introduced their particular design of key mechanics back in the 50s, eventually all manufactures copied it, because it just worked so well, and Selmers were at that time the most popular. Although every company had their "unique" mechanics (which is a pain getting used to), today literally every modern sax uses that same design, making it so much easier to switch. I think the first company who decided to copy it, made the wisest decision for business and for user-friendliness. Now it is pretty much a standard, and no one cares, where it came from. Same with Microsoft Word and Photoshop. To me Musescore leans much more towards Sib. in terms of workflow (input, editing, layout) than to any other major program. When I first used Musescore I could clearly see it. And to the point that I would start wondering, why not to finally to nail down, and avoid making an impression of a week Sib copy? Having something so similar, but not quite as consistent and convenient made no sense to me. And to be clear, I don't mean the things that are a particular design ideas of a musescore (most of which I find excellent, even if not fully matured). I mean small things that are like a cogwheels, that you don't care about, as long as they work smoothly, but when they don't you scratch your head. Like "R" command, one sided ties, copy paste of list selected notes, making all elements on the staff small (and not noteheads and rests separately), adding intervals, and some other. To me they are just too common and insignificant, to try to invent them anew. For the most parts, these things are being adressed already, but sometimes I was a bit surprised, how difficult it was to suggest things that just work and give no trouble. Maybe I'm biased, but seriously we are talking about the succesfull design of the software that is used by a huge chunk of users globally and from which musescore has obviously taken a lot. So why not to make those cogwheels run properly and then concentrate on the things that musescore could be unique at? It looks just like a matter of taking advantage of what has been done already. And for the most part it has already been taken. I think that is exactly the weakness of Dorico. Because obviously Dorico team was too concerned to do things differently than sibelius, even though they themselves created it. As the result its workflow is much less fluent and while the program is nice, it looks like it is not going to be a go-to software for the majority of users. Dorico's target audience seems to be a rather narrow group of engraving professionals and "serious" composers. My feeling is, it would be wise of Musescore developers to take as many "good things" from Sibelius as they possibly can, and make that workflow run just as smoothly, even if it would mean copying Sibelius (which is often the case anyway). And then "boldly" take all advantage of SMuFL while slowly growing up and maturing its own design developments and features. After Sib. has dropped the ball few times in the last years with some questionable design decisions and discouraging subscription policy, it would be "neglecting an opportunity" to not try to lure some of its users. But for that Musescore would have to become at least as good at things that Sibelius nailed.
The idea of being able to make a range selection in note input mode is interesting, and has some obvious benefits, such as those you have highlighted.
In theory, it's probably not that hard to implement the ability to make selections in note input. But there would be a number of difficult design problems to solve, though.
One is the question of how the "selection" will relate to the "cursor" in terms of, for example, where the next note is entered if you press a letter key. This is already a very delicate relationship that has been tuned over the years based on feedback. We also try to maintain a sense of the "active" note/rest when making selections by keyboard in normal mode (the one whose position is used as a basis for the behavior of Shift+left/right/up/down). This has also been tuned over the years but my sense is there plenty of room for improvement here. So it would be important to work through exactly what happens to both the input cursor and the "active" note/rest in a variety of scenarios.
Another obvious question involves the people - a large majority, I would imagine - who don't use the keyboard to make selections at all. If range selection in note input mode is to be a thing, it shouldn't be something available only to the minority who use keyboard shortcuts heavily. And that becomes trickier, because the idea of clicking to enter notes is pretty heavily ingrained and forms a big part of many users' expectations.
Example of how other programs handle these issues would be interesting.
In reply to The idea of being able to… by Marc Sabatella
"One is the question of how the "selection" will relate to the "cursor" in terms of, for example, where the next note is entered if you press a letter key."
If there is a hybrid mode, then a range selection doesn't affect the cursor (the one that's on the staff, about the mouse/note cursor see below.) The blue staff cursor stays where it was and pressing a letter creates the note there, where it would be created in a normal note input. And the "active note" would corresponds to to the last note that was entered, as it anyway stays blue in note input behind the cursor.
"If range selection in note input mode is to be a thing, it shouldn't be something available only to the minority who use keyboard shortcuts heavily."
For that i imagine holding Shift key could be used, as it is so universally associated with selection. not just in music notation, but in MS Word etc. So pressing shift key in the "hybrid" mode would make the "mouse note cursor" become a normal mouse cursor, allowing to do a range selection by clicking on the staff space., and the "staff cursor" would remain intact.
"Example of how other programs handle these issues would be interesting"
I don't think this particular idea of "hybrid" was implemented by famous notation program, however it is commonly used in DAWs like Logic, Cakewalk aka "smart tool", where the cursor changes appearance.
In reply to "One is the question of how… by antonjazzsax
Unfortunately Shift already has a specific meaning in note input mode, to replace notes rather than build chords (or vice versa for MIDI input). So further redesign would be required to accommodate use of Shift for selection.
In reply to The idea of being able to… by Marc Sabatella
"a large majority, I would imagine - who don't use the keyboard to make selection"
I'm sure there are a lot of mouse users out there and it's important to consider both habits.
For me personally there are just couple of common sense reasons, why I personally would never prefer a mouse input in the long run and at the certain volume of music production.
1. Although it is no doubt can be quite fast also, the keyboard input is still a bit faster.l for the "raw" input speed.
2. Not so insignificant to me: With keyboard shortcuts input you have a chance to give your eyes a little break from the screen here and there, as you can use a little bit of the blind "typing" technique . Something you can't possibly do with the mouse as a main tool. plus visual changes made in the design of the new version of the program don't throw you out as much. So arguably keyboard is a more sustainable method in the long run (as long as we are stuck with computer displays). Of course that is just a part of the users base, but not so insignificant.
In reply to "a large majority, I would… by antonjazzsax
You're preaching to the choir regarding keyboard control :-). But even so, I recognize that from a design perspective, to accommodate all users, not just "power" users, we need designs that are easily discoverable and that make sense to people who don't already have preconceived notions of how notation programs should work based on experience with Sibelius, Finale, or Dorico. This idea of discoverability is actually one of the main focuses (foci, I know) of the usability testing that has been happening on conjunction with the new designs being produced already.
In reply to You're preaching to the… by Marc Sabatella
So do you mean only those users who don't have a previous notation program experience would suit the criteria for usability testing? :)
Like people who always wrote by hand, or only children? Or those who have no previous experience with music notation, or no experience with computer, or only hobby musicians? Where is the "waterline" ? I think it's just an illusion distincting power users from non power users, as every person will likely have some experience to relate to. The question is really who should be the reference point?, what kind of professionals or artists? I think you'll be hard pressed to find it among those who are not completely inexperienced and ignorant, but have no notions about what the program should be like in 2020. And everyone has to learn, just like a musical instrument. But even relatively easy to lern Instrument will still relate to some kind of "professionals" in that field to suit them.
There are basically just two main variables: 1. is the amount of learning worth the reward in terms of possibilities the instrument gives and consequently I f there is something that can be done to allow achieving the result easier without sacrificing quality. 2. What the "ideal" functionality on various levels of complexity should be like? And that inevitably brings back to the collective experience of other programs. Like the design of a piano mechanic would not exist in its current form without all its predecessors, whose design contributed to the modern instrument. So if we talk about something sustainable, that hopefully should stick around for a while I think it should really be thought in terms of something that is less influenced by the computer-era hype. Where you have to relearn the software every few years, although it still does the same thing it did 10 years ago. Because sheet music has been there much longer than computers and audio recording and likely will stay for a while. The real evolution could be for example in how well it translates music from xml, or pdf , or how well it merges with the DAW. But music notes will likely look much the same in 20 -30 years. So why not try to establish the routine, like of the Microsoft Word or any other text processor. It's all QWERTY and and is quite established.
In reply to So do you mean only those… by antonjazzsax
All kinds of users are looked at in usability testing. My point here is, it isn't only former Sibelius users we try to make things seem "intuitive" to. It's important to look at the big picture and somehow balance the different expectation had by different users, rather than assuming our own expectations will always translate to everyone else.
The idea of making analogy to word processor makes sense sometimes, but not other times, as there are many many ways where music is nothing like words. Words have no concept of time or measures where removing a word has to ask what should happen to the subsequent words. That is, there is no situation where it ever makes sense to not shift them left to close up the space. Words have no concept of multiple voices, or for that matter multiple staves, or even chords. They are completely linear, so no issues of say multiple markings on a single note. And so on.
So we do try to use that analogy where it makes sense, but there are many places where it simply falls apart once you look closely. And that's why no WYSIWYG notation program follows this to any great extreme. You use that model where it makes sense, and you don't where it doesn't. Sometimes the line is hard to draw cleanly, and everyone will see that differently, and that's OK.
Anyhow, we certainly appreciate your input regarding your own personal experience and how it is has shaped your own unique set of expectations. It's all useful data. I'm just addressing specific points that seem to call for response.
In reply to All kinds of users are… by Marc Sabatella
Thank you. I'm glad if it is of some value. And even if it may seem like I'm pushing my ideas, that's really not what I'm interested in. I just feel there is more potential in this project than what the others software could have. Hope you'll find a good idea for the for the "range selection" matter of this topic too
In reply to Thank you. I'm glad if it is… by antonjazzsax
I am pleased that this proposal is receiving serious consideration. I can see its advantage if implemented correctly. To help things along, I did a little more experimentation with the existing behaviour of selecting "vertically" while remaining in input mode. In particular I looked at what happens when you try to enter a note after using the selection.
Suppose you have four staves and are currently entering notes in stave 3. You can use Shift+Up twice to select notes/rests at the same time slot in staves 2 and 1. Press Shift+S and you add staccato dots to the selection. If you now press a note key, the selection is cancelled, like pressing Esc and the note is entered at the next position that would have been used if you hadn't made the selection and added staccato. This seems very sensible and understandable behaviour.
I also looked at what actions are possible while a vertical selection is active. I found that most things work. You can add articulations and ornaments. You can add accidentals from the pallet but not from a shortcut. You can add most lines, but not a slur. You can add dynamics. You can't add stave text as you get a "No note selected" warning. Trying to add a tied note using the + shortcut gives quite surprising results. You get the tied note on stave 3 but you also get the notes in staves 1 and 2 added to the tied-to note in stave 3 to make a chord. This is perhaps clearer by reference to this screenshot.
I was working in stave 3 and after entering the G on beat 2 of bar 2, while still in note entry mode, I pressed Shift+Up twice to produce a selection including the E in stave 1, the C in stave 2 and the G in stave 3. Then I pressed + and you see the result: a tied G on beat 3 of stave 3 but the notes from beat 2 of staves 1 and 2 have been added to it to make a chord. Perhaps less surprisingly, the C on beat 2 of stave 2 has been tied to the C on beat 4.
A few thoughts on implementing “range selection within note input mode”:
The fact that vertical ranges can be selected while in note input mode suggests that extending the implementation to horizontal ranges may be more a question of removing a restriction that prevents making a horizontal range selection while in note input mode, rather than implementing something wholly new. But not being at all familiar with what goes on under the hood I may be grossly underestimating what is needed. One current difficulty is that the obvious short cuts for making a horizontal selection are already by default allocated to shifting the last-entered note. But as I noted earlier, I feel that this shift behaviour would not be missed by many users if the shortcuts Shift+Left/Right were re-allocated.
The behaviour when resuming note input after using a vertical range – carry on as if the range selection had just been cancelled - seems sensible and could be retained for horizontal range selections.
If the ability to make and use horizontal selections in note input made is implemented, thought needs to be given to what should and what should not be possible from those range selections. Ideally there should be no difference between what happens in and out of note input mode. But do all operations that are possible outside note input mode make sense while in note input mode?
Forward selections from the current note input position are probably much less useful than backwards selections as if you are entering music left to right, there is probably not much to select in the forward direction. Perhaps only backwards selections should be allowed.
The current behaviour when adding ties with vertical selections while in note input mode is bizarre and should be made the same as when out of note input mode.
In reply to I did a little more… by SteveBlower
Oh great! So you've actually tried it!
" making a horizontal range selection while in note input mode, rather than implementing something wholly new"
1. That's what it seemed to me. An idea of a "hybrid" extra was just an idea of precaution, but I would not mind at all having it in usual Note input.
While the point is true....
Ehm..... It might be a good idea to give just a little extra permissiveness on that one. You never know, how users might end up doing things. Full range sel. functionality would not seem to hurt. Unwillingly remembered that fragment of Tantacrul's video about vertical hairpin movement behaviour in Dorico :D!!! Let's not risk that.
Cool! so maybe we could draw some attention of developers to this then!
In reply to Oh great! So you've actually… by antonjazzsax
"So you've actually tried it".
Well, I have tried what I said in my post which is to see what happens when you press shift+up/down when in note input mode. No, I haven't tried to implement making a selection by pressing shift+left/right when in note input mode. I have just made some suggestions about what such an implementation might look like to a user.
In reply to Oh great! So you've actually… by antonjazzsax
It's frankly a bug that Shift+Up/Down seems to work in note input mode currently, but it's a convenient bug for this purpose, because it allows testing some things that otherwise would require someone to actually prototype something,
So I definitely encourage more experimentation with this to see if you like the current behavior in a variety of different scenarios. Be careful, as I would not be surprised if some operations crash, as there are implicit assumptions in the code that range selections won't happen in note input mode.
In reply to It's frankly a bug that… by Marc Sabatella
Dear Marc. Thank you for your response. I have a question, Is there a possibility to make a rough change to the program code (a draft for testing so to say). Since there is no need to make anything new, except for disabling the "swap notes" command and removing what limits selection to the left and right. Any chance someone who knows the code of the program could assist with that? Again just a quick tweak for a personal testing? So we could have a run on that. Many thanks
In reply to Dear Marc. Thank you for… by antonjazzsax
It's probably possible, but likely to be more than a little work to make sure we handle enough cases that it doesn't crash. I wouldn't consider it worthwhile without more design thought into how this could really work - again, a feature that only works via shortcut might as well not exist for most users. Meanwhile, you can test using Shift+Up/Down.
Or maybe someone else has more spare time on their hands and doesn't mind spending a few days or whatever on doing a trial implementation of this.
In reply to It's probably possible, but… by Marc Sabatella
If using shift is not possible , it could also be holding "alt" key or a ctrl/command keys (mac/pc respectively) and then clicking the staff space (or a note). So holding a key could make a note cursor icon dissapear and thus allow selection. I know I'm risking to be arrested by the "step-input" police , but hey, why not? This is a fairly common behaviour for many DAWs, so maybe it could be borrowed.
In reply to If holding shift is not… by antonjazzsax
Having to hold down a key other than Shift for making selections is not a step in the direction of discoverability, however.
A related issue to ponder is how to one makes selections in normal mode. Currently, MuseScore moves the score if you try to drag-select. I do think many people eventually figure out (or are told) that Shift allows you to drag-select, but this is not the epitome of discoverability. Plus, people find immediately that the drag moves the score, then they fail to look for and discover the much better ways (eg, mouse scroll wheel or two finger swipe), and instead grumble about the lack of scroll bars and spend way longer than necessary dragging the score around and accidentally dragging elements to boot.
I'd just as soon see us make plain drag do a select, and Shift+drag to the scroll. But that would not work in note input mode any better, because the click for plain drag would insert a note. Unless it didn't, of course, so we could play games with things like, only adding the note on mouse release instead of on press.
These are the sort of things that all need to be looked at together when designing new interfaces, particularly when trying to replace one that actually works quite well and has been refined over the years based on lots of input from users and millions are now used to.
In reply to Having to hold down a key… by Marc Sabatella
Well but that leaves us kind of empty handed then, as there is no way to address the issue other than making those operations more complicated than they already are. Come on...
No feature for keyboard shortcut, because mouse users cannot take advantage of it, no "silly-billy" because it might scare someone. So then at the end lots of posts and little chance for the feature to be implemented. It would be just good to see where this can go..
In reply to Well but that leaves us kind… by antonjazzsax
Spending a bunch of time implementing a feature that the vast majority of users will never use is a bad idea, if we could be spending that same time figuring out how to design it to actually be useful to everyone. This is why I say some good design work is needed. There are probably solutions out there, but it takes work to come up with them. It does no one any good to cobble together an application out of hundreds of unrelated ideas that seem good on their own but don't mesh together well and end up being undiscoverable to the average user. You end up with an application that makes no sense to anyone, a mess of non-intuitive inconsistencies.
That's always the danger we face and what we are trying to avoid and why we've gone to the trouble of hiring Martin to help focus design efforts going forward.
In reply to Well but that leaves us kind… by antonjazzsax
I posted my previous response before your edit.
No one is saying it's not going to be implemented. I don't know how you get from "more design work is needed to make sure we do a good job of it" to "not going to be implemented". That is not it at all. Please don't put words into my mouth. When I say more design work is needed, it isn't to say it won't be implemented - it's to encourage the sort of discussion that will lead to it actually being implemented well, designed in a way useful to all.
So you know, MuseScore 3.5 is imminent. There won't be any major changes to how the modes work or how selection works. Although I have implemented a few useful tweaks that hopefully will make it in, like "R" for single notes in normal mode, click/shift+click to select similar elements in a range, and ctrl+click to add/remove elements from a range selection. Those were all doable without changing any basic use models.
But MuseScore 4 is going to be the next "big" release, where quite a lot will change, precisely because of the ton of design work going into it. And to me that's where this discussion should be focused - making sure it gets considered in that design work, not arguing about whether or not it's worth spending time on a half-baked version in the interim that would likely need to be thrown away once a better design is created.
In reply to I posted my previous… by Marc Sabatella
Sorry, sometimes I get discouraged when I hear "no" a lot of times:) Of course you are right. So just to sum it up a little before taking a step back from this:
- we have a "bug" with vertical selection, that either can grow into a feature, or should be removed, but in any case should be addressed.
- we have lot's of use cases where simultaneous note input + range selection could be useful, but there is an overlapping command for both a keyboard input and for a mouse input scenarios.
Now after having played a little bit with applied vertical selection while in note input I have few observations:
- that feature would likely be more powerful but somewhat more advanced to use, than Sibelius's way of handling it and therefore probably something you would have to watch the video about. One would have to understand both modes quite well first in order to be able to combine them effectively and develop some routine.
- but It could speed up the process significantly, as you are potentially saving the need for exiting and reentering note input mode every time.
- it encourages a different way of working - i.e more multitasking, and possibility to write everything at once , rather then having to come back to edit elements. This feels in a way more natural and similar to how one would write music by hand bar after bar. It could be really powerful as you can remain in a "flow".
- feels especially useful for things like line palette elements , but also for tremolos, arpeggiates and slurs. You can add hairpins, slurs, slides, trills, piano pedal marks, repeat endings etc. And all that while continuously inputing notes.
- potential confusion point is obviously the fact that things are applied at multiple places of the passage, and one might forget about the staff cursor.
- For the mouse input scenario it feels that some kind of "smart tool" approach would be most appropriate. For example smart tool in Logic Pro, when holding certain key (which is assignable) changes a mouse tool, or Cakewalks's type, where the mouse tool changes depending on which part of a region you are hovering it over. It could be also be a drag selection, if adapted accordingly.
- selection behaviour in itself has some issues, that first should be addressed independently to have a clearer view on the combined behaviour of these modes.But that's a separate topic, which seems to be discussed somewhere else already.
- another potential issue is that it's not possible to convert selected passages into a 2nd voice if range selection is applied in the note input mode. That is something that feels as a discrepancy with the regular selection mode, which is not so cool.
In reply to Sorry, sometimes I get… by antonjazzsax
I would agree the ability to use Shift+Up/Down in range selection is a bug, but a very minor one, unless you can easily make MsueScore crash by exploiting it. But if it is decided to eventually implement a range selection facility within note input mode, it might be just as well to not bother fixing it as we'd just have to un-fix it later.
In any case, it should be submitted formally to the issue tracker so it can be prioritized and dealt with accordingly.
Regarding "Sibelius' way of handling it", I'm confused, I thought you said they don't support this? What video do you mean?
Regarding "selection behaviour in itself has some issues", not sure what you mean by that, unless you mean the confusion between creating list selections and range selections and how the Select context menu vs the Selection Filter play into this. That's definitely a known area where we'd like to eventually come up with improved designs, Martin has made the same point although I don't know that it is a top priority right now.
Anyhow, I do think this is a promising idea and agree with you regarding the ways it could help. It's just still not entirely clear to me if there is actually an opportunity to do even more to blur the distinction between normal and note input modes.
In reply to I would agree the ability to… by Marc Sabatella
Regarding "selection behaviour in itself has some issues", not sure what you mean by that
https://www.dropbox.com/s/mkgham0gtq4rdci/0-02-0a-c4fea9449ed1e5273c5fd…
Hi Marc, I've recorded a little video showing, what doesn't seem to me quite right about current range selection behaviour. And I think that might become more exposed if the discussed range sel. functionality in note input mode gets implemented.
To me the logical behaviour would be, if the whole bar is selected, then extending selection down the staff below should always select the whole bar as well. If let's say only the quarter note gets selected, than pressing arrow down or up can create the selection of the similar duration. That's fine. The program should attempt to do it as far as possible, but when it isn't possible anymore, because for example the lower staff contains the whole note, or whole note rest, then the whole bar selection should be created instead and selecting all the lower staves should continue creating whole measure selection.
I see no reason, why the empty bars don't get selected when pressing shift Arrow down, likewise it doesn't make sense to me that the notes get selected, then deselected than selected again, as it feels confusing.
"Regarding "Sibelius' way of handling it", I'm confused, I thought you said they don't support this?"
Ah, Nevermind, Sibelius just allows you to create range selection by pressing shift arrow instantaneously, which I find practical. But in Sib. those are still two separate modes.
"It's just still not entirely clear to me if there is actually an opportunity to do even more to blur the distinction between normal and note input modes"
What do you see the use of having modes more "blurred" and what would such blurring look like?
"Anyhow, I do think this is a promising idea"
So what should be the next steps?
In reply to Regarding "selection… by antonjazzsax
The behavior of Shoft+Up/Down has been refined much over the years based on discussions here. The basic question is, what should happen if the different staves (same issue for multiple voices, BTW, independently of Shift+Up/Down) have different rhythms. The current behavior does simplify one particular very common use case - wanting to select just a single note in each measure so you can, for example, apply a dynamic to all of them at once. And it's simply enough to use Ctrl+Shift+Right to quickly extend to the whole measure again if that is your goal. But indeed, no matter which use case we optimize for, there is another that suffers for it.
Not sure what you mean about empty measures, those do get selected. FWIW, it's much easier to discuss these things from actual sample score and written steps to reproduce an issue, so we can "play along". Videos are much harder to deal with,, except when discussing some sort of on-screen glitch that wouldn't be reproducible unless we have the same screen resolution, window size, canvas position, etc.
As for what blurred modes would look like, I don't know, basically the idea that you wouldn't have so many commands that work in one mode but not the other, or that work differently. But that's a big discussion, should take place between lots of people, including the design team.
Next steps would just be to try to get more people interested in discussing this here or elsewhere so it can be considered in the design plans for MuseScore 4.
In reply to The behavior of Shoft+Up… by Marc Sabatella
"The current behavior does simplify one particular very common use case - wanting to select just a single note in each measure so you can, for example, apply a dynamic to all of them at once. "
Sorry, but that is exactly what ISN'T possible with the current behaviour, unless you all the notes you select vertically are of the same duration. And this "selection/deselection" behaviour, I just don't see the point of it.
Ok I've attached the score and here are the steps to reproduce:
Now here is another one:
At this point you cannot continue selection to the lower staves, as the "empty measure" seems to block it.
So this is quite a bit of inconsistency in there. And it seems to be some issue with vertical selection of the rests that causes that.
Therefore a suggestion would be:
- always allow extending selection down or up, and fix the "rests selection" as well as selection/deselection behaviour as described above.
As far as how exactly should the vertical selection be extended.
Sibelius does the following
- it always selects the "first notes" beneath or above, but never extends range selection horizontally, even if the duration below, or above is larger. But when you copy paste it will paste all the selected notes of different durations aligned vertically. So essentially it works similar to "step 2" of the first example.
In reply to "The current behavior does… by antonjazzsax
I think in this particular case, somehow the rests are indeed getting in the way. I guess the code intended to deal with this doesn't handle something about that particular case. Worth submitting a but report. Two, actually - one for the fact that the selection in the first scenario isn't exactly as expected, another for the fact that the full measure seems to block the extension of the selection at all in the second.
But try having a whole note on one staff, two halves on the next, four quarters on the next, eight eighths on the next. Click the whole, then Shift+Down three times. Selection is now exactly as you'd want for the purpose of adding a dynamic to the first note of each staff. That was my point - reducing the selection to the shortest of the different durations, rather than expanding it to the longest, ends up being the right thing here.
In reply to "The current behavior does… by antonjazzsax
Linking to #306380: Extending range selection vertically - issue with rests
In reply to The behavior of Shoft+Up… by Marc Sabatella
"As for what blurred modes would look like, I don't know, basically the idea that you wouldn't have so many commands that work in one mode but not the other, or that work differently"
To be honest I cannot come up with the situation, where having all the commands working in all modes would not be helpful. I honestly tried, but just don't see it. Do you have a specific use cases in mind, where you want that some commands don't work in some mode? There might be some exceptions for sure, but maybe let's try to them first?
In reply to "As for what blurred modes… by antonjazzsax
Mostly it's about mouse interaction, not keyboard, but yes, I'd say most mouse interactions should be expected to work differently. When it comes to keyboard, only a few: things like what a number key or dot does in terms of duration, or the shortcuts to select voice, enable accidental, etc. But those are pretty significant.
In reply to Mostly it's about mouse… by Marc Sabatella
Mouse interaction yes for sure, although it is in a way predefined by the mouse cursor appearance. I meant keyboard shortcuts commands. The numbers and dots - true - although it is specifics of the note input mode that you first "prepare" the duration and then enter it, unlike in normal mode, so it still does the same in a way, that in normal mode and in note input mode pressing number selects the duration in the panel and that feels logical.
About the "shortcuts to select voice" - to me that's two different commands done with the same shortcut, because in note input mode you aren't really selecting anything by pressing that shortcut. it just enables second voice entry. To me that is not exactly intuitive, but not as bad as "swapping notes" and probably that is a valid exception.
However, even in the normal mode that shortcut "ctrl+alt+number" isn't making a selection, it makes the selected range into 2nd voice. It looks like we are actually missing the real "select 2nd voice" command shortcut. In fact correct me if I'm wrong, but there seems to be no such thing as "select 2nd voice from the range selection" exactly. Selection filter "subtracts", and "select similar" doesn't do exactly that either.
In reply to Mouse interaction yes for… by antonjazzsax
I'm not quite understanding the distinction you are making between selecting voice 2 and excluding voice 1. Or if Select / More / Same voice is what you are looking for. A real world example would help.
In reply to I'm not quite understanding… by Marc Sabatella
I think I said it before. Just to be clear: There is nothing in Musescore that one CAN'T do. At this point pretty much everything is about HOW it can be done. The thing is at the more subtle aspects of workflow, there is apparently a limitation of what can be discussed in the format of this forum. Honestly I can't. Would be too much. I just know what works better for the purpose and write it where possible. The video from Martin on Dorico is a great example of how design gets a "reality check" and it is great that he is doing that job. I guess that way of presentation is more effective. It does seem however that graphic interaction design of MS as a whole is better backed than the keyboard workflow at this point. At least that "roasting" video was mostly about that, but TBH there is probably an hour worth of video to be done on the keyboard editing in MS as well.
In reply to The idea of being able to… by Marc Sabatella
Dear Marc, in your last comment you mentioned some of specific issues that need to be addressed on a more objective scope of usability, not just to please former Sibelius users :). I believe you were relating to those asked in this comment above about range selection implementation in note input.
"How "selection" will relate to the "cursor" in terms of, for example, where the next note is entered if you press a letter key."
(looks like I can't answer your comment directly). Is that so, ot did you mean something else? It would be good to have your feedback on the specific suggestions that were made in this thread by Steve and myself in the posts below. Whether some of those meet your criteria to some degree. Thanks a lot.
In reply to Dear Marc, in your last… by antonjazzsax
I've responded above to some specifics. Let me know if there are others I missed.
I should note, I'm not the design guru here, I'm just one of the people who ends up implementing and documenting things, and also supporting the users who are confused when they can't figure something out or things don't go as expect or - worse - when something that used to work a particular way and people have relied on for years suddenly changes. So I try to be sensitive to all those concerns when giving input into the design process, to try make sure proposed designs don't cause problems that were not originally foreseen.