can't type 'm' in lyrics mode when 'm' is used for 'toggele metronome playback'.

• Nov 24, 2015 - 19:19

1. Set for 'toggle metronome playback' shortcut 'm'.
2. try to type in lyrics mode lowercase 'm'.
3. It's not possible to type 'm'.

I did'nt try other assignments with 'm'. I use OSX El Captain and Windows 8.

Little bug but i hope it can be solved. Happy musescoring!

Best, Philip Bergwerf


Comments

I've seen this posted a few times, now, regarding different shortcuts. I use a self-compiled linux version and don't have any problems but this strikes me as a significant bug if, in other OSs, keystrokes are being captured in lyric input mode and enacted as shortcuts.

In reply to by underquark

As Marc pointed out in this reply to the other thread linked above by Stoichi, each short-cut has a list of modes in which it is active.

If a short-cut is active in a certain text mode and boils down to an alphanumeric character, that character will no longer be available for that text entry mode.

Now, why the short-cut for "metronome" should be active in lyrics text entry mode is not obvious, it might be simply an overlook, or something else. As Marc concluded there: " Worth revisiting for sure".

I am revising the whole matter of the interactions between text editing / short-cut / state and some advise / comment would be useful.

Background: MuseScore currently knows about 3 textual editing states, namely:

  • Lyrics edit
  • Fig. bass and chord symbol edit
  • Generic text edit (covering all other cases: staff text, system text, tempo text, ...)

Each short-cut can be enabled in a given state or not.

Summary of current situation:
This is a summary of which short-cuts are enabled in which textual state (short-cuts having specifically to do with note entering or other specialized tasks are not listed):

  1. In NONE:
    "local-help"
  2. In NONE under Win/Linux but in LYRICS under OSX (with a comment saying "//Avoid conflict with M in text" ???):
    "toggle-mixer"
  3. In LYRICS only:
    "file-open"
    "file-save"
    "file-save-online"
    "file-save-as"
    "file-save-selection"
    "file-save-a-copy"
    "file-export"
    "file-part-export"
    "file-import-pdf"
    "file-close"
    "file-new"
    "print"
    "toggle-palette"
    "toggle-playpanel"
    "toggle-selection-window"
    "toggle-navigator"
    "toggle-midiimportpanel"
    "toggle-statusbar"
    "quit"
    "mag"
    "rewind"
    "zoomin" (but NOT "zoomout" because of [Ctrl]+[-] conflict)
    "zoom100"
    "hraster"
    "vraster"
    "config-raster"
    "media"
    "page-settings"
    "inspector"
    "metronome"
    "countin"
    "next-lyric"
    "prev-lyric"
    "startcenter"
  4. In LYRICS + TEXT:
    "cut"
    "copy"
    "paste"
  5. In LYRICS + TEXT + FIGBASS/CHORD:
    "escape"
    "show-keys"

My plan is to

  • Disable all short-cuts currently enabled only for Lyrics, including the strange OSX exception for "toggle-mixer", with the exception of "next-lyrics" and "prev-lyrics" which are specialized exactly for them and shall remain enabled.
  • Enable "file-save" (and "file-save-as"?) for all textual states (I often find convenient to save the score no matter of the state I currently am)

Anybody can spot problems with this or has additional suggestions?

Thanks, M.

In reply to by Miwarre

OK, I'll try to be more detailed:

Yes, the origin of this specific issue is group 2) above, but all actions in groups 3), 4) and 5) may result in similar problems if their short-cuts (either default or customized) are not chosen wisely, so it is important to keep all those groups to the minimum indispensable.

  • Remove 2., i.e.: OSX would no longer be an exception in dealing with "toggle-mixer": this action would be disabled in all textual edit modes.
  • Remove 3. except "next-lyric" and "prev-lyric", i.e.: those actions will no longer be enabled in any textual editing mode (except "next-lyric" and "prev-lyric" which would enabled in LYRICS mode only, for obvious reasons).
  • Leave 4. as it is.
  • Add to 5. "file-save" (and possibly "file-save-as"?), i.e. those actions will enabled in all textual editing modes, as I find usually convenient to be able to save the score no matter in which state I am, and I assume other peoples might find this useful too; as these actions are usually mapped to non-alphanumeric short-cuts, they could hardly create problems while entering texts (but, yes, should they be remapped to, say, [S] and [Shift]+[S], this would prevent the 'characters 's' and 'S' to be entered in texts).

This would result in the following new groups:

  1. NONE (inactive in all textual editing modes)
    "local-help",
    "file-open"
    "file-save-online"
    "file-save-selection"
    "file-save-a-copy"
    "file-export"
    "file-part-export"
    "file-import-pdf"
    "file-close"
    "file-new"
    "print"
    "toggle-palette"
    "toggle-playpanel"
    "toggle-selection-window"
    "toggle-navigator"
    "toggle-midiimportpanel"
    "toggle-statusbar"
    "quit"
    "mag"
    "rewind"
    "zoomin"
    "zoomout"
    "zoom100"
    "hraster"
    "vraster"
    "config-raster"
    "media"
    "page-settings"
    "inspector"
    "metronome"
    "countin"
    "startcenter"
  2.  
  3. Active in LYRICS only
    "next-lyric"
    "prev-lyric"
  4. Active in LYRICS + TEXT
    "cut"
    "copy"
    "paste"
  5. Active in ALL text editing modes (LYRICS + TEXT + FIGBASSCHORDS)
    "file-save"
    "file-save-as"
    "escape"
    "show-keys"

Is this clearer?

Thanks! M.

In reply to by Marc Sabatella

@Marc Sabatella:

A) "I think zoom & help should probably be active in all text modes": "zoomout" action cannot be enabled as its default short-cut conflicts with the "hard hyphen" short-cut, so the situation would be asymmetric anyway. Also note that disabling the "zoomin/out" actions does not disable neither the mouse wheel zoom or the zoom dropdown list, so zooming remains possible in one way or another.

For local help, you are probably right: any reasonable short-cut (either default or customized) for it would hardly be an alphanumeric character, so it can probably be enabled. So, "local-help" can be moved from 1. to 5.

B) "I'm not sure why cut/copy/paste should be excluded from chord symbol mode": I'm not sure either; this is the situation as I see it in the code. Telling from my experience with Fig. bass, which shares a number of characteristics with chord names, copy / cut / paste of sub-text portions (as distinct from copy / cut / paste an entire Fig. bass element, which remains possible) is hardly needed or useful.

If you think it can be useful and do not see any problems (e.g.: are [Ctrl]+[C] / [Ctrl]+[X] / [Ctrl]+[V] or other common short-cuts for those actions ever used or potentially useful to enter special chord symbols?), they can be enabled for chord mode.

Let me know and can provide a PR rather quickly.

Thanks, M.

In reply to by Miwarre

Good point on the zooming. No big deal.

As for copy paste, I could definitely imagine it being used while entering chord symbols. Like if you enter a chord symbol like Cmi7(b9,b13)/F then wish to enter Bbmi7(b9,b13)/F, I could totally imagine someone wanting to copy and paste the "mi7(b9,b13)/F" from one to the other. But the fact that I never noticed it doesn't currently work, and no one has complained to my knowledge, suggest it isn't that big a deal either :-). Still, I don't see any reason not to enable it.

Do you still have an unanswered question? Please log in first to post your question.