Right click menu in note entry mode and shadow notes
This is not really a feature request, but rather something I've already programmed and I'd like to know what you think about this or if you have any ideas for addions or improvements. I've implemented a right click context menu in note entry mode and shadow notes which represent the set duration while in note entry mode.
1. A new menu entry in the right click context menu (which opens up if you right click in the empty space while in note edit mode) enables the user to switch to note entry mode
I've already received a suggestion to implement this for all right click menues in note edit mode.
2. A right click with the mouse in note entry mode opens a context toolbar which allows the user to change duration, dots, accidentials, voices etc. on the note entry spot. The user can also exit the note entry mode, do some editing and reenter note entry mode by using the new menu entry introduced in 1.
3. If the user changes the duration of a note in note entry mode, the shadow note now shows the right note and not just a filled or empty note head.
Cheers
19joho66
Comments
I really like the shadow note idea!
I'm not sure the right-click toolbar is really necessary though (did you know you can drag the existing toolbar and put it wherever you want?) but I could see something similar being helpful on touch screen devices. On a touch screen, you could tap on a measure and then the possible note durations could appear as a menu radially around the touch position. Editing scores on a phone/tablet is probably not something you'll see in the next couple of years though.
In reply to I really like the shadow note by shoogle
Hi shoogle,
thanks for your comment.
The advantage of a right click context menu is, that you can do the selection on the spot where you enter the next note. After the selection the context menu disapears. A dragged toolbar doesn't do this and often is in the way somehow and then has to be moved.
In reply to I really like the shadow note by shoogle
I suppose that could actually be quite handy, especially on a laptop with a bad trackpad. What about making it so that the menu also pops up if you hold down left click? (Maybe if you hold it for 500 ms?) That would make it accessible on a touch screen too.
In reply to I suppose that could actually by shoogle
Shouldn't most touchscreens make that happen automatically? I definitely wouldn't want it when using a mouse or trackpad.
In reply to I suppose that could actually by shoogle
I don't know, it probably depends on the OS. I don't see how it would interfere with normal use since you would normally just click and release straight away (not hold the mouse button down). It's just something I though of a while ago for an interface for editing within the Android/iPhone apps. Holding your finger down could cause the different note durations to appear in a ring around the point of contact, then you move your finger to the one you want and release. If you lift your finger without moving it then the currently selected duration is used, so again it wouldn't interfere with normal use. The suggestion here is slightly different - hold for the menu, then release, then click the menu item - but either way would work.
In reply to I don't know, it probably by shoogle
You could make the same argument for many other contexts, in many other programs, but there's a reason that absolutely no application does this. A right-click is a right-click. Some systems may have different actions that access the secondary-click function (for example, on my laptop, it's a two-finger click), but that applies globally anywhere in the OS. A single application in which a long left-click turns into a right-click? That application would be annoying a lot of people. If you want that behavior, configure your system to support it. The idea of any desktop application doing this on its own is very surprising.
In reply to I don't know, it probably by shoogle
Secondary-click usually accesses a context menu, not a toolbar, so this would already be breaking a convention. In MS Word, highlighting a word (i.e. with left-click) displays a toolbar (see image), so I think left-click-and-hold, would actually feel more natural (or maybe even have the toolbar permanently floating at the current note entry point?). Right-click would be more annoying for me because I often press right-click by accident, but I never accidentally left-click-and-hold.
But I wouldn't want to just assume that what you or I find annoying is true for everyone, which I why I would like both to be enabled for testing within the nightly build. We decide which works best and disable the other in the final release. If we want to innovate then we need to be prepared to try new things.
In reply to Secondary-click usually by shoogle
I want to affirm that the concept of right click should be something that the windowing environment tells mscore through Qt immediatery. Not something that mscore tries to figure out on its own.
The android X-Servers and VNC's that I've tried out all have their own special way in settings to configure how to input right click (be it two fingers, double tap, tap in right side of screen, etc.). Additionally my bluetooth mouse has a right mouse button that works in my android X-server. And mac's I believe have their own way using Ctrl->click (I think).
Having access to the note-entry menu wherever the mouse pointer happens to be is great.
In reply to I want to affirm that the by ericfontainejazz
Sorry, I think you got the wrong idea about what I was suggesting. I just want the toolbar to be displayed by holding left click. I don't want left-click-and-hold to somehow emulate a right-click. I want right-click to do *absolutely nothing* (or maybe it would show a context menu, if relevant). Again, I point to the example of Microsoft Word where interaction with the left mouse button displays a toolbar at the editing position, and right-click only ever shows a context menu.
However, for the purposes of testing the feature (rather than just discussing it) I suggested enabling both options so that we could actually see what worked best by trying it out.
In reply to Sorry, I think you got the by shoogle
ok, thanks for clarifying.
In reply to Sorry, I think you got the by shoogle
Well, you did initially suggest it as "What about making it so that the menu also pops up if you hold down left click? (Maybe if you hold it for 500 ms?) That would make it accessible on a touch screen too," which I interpreted the same way Eric did. But temporarily implementing it both ways seems fair enough.
However, now I'm thinking about it further, I'm not sure how it would work. We're clear that this would only be available when in note input mode, right? And when in note input mode, left-clicking enters a note.
So you click, a note is added, hold, and then the note is deleted as the context toolbar pops up, allowing you to enter a note again—by clicking… and to get the toolbar back you click and hold again? Like I said earlier, there are reasons this isn't a thing already.
In reply to Well, you did initially by Isaac Weiss
The note would only be added when you release (not when you press) and only if you release before 500 ms.
Sorry for causing confusion re. input method.
In reply to The note would only be added by shoogle
Currently, the note is added immediately when you click, so that would be one more change—all to potentially be reverted if we go with the initial conception of right-clicking.
In reply to Currently, the note is added by Isaac Weiss
That shouldn't be too hard to change, but I'm actually starting to prefer the idea of having the toolbar float permanently just above the stave at the current editing position. This seems easiest of all and avoids the problem of discovery where users might not realise that they can right-click or left-click-and-hold to get a toolbar.
In reply to That shouldn't be too hard to by shoogle
I have to say out front that I don't like that idea. Changing something as fundamental as note input shouldn't casually "overwrite" a previously familiar interface, and that's exactly what that would do. Having that thing always floating there, following me wherever I go, always blocking my view of the score, just seems like an unutterably bad idea. Remember, the toolbar already is always present!
In reply to I have to say out front that by Isaac Weiss
An option of having toolbar appear to float above the staff is interesting, but I would like to be able to disable that, and would like to be able to configure the delay in milliseconds after which the toolbar appears (0ms for instantaneous/permanent).
I agree with Zack's caution, that I wouln't want to "overwrite" a previously familiar interface.
In reply to An option of having toolbar by ericfontainejazz
Tell that to Microsoft ;)
In reply to Tell that to Microsoft ;) by shoogle
I don't use any Microsoft software.
EDIT: That's actually not quite true; I used Skype once. :-)
In reply to I don't use any Microsoft by Isaac Weiss
I try my best to avoid it too, but I have to admit that MS Office is still way ahead of LibreOffice/OpenOffice. The floating menu is particularly nice, as is the ribbon interface (or it would be if they didn't keep messing with it).
A danger I see with the right-click toolbar is how to make it disappear if I didn't mean to right-click? Obviously I left-click somewhere else. But wherever I click a note will be added to the score. Now that would be annoying!
In reply to I try my best to avoid it by shoogle
>> "A danger I see with the right-click toolbar is how to make it disappear if I didn't mean to right-click?"
But I was actually concerned a little bit with having the floating toolbar always appear above staff: What if it is appearing ontop of some chord symbols or staff/system text that I want to edit?
So if I find the toobar is getting in my way a lot, I'd like to disable it.
In reply to >> "A danger I see with the by ericfontainejazz
Admittedly that would be rather annoying. Perhaps there could be a single floating icon that expands to a full toolbar when you hover over it? That would aid discovery without blocking much of the score.
In reply to I try my best to avoid it by shoogle
I don't doubt that Microsoft Office is still way ahead of LibreOffice (obviously it's ahead of OpenOffice). But at the same time, LibreOffice is significantly ahead of Microsoft Office (see http://www.datamation.com/applications/how-libreoffice-writer-tops-ms-w… for example). And at the same time, they really do have a 95-99% overlap in features (and I don't exaggerate numbers). I gather you like Microsoft's extra 5%. I like the ability to open AppleWorks documents. ;-)
Well, that was a nice birdwalk.
In reply to I don't doubt that Microsoft by Isaac Weiss
You're right, the gap is closing all the time, but for advanced users I don't think it's quite there yet. In terms of features they are more-or-less equivalent, but I find MS Office is far more polished. LibreOffice has some annoying bugs in basic features, like displaying PNGs with transparency. I find Microsoft's ribbon interface to be far superior to the 1990's style toolbars and menus that LibreOffice still insists on using. Excel and PowerPoint have better looking templates for graphs and presentations than LibreOffice Calc and Impress, etc. I mainly just use Google Docs now anyway, because its sharing a coloration features are unrivalled, but when I need something more powerful I end up using MS Office.
Anyway, back on topic...
In reply to You're right, the gap is by shoogle
The PNG thing seems to be a regression that only exists in one release from the "fresh" branch, and will presumably be fixed by the time it becomes the "still" branch (which is, after all, what they recommend for professional use). But isn't there another program that uses menus, one that saves files with the extension MSCZ? ;-)
In reply to The PNG thing seems to be a by Isaac Weiss
Indeed there is! But MuseScore's buttons are distributed among a number of windows and dockable panes rather than all jammed into one huge toolbar at the top. The best examples are the inspector, which only shows controls relevant to the current selection, and the Pallet pane, which allows irrelevant categories to be collapsed when not needed. This is analogous to how the ribbon interface in MS Office only displays buttons that are relevant to the current mode or selected item (e.g. Word has ribbon menus for Insert, Design and Page Layout, etc). There's still room for improvement though; ideally each mode would only show relevant options and nothing else, entering Playback mode could hide the Inspector and Palette panes for example.
Like ;-)
(because I rather use the mouse pad than shortcuts or midi input for note entry and editing on my laptop).
In reply to Like ;-) (because I rather by kuwitt
Same here, so a +1 from me ☺
I'm all for both ideas. However, in the last two screenshots, there's a vertical line partway through the staff to the right of the time signature. What's going on with that?
In reply to I'm all for both ideas. by Isaac Weiss
Thanks for pointing that out. That was a leftover from a testline. It is fixed now.
I've been persuaded that the shadow notes and floating toolbar are welcome additions (though I think the toolbar should appear on left-click-and-hold rather than right-click, or maybe even just permanently float above the current note-entry point), but I'm unconvinced by the right-click option to enter note entry mode when there is already the keyboard shortcut "N" readily available. We wouldn't want the right-click menu to get too cluttered (e.g. Playback mode, Replace Pitches mode, and, when it arrives, Real Time Note Entry mode). Any thoughts on this?
In reply to I've been persuaded that the by shoogle
-- didn't mean to reply here...my comment is a new one at top-level of this thread https://musescore.org/en/node/99536#comment-442861 --
Regarding: "but I'm unconvinced by the right-click option to enter note entry mode when there is already the keyboard shortcut "N" readily available."
I would say there are definate use cases where don't have easy access to keyboard, which I've encountered, incuding:
I'm copying my comments I made on jho's PR "Shadownotes during note entry #2313":
and on his PR "Right click menu in note entry mode #2401":
Regardin what should be in the context menu, I also wrote:
I think that new users might be overwheleved if there is too much stuff in right-click menu, due to information overload. But I also feel that pro-users will want all these extra things to improve efficiency. Mscore already does something similar with the Pallete (starts in default beginner mode as, but user can change to advanced mode and add custom palletes).
In reply to I'm copying my comments I by ericfontainejazz
I think right click context menues are a great way to speed up the workflow if you use the mouse. I use REAPER a lot and there the right click context menues are used extensively. Specialized context menues makes it uneccessary to use the menubar at all. The use of a menubar always involves the moving away from the element you are working on, clicking several times through the main menu until you get the entry you need and then you have to go back and find the element again. With a right click context menu, you just click right once and have all the relevant commands at the spot where your element is. After selecting the command the menu is gone and you can go ahead in your workflow.
I got so used to this, that if I want to do anything in REAPER I first use the right click to see if the desired command is in the context menu. (And in 95% of the cases it is).
That is also the reason why I came up with the idea of a context menu in the note entry mode. I really missed this feature.
In reply to I think right click context by 19JoHo66
I'm not disagreeing with you, and I support your PR, although the one thing I think needs to be fixed before merging is:
In reply to I'm not disagreeing with you, by ericfontainejazz
Sorry, when I commented I pressed the reply button. I didn't mean to reply on your comment but place a seperate comment.
I agree with your suggestion, and will fix that soon. I didn't find the time yet to do so.
Do I have to remove the PR until it is done?
In reply to Sorry, when I commented I by 19JoHo66
I don't know what the rules are about PR. lasonic is the person who merges PRs. I always just squash & recommit to the PR branch when I'm ready, and no one has said anything to me about that. Although all the core developers get an email when the travis build completes, so best to not recommit to the PR too often.
In reply to Sorry, when I commented I by 19JoHo66
Just add your changes to the last commit with `
git commit --amend`, or create a new commit and then squash with the previous with`git rebase -i HEAD~2`. Probably a good idea to rebase against upstream:master at the same time, then push back to the same branch with `git push -f <branch>`. If you're worried about sending too many notifications then create another branch to run your own tests and then cherry-pick commits back into the issue branch, but probably needn't bother doing that here since you can just run the tests locally.Maybe leave a note on the PR to say if you might make some more changes or if you think it's ready to merge.
In reply to I'm not disagreeing with you, by ericfontainejazz
@ ericfontainejazz
As you've suggested, I've now added the menu entry to the other context menues as well.
Just a note that I checked out and compiled the right-click branch, and I really love it just the way it is.
for the record, the PR is at https://github.com/musescore/MuseScore/pull/2401
In reply to for the record, the PR is at by Jojo-Schmitz
and the other (shadow notes) at https://github.com/musescore/MuseScore/pull/2313
In reply to and the other (shadow notes) by Jojo-Schmitz
The shadow note duration is now merged on master.
Note that
1/ it doesn't include dots
2/ it doesn't move the mouse automatically like the original PR was doing.
I used it quite a bit during the past 2-3 days and I'm not yet 100% convinced that it's an improvement. So feedback is still welcome.
In reply to The shadow note duration is by [DELETED] 5
Not having the dot is a little bit of a bummer. Also, it seems like the stem direction should flip depending on the height in the staff. Maybe it wouldn't be too difficult to tweak it for those?
In reply to Not having the dot is a by Isaac Weiss
I'm not sure it's worth trying to calculate the stem direction, since it depends on many factors (position in staff, voice, also beam status which could well include notes not yet entered). I think it would be a lot of work to still not always be "right", and in any event, I sincerely doubt it will be seen as confusing that the stem flips. More disorienting to see if change as you drag actually. And besides, it's not like the toolbar icons change.
In reply to I'm not sure it's worth by Marc Sabatella
I've done an in-depth comparison between the major scorewriters, and I recorded GIFs of what their "shadow notes" do, inputting an eighth note D4 followed by a dotted quarter F4.
These are in order from worst to best, as I see them.
1. MuseScore 2.0.3:
Notehead only. No stem, no flag, no dot. Not good.
2. Nightly eaa0322, post-19joho66's improvements:
Stem and flag included. Still no dot, so duration is not all there. Stem direction does not match staff position.
3. Finale:
Stem, flag, and dot all included. Stem direction does not match staff position.
4. Sibelius:
The ideal. Stem, flag, dot, and stem direction all together, showing you exactly what's going to be placed on the staff.
In reply to I've done an in-depth by Isaac Weiss
Just curious how accurate Sibelius' stem direction is if the note is part of a beam group. Obviously, it can't know what notes will be entered later so it's going to be wrong a lot regarding the *final* position, but I suppose it could get it right regaridng the *initial* position. Like, if you enter eighth notes, two middle C's, then a C an octave higher - does it correctly show you the stem will actually be up, at least initially?
In reply to Just curious how accurate by Marc Sabatella
No, none of them do beams.
In reply to No, none of them do beams. by Isaac Weiss
Agree for stem direction, and dot.
From my part, I am also and maybe more disturbed by this behavior in a multivoice context (and on a single staff), essential in the guitar writing.
This behavior adds a regrettable visual confusion to the entering of notes, by creating collision between notes (at least, a part of noteheads, and flags etc.) And I am not a big fan of collisions of all kinds!
Of course, I just begin to test this. But the very first impression is not good here, sorry.
Some examples:
![Ok voix 3.jpg]( "Ok voix 3.jpg")
![NON, voix 3.jpg]( "NON, voix 3.jpg")
With the 2.0.3:
Currently (last nightly f97b265 )
Other, with the 2.0.3:
![OK version 22.jpg]( "OK version 22.jpg")
![NON version 23.jpg]( "NON version 23.jpg")
Currently:
In reply to Agree for stem direction, and by cadiz1
I just added stem direction and dots.
The algorithm for stem direction is simple (maybe too simple). Voice 2 and 4 are always down. Voice 3 always up. Voice 1 is up below above middle B in G clef, down above. And so it's ugly if the chord change direction with the new note... Feedback very welcome. The more I see it, the more I like the 2.0 implementation.
In reply to I just added stem direction by [DELETED] 5
Right now there's a thick blue rectangle appearing around the shadow note.
In reply to Right now there's a thick by Isaac Weiss
I know I initially expressed support, but after I've read cadiz's comments, I'm also noticing that things can at times be a little too cluttered, especially when there is already a lot of ink already. Anyway, I think there should be a preference to disable shadow notes if not wanted, but I know I have the minority viewpoint about allowing most things to be configurable.
I like how sibelius is using a light grey for their shadow notes. I sortof find that easier on the eyes than the full color which musescore is using now. I'm thinking maybe having the shadow notes be colored in a light grey will alleviate some of the information overload.
(I presume those rectangles are just being use now for debugging purposes, since it reminds me of what happens when I run older musescore in debug with -d command line flag.)
In reply to I know I initially expressed by ericfontainejazz
Sorry it was late. The debug rectangle is gone.
In reply to I just added stem direction by [DELETED] 5
I like it. Maybe voice 1 stems could be made more clever, to up if there is something in another voice
In reply to I like it. Maybe voice 1 by Jojo-Schmitz
By trying again, I started bitching ... Because the blue color of the Voice1, now, was the same like the instruments names, time signatures, etc. in the Continuous View (and I don't like it yet, because too washed out, and because the blue - this blue- is always showed, and re-showed, into the instrument forums and other forums of all kinds ...) Anyway, personal feeling!
Before I realized that after the entry of the note, this note (notehead) reverted its original color, more intense, a true color, what!
![bleu 2.jpg]( "bleu 2.jpg")
The same for the other voices (and colors)
I suppose of course that this is intentional! And I must admit that it's rather well done!
These "translucent" colors ( (including stems and flags, which was my main complaint in a previous message) have the power to reduce the impact of the possible information overload and visual inconfort (I mean mainly in a multi-voice context). Of course, the improvment of the stem direction participe to this.
I will issue perhaps some reservations (or not) after further testing, but for now, I feel much better than yesterday noon!
In reply to By trying again, I started by cadiz1
This is good. Definitely a step forward, not back.
In reply to This is good. Definitely a by Isaac Weiss
Just a couple of issues: #114116: Over-bright shade of green for voice 2 shadow note and #114121: Regression—shadow note appears during keyboard entry.