Chord symbol entry - tab and space not working

• Feb 16, 2013 - 10:12
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

In 2.0, the tab and space keys for moving to the next measure or beat do not work. This is due to the underlying architecture being different from in 1.2, so that they were never implemented in 2.0 when being added to 1.x.

I plan to work on a fix for this using a similar technique to that used by Miwarre for figured bass positioning.

See the discussion on the dev mailing list.

Comments

• Mar 14, 2013 - 16:33

Just to summarise here, this patch provides the following navigation in edit mode for Chord Names:

  • Tab/Shift-Tab - start of next/previous measure.
  • Space/Shift-Space - next/previous existing note, rest or chordname.
  • ;/: - next/previous beat, according to time signature.
  • Ctrl-1..Ctrl-9 - move forward by specified duration (like figured bass).

For ;/: and Ctrl-1 to Ctrl-9, the target position does not need to have a note or rest.

Reply

• Mar 14, 2013 - 18:29

We did talk on the mailing list thread about whether space should do that, and it was a compromise between compatibility with 1.2 and consistency with figured bass.

Marc also mentioned the occasional tedium of having to keep pressing space to work your way past a sequence of short notes when trying to get to the next beat position.

The ";" was Marc's suggestion and I quite liked it. In general, "Shift" means go back, and on US and UK keyboards, ":" is shifted ";" (US and UK ). That's why ";" goes forward and ":" goes back. I see the French AZERTY keyboard has ":" to the right of ";", which makes it feel the wrong way round.

It was actually quite nice in the code to keep ";" for beat separate from Space for segment, but we can certainly revisit the decision if need be.

I'm open to suggestions!

Reply

• Mar 14, 2013 - 19:15

As for semicolon / colon, if the shortcuts are customizable, it's no big deal to me what the defaults are. But I could imagine these won't be customizable, since they are mode-specific. So it's probably important to make them work well in a reasonably keyboard-independent way. I might still argue that the having semicolon for forward and colon for backwards makes (some) sense even if the semicolon is to the left: it's going to be the more commonly-used key, so it (kind of) makes sense to have it closer to the rest of the keys used in chord entry. But that's admittedly reaching a bit.

As for space bar, I still don't have strong feelings about the consistency with figured bass on this point. With a separate shortcut to move by beat, I suspect I'll stop using space for the most part, so it won't affect me much one way or the other. I will say this, though: we didn't get a single complain that ai can recall about space bar stopping on beats. I suspect we'd get a few if we backed that out, even though to my mind the semicolon to go by beats only if a preferable solution. But there would be some number of people complaining who, for whatever reason, don't want to make that adjustment.

So I guess I'm leaning toward keeping the current behavior of space, while definitely adding the semicolon/colon (or whatever people think are better shortcuts) to move by beat only.

Reply

• Mar 15, 2013 - 13:07

The problem with ; and , is discovery. Most people will use space to "enter the next chord". If the cursor is not where it should be, they will just press space again, and would expect MuseScore to stop "where they want"... So from a beginner "I never read the manual" point of view, the behavior of space like it was in 1.3 is much more "discoverable" IMHO.

Reply

• Mar 15, 2013 - 14:49

OK, I'm convinced! :)

I'll update harmonyBeatTab() so that it takes a flag telling it whether or not to stop on intermediate notes and rests when it's looking for the next or previous beat. Then space/shift-space can call it with the flag true, and ;/: can call it with the flag false.

Reply

• Mar 16, 2013 - 00:03

I see that the point is already decided but, just for the record:

Consistency with Figured Bass is not SO important from my point of view; as I said on the dev list, I expect that only few users would use both features (chord symbols and FB) and then would notice the difference.

Consistency IS important, of course, but not at the expense of ease of use. In the end, the decision made seem very reasonable to me too.

Thanks,

M.

Reply