in Note Groups UI make palette selectable, then click notes to toggle between selected beam property and auto

• Feb 18, 2017 - 15:37
Graphical (UI)
S5 - Suggestion

When creating a custom time signature, dragging and dropping beam properties to lines of notes is tedious and not the most intuitive method of changing beam properties. Add a click or double click method to add beam properties to note regions.



Can you describe what you have in mind in more detail? What I like about the current method is that you *don't* have to use drap and drop for the most common case - breaking or joining simple beams. A single click does the trick. Only the sub-beam options require drag and drop. If we made it so you first click the note then double click the icon, that actually makes the most common case harder. Probably there is a way to get the best of both worlds, but it isn't clear to me exactly how. Something like single click the note to merely select it, double click to do what single click does not wouldn't be a big step backwards in actual effort, but it is a bigger step backwards in discoverability.

Indeed. But I would still like to see discussion of the issue I raised: changing the behavior to allow single click of note followed by double click of icon (making it work the same as the regular palettes) actually *doubles* the amount of work required in the usual case; it only helps with the sub-beam case. So I'd like to see a concrete proposal for a system that helps the sub-beam case *without* compromising the usual case.

I personally would not want to change the current default behavior of just single clicking doing the trick.

The way I advocate for this is to have the the first beam property (Beam Start) be selected in the palette initially when the UI is first opened. And I would have the behavior such that clicking on a note would toggle between the current selected beam property and Auto. Which would mean get the same behavior if left the first beam property (Beam Start) selected.

I want to note that NoteGroups::noteClicked() currently starts with:

      if (chord->beamMode() == Beam::Mode::AUTO)
      else if (chord->beamMode() == Beam::Mode::BEGIN)

That is from Werner's commit 4 years ago. I have a slight issue with this: I think that the the else condition should just be a regular else, not an else if, such that if clicked on a note with any one of the other beam modes (BEGIN_32 or BEGIN_64), then that beam would revert to AUTO.

Anyway, the pseudocode for how I think this feature would work in this function is:

      if (chord->beamMode() != selectedBeamMode)

The only way to change to the beam with 8th on the left and 1/6th on the right is to drag it there. This just doesn't make sense. There should be some click sequence that will allow you to change to any of the possible beams rather than simply toggling between middle beam and start beam. Since most users (like me) don't input their opinions on issues, we're not likely to get feedback on this from too many people who are not developers.

mike320, the pseudocode I proposed in #5 is doing what you are requesting in #6.

I also discovered that palette cells can be "selectable" by calling palette->setSelectable(true).

I'm going to go ahead with my proposal.

Title Click to add beam property to note region in custom time signature in Note Groups UI make palette selectable, then click notes to toggle between selected beam property and auto

This title reflects how I'm implementing this feature.

I tried it and it works as advertised. I'm not sure I like it.

First, dragging doesn't work at all anymore but we can still drag from the palette
Then, the previous behavior of toggling is kept but only with the first item selected.

I don't know what you mean by "dragging doesn't work anymore" because I remember making sure dragging still works. The only difference I caused with dragging is that whatever was last dragged becomes the new selection, that behavior I unintentionally introduced.

Also I don't understand your second sentence.

I had to rebase the code...there was some divergence that might have caused it to not behave properly, and there was also a typographical error in my code where I had one of the beam properties swtich case confusing AUTO with MID. And to be honest, I'm also a little bit bothered myself by how "AUTO" means something slightly different inside noteGroups.cpp than it does in the main score. It seem inside noteGroups.cpp it will mean that the beams are connected left and right (like MID), but in the main score it means to use whatever the time sig says. Which is a bit confusing because if in note_groups.ui the user is defining what AUTO is for each note...

I'm going to make a few more enhancements before I repush the PR:

  1. I don't think "AUTO" makes any sense inside the seems that auto is basically "MID" in that file. What I'm going to do is not have AUTO anywhere inside noteGroups.cpp, and have the default newly constructed time sigs be called MID instead where it is currently "AUTO". There isn't a AUTO beam property in note_groups.ui palette anyway. So that means the default toggling behavior would switch between the current state and START. I hope I'm not totally confused.
  2. I think that there need to be a tooltip that displays the state of the beam property for the nothead that you are hovering over. This is important because it is somehow not possible to know what the beam property of a note is just by looking at it's beams, because the beaming also depends on its neighbors
  3. I'm thinking about modifying palette code so that if drag a cell then won't change the selector to that cell...this is to prevent that Beam Property mini palette in the note_groups.ui from changing its selected index when the user is simply dragging & dropping.
  4. Oh, and I'm regretting putting the horizontal spacer between the reset button and the BeamProperties palette group box. I'm going to instead put the spacer to the right of the beam Properties palette group box. That way the beam properties palette doesn't move too far right (and away from most of the notes) when moving the right hand side of the window.
  5. I also think the "1/8", "1/16", "1/32" aren't actually useful because user's brain can already figure out what each score view represents. All it does it is take away valuable realestate needed for displaying the very wide 32nds. Maybe I'm being a little too nitpicky with that, though...

Update: To keep the previous behavior the same, I'm not starting out with any palette cells selected initially. When click on a note without any cell selected, I've left the original if statement for that case, so behavior is identical to previous.

I repushed with following behavior:

  1. Increased the clickable region such that click event will change beam mode of nearest note (so can click on whitespace).
  2. If a palette cell is selected, then click on notes will change to the selected beam property.
  3. If no palette cell is selected, then keeps prior behavior whereby clicking notes toggles between palette's currently selected beam mode and mid.
  4. Reset button will now remove the palette's selection.
  5. Removed the unnecessary labels "1/8", "1/16", "1/32" from the UI.
  6. Moved the hspacer on the UI to be to the right of the palette.

The issue tracker does not indicate that this has been merged, but much to my delight it has been. There are two things that you said were going to be different than what was merged.

1. The 1/8. 1/16 & 1/32 labels are still there (but that doesn't matter to me.
2. Clicking the palette does not set the beam mode to the last selected beam, it continues to toggle between middle and start...After further testing I realize it just doesn't work as expected. I will continue to test and elaborate on this feature in another post.

Two HUGE improvemnts are present.

1. The "also change shorter notes checkbox" which IMHO should default to checked which is does not
2. Scrollable long note lines. You can actually change the 32 note grouplings beyond about 4 beats.

This issue's PR has yet to be accepted. I think lasconic had disagreements with feature (read the PR comments on github).

The two huge improvements you mentioned were different story issue PRs which were accepted.

Testing on the 32nd note line using the default 6/8 time signature:

Click on Beam 16th sub then a note makes it a beam start
multiple clicks toggle between start and middle (I will now reset)
double click on beam 16th followed by single click on a note leads to toggling between start and middle as above (reset)
Dragging beam changes the note to the correct beam; however, the beam can only be changed by dragging another beam to it.
If you drag a middle or start beam, then you can then click to toggle between middle and start by clicking on it.

On the 16th note line:
Dragging the Beam 32nd sub to a note looks like a middle beam but acts like a 32nd sub beam. As a result, clicking does not toggle between start and middle beams as the uninitiated user would expect. It should do nothing-no visual or internal change regardless of original state of the beam.

I decided to test 2.0.3, which I had not systematically done before, and now realize this is the same behavior as before. If that is what is wanted, then I can live with that. I do think the 16th note line needs to be fixed though.

I'm not going to make customized version of MS with my current configuration. I have limited data I can download before my speed falls to nearly modem speed (actually 2G) :(

I looked through the issues concerning this and didn't see anywhere that your work had been merged. I accidentally discovered it by using MS, which I do a lot.

Status PR created active
Reported version 2.2  
Regression No
Workaround No

The pull request got archived. Also I am not sure whether this suggestion is actual with the recent single-click palette changes, although it still might be applicable.

In reply to by dmitrio95

As far as I can tell, drag & drop is still required to apply the "sub-beam" options (ordinary join & break work fine with just a click on the note groups). So sub-beam is not keyboard-accessible at all right now, it seems. Worth addressing for sure, although probably not the highest priority such issue.