TABs keyboard note entry: ready for testing

• Sep 2, 2012 - 12:08

...well, almost!

First of all, a nightly version 74b4a45 (2012-09-01) or later is required. Currently, such a nightly is only available for Mac but it should be available for Linux soon and for Windows as soon as Win nightlies will be resumed. A self-compiled version from Github can also be used, of course!

Changes:

1) During note entry in TAB staves, the entry cursor (the 'blue rectangle' cursor) does not span the whole staff vertically as for other staves, but only one string: this is the current string. Initially, the current string is the string of the selected note, if any, or the topmost string if no note is selected.

2) Two shortcuts have been added: one to make current the string above ('blue rectangle' goes up) and one to make current the string below ('blue rectangle' goes down).

3) 10 other shortcuts have been added to enter a fret mark 0 to 9 on the current string. More shortcuts (10 to 19 or even 10 to 29) will be added once the system is proven correct and stable enough. For the moment being, these should cover the majority of cases; ShiftUp can always be used to raise the note without changing string.

4) Shortcuts removed. A number of shortcuts have been removed while in TAB note entry; all those referring to absolute pitches (like "A" or "Add A to chord") and to intervals (like "Add a fifth"), as they make little sense while working on a TAB. Of course, those shortcuts ARE still available in other staff types.

5) Actual shortcuts. I had to choose the new predefined shortcuts among the few combination still available (mostly Alt combinations) and the result is somehow awkward. These are the default:

AltUp: current string above
AltDown: current string below

Alt0: enter fret 0 (or 'a' if letters are used)
...
Alt9: enter fret 9 (of 'k' if letters are used)

As an alternative, AltA to AltK are also set to enter frets (same meaning as above: i.e. either numbers or letters can be used to enter, and frets will be displayed as numbers or as letters according to TAB properties). Unfortunately, AltC, AltD, AltE and AltF are intercepted by the operating system to display the "Create", "Display", "Edit" and "File" menus respectively, so these combinations are not actually available! (This applies to the English version; for other languages, any letter which happens to be used for a menu will not be available).

6) All shortcuts are configurable as usual.

Note on first time usage
After running the nightly with this update, you may need to reset all shortcut customizations or the new shortcuts will have no predefined value (they will there but without any key associated). To reset them:
"Edit | Preferences | "Reset to default" (the one near to "Clear", not the general "Reset")
It is inconvenient, I know, but it is one of the drawbacks of working with an experimental version...
OR: you can enter your own key combinations for those shortcuts as usual.

Feedback requests

1) Does the whole work as described above?
2) Has some special case been left out?
3) Can shortcut defaults be improved?
4) Suggestions for the additional shortcuts.

Thanks,

M.

Comments

• Sep 12, 2012 - 23:11

I haven't been able to get this to work on Mac. I'm using one of yesterday's builds - c0faed4 on Mac OS X 10.6.7.

I've reset to defaults but although the Alt-Up and Alt-Down work, neither number nor letter combinations for note entry work.

I've tried on Windows 7 with the same version and that does work as described. It's very useful and certainly a lot easier than using the mouse on tablature.

I think you included shortcuts that cover most use cases but there are a couple of other things which may be useful. One is shortcuts for changing voice - I've no idea how many people will be using TAB entry for multi voice music but I'm sure there will be some.

The other I only mention because you're talking about TAB note entry but I'd see it as fitting in somewhere else rather than here as it would be a global setting and applies as much to TAB conversion from a pitched staff. That is the ability to set a capo. For example setting the capo at the third fret would prevent use of open strings and frets 1 and 2.

Reply

• Sep 13, 2012 - 17:39

"I haven't been able to get this to work on Mac. I'm using one of yesterday's builds - c0faed4 on Mac OS X 10.6.7."

I know nothing about Mac and, in particular, about musescore specificities for Mac: I may well have forgotten to set something up for Mac if it has specific requirements. That 2 short cuts work seems to imply at least those 2 as set up correctly (but the other are similarly set up): let's ask lasconic, he knows about Mac specifics.

About voices: well, currently TABs do NOT support voices (only voice 1)! From one side, voices make little sense on tabs; OTOS, converting pitches to frets would be rather complex, as chords from different voices are stored in different points. Also, it makes rather cumbersome to create either duration symbols (historical tabs) or stems (modern tabs).

So, the whole issue of voices in tabs is postponed.

Capo: I assume it is what I know under the name of capo tasto. I know, it is another open issue; I should 'sit down' with Werner (well, except we live in two different countries...) and figure out the best way to do it. It is a kind of temporary overcome of the instrument definition.

One thing I have never understood: when you use a capo tasto, frets numbers changes or not? I mean, do they become relative to the capo tasto or keep the same values as without? In other words: with a capo tasto on 3rd fret, do you jump from 0 to 4 (0 meaning the 3rd fret) or still use 1 and 2 to mean the 1st and 2nd fret after the capo tasto?

Thanks,

M.

Reply

• Sep 13, 2012 - 18:39

Thanks for the answers

"About voices: well, currently TABs do NOT support voices (only voice 1)"
That makes sense. I hadn't noticed because until I tested this I'd always created tabs by inputting on a pitched staff and turned off stems and beams in the (linked) tablature. Forget I mentioned it ;-)

"Capo: I assume it is what I know under the name of capo tasto."
That's right. I don't think I've come across it in unabbreviated form in English but capotasto is certainly what I'd use in Italian.

"when you use a capo tasto, frets numbers changes or not?"
Good question. I'm not sure if there is a standard but treating the capo as the new "nut" of the guitar (or other fretted instrument) and counting from that would be a lot easier to read because common chord shapes would be immediately recognisable. It also makes it easier to play the score if the player doesn't have a capo to hand, it would just transpose it down to a lower key. So if it's set at the 3rd fret that becomes 0 and the 4th fret becomes 1 etc. A capo is often just used to change key which is also an argument for this method. I would expect it to be easier to code as well as it would effectively just be an overlay changing the tuning of the strings.

Reply

• Sep 14, 2012 - 02:25

The TAB and standard notation I've seen treat a guitar with capo as a transposing instrument. There is text indicating the capo position (e.g. "capo II") and the notes and fret numbers are placed as if there were no capo. When I use MuseScore to score a piece with capo, I typically edit the staff properties and set "Play Transposition:" as necessary, e.g. "Major Second" for capo on 2nd fret. That makes playback transpose to the correct key. (There may be other ways to handle this with MS too.)

Reply

• Sep 13, 2012 - 17:18

Sorry that I am not in a position at the moment to install the nightly, but I would like to say that I am so excited about this development! You guys rock!

Reply

• Sep 15, 2012 - 11:58

We've been discussing this a bit on IRC, but let's sum it up here. I would like the possibility of having one note in the normal staff and repeat this note on several strings for a freted instrument. Look at this tab for a G major chord:

e +---3----+
b +---3----+
g +---0----+
d +---0----+
a +---2----+
E +---3----+

Here we play g, d, g, d, c, G. Two of g, two of d, one of each c and G. Four different notes in total. For a normal score, this would be written with four notes, but in the tab it would be written either as damping of two strings or as above.

The example above is made up to show a usecase for guitar. However, I am using MuseScore to write balalaika sheets. A balalaika has three strings tuned a, e, e. The a string plays melody and the two e strings is for base. Often you play the same note on both strings. In normal balalaika sheets, you write this in the tab like

a +---3----+
e +---1----+
e +---1----+

but in the normal score staff you only see two notes, c and f.

It is possible to do this with the current nightly. However, I have only found one quite painful way, as it is not intended to do it. I can have two linked staves, one normal and one tab. I first insert c and f by hitting c, shift+f. Then I insert another note close to f, like e, then move it with arrow key until it overlaps f. Now in the normal score, only two notes are shown, but in the tab I see all three of them.

I was told that in a previous version of MuseScore, you could add several notes of the same kind by just pressing shift and insert as many you liked. They was just stacked. However, this was considered bad behavior, so it was changed to just toggle the note on and off. I understand that in normal case toggling is easier to explain. However, in this case, stacking would be a solution to my problem.

Suggestion: Add the posibility to stack notes again, in order to make it possible to acchieve the above mentioned scenario in a natural way. For instance by pressing shift+control+note.

In tab mode, I find this new feature convinient, moving the cursor and controlling notes by alt+arrows and numbers. Also with this method, you would be able to implement a way of acchieving my feature request. There must be a little change though. Now, if you have inserted some notes and/or chords in the normal staff, then go to the tab to modify it, you overwrite the inserted notes. Even if you go to a string where you have no notes and try inserting one with alt+number, other notes will be gone.

Suggestion: Add a possibility to add to a chord in tab mode by hitting shift+alt+number. This should only affect the selected string. If there already is a note, it should change to the new number, but if there is no note on this string in this position, it should just add to the chord. If there already is a note with the same value on another string in this position, the normal score should not show any more note. It can add a stacked note if that is technically convienitent, but it must not be displayed.

Does this make sence? If not, I can try completing with some figures.

Reply

• Sep 15, 2012 - 14:47

Maybe we should wait for Miwarre to reply but I would guess that the deletion of notes entered on the pitched staff is not intentional and I agree that it needs to be looked at. I've just checked on Windows with build 0439920 and see the problem and for clarity I'm including a replication procedure below. I doubt anyone who uses linked pitch and tab staves would limit themselves to one form of input.

1. Create a score with a pair of linked staves, one pitched and one tab
2. Type "Alt-n" and "enter" to enter note entry mode
3. Type "5" to select a crotchet
4. Click anywhere in the first measure of the pitched staff to enter a single note
5. Type "Esc" twice to exit note entry mode
6. Select the same measure on the tab staff
7. Type "Alt-n" and "enter" to enter note entry mode on the tab staff
8. Use the left arrow key (twice) to move the entry point to align vertically with the previously entered note
8. If necessary use alt-down to move away from the string with the previously entered note
9. Type "Alt-1"

Actual result:
Second note entered appears as a 1 on the selected string, the note previously entered on another string disappears.

Expected result:
Second note entered appears as 1 on the selected string and the previously entered note remains.

The input on the tab should only override the note entered on the pitch staff if it conflicts ie if it's on the same string.

As for the second suggestion, I'm afraid I don't understand it. If your request would only affect the selected string surely this new tab keyboard entry method is already the quickest way to do it? Repeating a note from another string on the selected string would involve deciding which note to duplicate and, unless I'm missing something, that would be an additional step.

Reply

• Sep 15, 2012 - 16:31

Let me try clarifying my problem:

  1. create a linked pitch and tab staff for guitar
  2. go to the first first e string in the first measure of the tab
  3. press alt+0 to insert a 0 to the string and an e to the pitch staff
  4. press alt+down to navigate to the b string
  5. press alt+5 to insert another e tone of the same pitch

    6. Actual result: Nothing!

    Expected result: The e string should show 0, the b string should show 5 and the pitch staff should show only one e note.

    If the default behavior of alt+number is to move the current note to the new insert, then shift+alt+number should add to build a chord. This would be consequent to the pitch editing. However, I agree with brod that it would be more convienitent if the default behavior would be to add a note to the chord.

Reply

• Sep 15, 2012 - 18:58

Ah, now I understand. I hadn't tested that.

In fact behaviour is not consistent across strings. It seems the first string acts differently to the others.

The test you describe shows that you cannot add the same note as is on the first string on another string (in your case it was the second string but trying fret 9 on the third string gives the same result).

The same is not true of other strings. Add a note to the second string and attempt to repeat it on the third string and not only does the new note not appear but it deletes the first note. A second attempt adds the note on the string you are editing but does not bring it back to the string where you first entered it.

Reply

• Sep 15, 2012 - 19:04

Miwarre, I've noticed that you can't overwrite a fret using the "alt-number" method. Once you've entered a fret number on a string the only way to change it is with the up and down keys (or shift-up and shift-down if appropriate) or by deleting and re-entering.

Is this intentional?

I don't really have an option on whether it is a good thing or not. It slows down corrections but also helps prevent accidental overwrites.

Reply

• Sep 16, 2012 - 01:31

I was told that in a previous version of MuseScore, you could add several notes of the same kind by just pressing shift and insert as many you liked. They was just stacked. However, this was considered bad behavior, so it was changed to just toggle the note on and off. I understand that in normal case toggling is easier to explain.

Hmm. I hadn't beem aware of this change, and I am mot sure I like it. This has nothing to do with tab specifically, but applies to all note entry: if you have already entered an E, you cannot enter another via shift-E. But that's a pretty common thing to do, at least for me. To have an E and Eb in the same chord, for instance. Possibly in different octaves, but I would often enter this as E, -, E, crrl-up. Yes, I know there are other ways and I can adapt, but I am wondering what problem this change solves and if the cure isn't perhaps worse?

Reply

• Sep 16, 2012 - 09:50

I can confirm that code is there to implement this kind of toggle and preventing entering the same note twice in a chord (where by "same note" a note with the same pitch is meant; if anybody cares, the code are lines 755-762 of libmscore.edit.cpp, function void Score::putNote(const Position& p, bool replace)).

I also do not understand the reason for this change, which is however there since before the switch to github, i.e. end of May.

For instance, this change does not prevent entering an octave to a note already there, but makes it unnecessarily complex, as the usual way, for me and for Marc as well, is to repeat the note and move it by an octave.

There are commands to add to a chord an interval to a note already there, but one has to be sure the relevant note of the chord is selected and I am not sure there are commands to add the interval above AND below.

So, a word on the rationale of this change would possibly clarify the matter.

I'm going to disable this for TAB staves, as it does not make real sense for them; but I'm not going to change it for other kinds of staves until the reasons for it are clear.

Thanks,

M.

Reply

• Sep 16, 2012 - 15:26

I could live with shift-E automatically entering an E an octave up. I suppose some might prefer an octave down, but for some reason, I think I tend to enter chords bottom up. Plus I do tend to use the shortcut for entering a note an octave below (shift-8).

I wonder if the reason for the change was to prevent mistakes where a double note is accidentally left in. Or maybe that causes problems for MuseScore down the road. But it's still possible to create this situation by entering different pitches then uses up/down arrows to merge them.

Reply

• Sep 16, 2012 - 19:03

Forgive me if I sound too picky, but it is perhaps the case to move the discussion about this change (note toggling instead of note adding) and ways around it to a topic for itself, as it is not specific to TABs; even more, it will no longer apply to TABs very soon...

Thanks,

M.

Reply

• Sep 16, 2012 - 00:26

I'll address each issue separately.

[Alt]+keys not working on Mac: unfortunately, I know nothing about Mac's. By chance, are they reserved by the system?

As detailed above, I know [Alt]+[C], [Alt]+[D]... do not work (at least in English version of the software) as they are 'stolen' by the [C]reate, [D] isplay, ... menus. I know of no reason for [Alt]+[1], [Alt]+[2], ... not working on Mac: they do work on my Ubuntu and Win7 systems.

Any Mac expert has any idea?

I understand that using [Alt] combinations will ever be a problem. If anybody could come with better default shortcuts (also keeping in mind that one or two more rows of numbers should be reserved for frets 10-19 and 20-29), it would be great.

Thanks,

M.

Reply

• Sep 18, 2012 - 00:13

In order to test the last fixes, I tried entering a full TAB piece (for the record, Dowland's Pavana Lachrimae Antiquae) with the keyboard-only entry way. And I perhaps got an idea for a new set of short cuts for it.

1) The main constrain is that an existing shorts cut cannot be reused if linked to a command which makes sense while entering notes in a TAB staff.

For instance:

*) [Ctrl][S] is currently "Save". Reusing this short cut would make impossible to save via keyboard (of course, menu commands are always available) while entering notes in a TAB staff; this would NOT be a sensible choice.
*) [A] is currently "enter an A note": while entering notes in a TAB staff, note spelling makes little sense; this short cut could be easily re-used (in fact, it is currently disabled while in TAB note entry)
*) [T] is (I think...) "Open the Instrument dlg box": it might be useful to have as a short cut but, if necessary, can be re-used, forcing the use of the menu command while in TAB note entry mode (which presumably is not needed very often).

2) A second constrain is to avoid [Alt] if possible, as it creates a number of problems.

So, my idea is:

[Cltr][0] ... [Ctrl][9] for frets 0 to 9
[Ctrl][Shift][0] ... [Ctrl][Shift][9] for frets 10 to 19
[Shift][0] ... [Shift][9] for frets 20 to 29
(at least on Win and Linux, numbers could be entered either on top kdb row or in number pad, if it exists and NumLock is on)

[Ctrl][A] ... [Ctrl][R] as duplicates for frets 0 to 16 (useful when using TABs with letters rather than numbers).

[Ctrl][Up] / [Ctrl][Down] to move the current string up or down

[Ctrl][Left] / [Ctrl][Right] as duplicate of current [Left] and [Right] to move the cursor to the previous / next chord

The last 2 short cuts are useful because I noticed that, when mixing fret entering or string up/dn (which currently use [Alt]) with cursor left/right (which do NOT use [Alt]), it is easy to forget to release or re-press [Alt]. Having those additional [Ctrl][Left]/[Ctrl][Right] could allow to keep [Ctrl] always pressed and still achieving the intended commands.

This is also why I propose to use [Ctrl][Shift]+number before [Shift]+number alone: I think it is easier to add [Shift] than switching [Shift] for [Ctrl].

(Of course, short cuts can be customized, but I think important to give reasonable defaults, as a number of users will not discover how or be willing to customize them).

Any comment? Did I overlook something? How would this look on Mac?

Thanks,

M.

Reply

• Sep 18, 2012 - 12:33

Edited because I missed something important in the original post!

In many cases the Mac version of shortcuts which include "ctrl" on a PC use the "command" key on a Mac, not the "control" key. I don't know if it is a deliberate change to adapt to Mac usage or if the code used on a PC would automatically translate to "command" on a Mac.

If "ctrl" maps to "command" on Macs there are system commands which use some of the suggested combinations. eg command-shift-3 is print screen to file.

If "ctrl" maps to "control" on Macs there are other system commands which conflict. eg control-3 switches to desktop 3 in Spaces on Snow Leopard. Spaces functionality moved to Mission Control from Lion and I don't know whether that has the same shortcuts but there are still a lot of Snow Leopard users.

Whichever it is, the new proposed list can't be used on Macs as it stands.

Reply

• Sep 18, 2012 - 21:23

As you have a Mac AND use tablatures, which would be suitable shortcut set for you? Perhaps, as Win / Linux seem to have less restrictions, it might be easier to port to them a set working on Mac than vice versa.

Thanks for the consideration Miwarre. Although if I'm really the only one using this functionality on Mac getting it to work on Mac is a low priority ;-)

Here are some thoughts (some nothing to do with Macs).

Alternative shortcuts
Is there a particular reason you think the letter alternatives to numbers are needed? Numbers are intuitive as frets are numbered. Letters are not intuitive (they would probably lead most people to count through the alphabet) and whilst the staff type is different, it seems to 'contradict' the use of letters on a pitched staff to choose a specific note (which is intuitive). What's more, they are likely to conflict with other shortcuts like ctrl-N which opens the new file dialog regardless of context.

Moving across strings
Ctrl-Shift-Up and Ctrl-Shift-Down are used to move up and down in another context. It may be easier to remember if the same shortcuts were used to move to the string above or below.

Moving left and right
I also got confused switching between just left and right with the combinations for up and down so I think your idea to include the key combinations is a good one. In other contexts the combination ctrl-left and ctrl-right are used to move to other measures so the use of "ctrl" here is in a way inconsistent. I realise that keeping shortcuts consistent in different contexts may not be a priority and maybe not possible, but consistency makes it easier to remember and therefore easier to use. This is an argument for keeping to "Alt" as the modifier rather than changing to "Ctrl".

Use of "ctrl"
I have found that the default (Qt) functionality is for "ctrl" to map to "command" in Mac OS X builds ("Control" is used for the meta key). Command and Command-Shift are commonly used for system shortcuts on Mac so the chances of being overridden are high. My opinion is that it would be better to stick with the use of Alt rather than change to Ctrl even if this means that in the short term it means that some of the shortcuts are not available on Mac. Nobody has commented on my post about the shortcut problem on Macs but I've done some research and found that Linux and Windows seem to be more 'flexible' when it comes to interpreting keypress (I came across a number of issue where developers using Qt found their shortcuts work on Linux and Windows but some don't work on Macs, some seemed to blame a possible bug in a recent version of Qt, others where it seemed focus needed to be specifically set).

Reply

• Sep 18, 2012 - 23:23

Very useful analysis! Thanks for your thoughts. I agree with most of them.

Just one note about letters: modern TAB's uses numbers for frets, but French (and most English) tablatures for lute, viol and other instruments of the XVI and XVII centuries used letters, using 'a' as 0 (not as an A note!), 'b' as 1 and so on (the so-called French tabulature).

As this type of TAB's is possible in MuseScore, it is rather inconvenient to remember to press [0] to get an 'a' or [5] to get an 'f' and so on, particularly if you have to remember to not count 'j' (which was not used) or if you are copying a French tabulature from a source. Several TAB specific programmes also allow to use of letters to enter frets, Fronimo for instance does. I would like to keep this possibility.

(A very collateral side note: you say that using letters to enter note names in pitched staves is "intuitive": it is not for me, as I am not English and I use different names for the notes; of course, I know the English names, but I have re-configured the note entering shortcuts to match (more or less) the note positions in the scale...)

For the rest, as I said, I agree with you; so the current shortcut setup seems to be the best we can arrive at the moment. But having some number combinations not available on Mac and some letter combinations not available in all systems still is a problem.

Thanks,

M.

Reply

• Sep 19, 2012 - 11:12

Thank you for the background information. I've seen old lute tablatures but not being a player myself I've never used them so the fact that they used letters had not sunk in. Knowing that, the alternative shortcuts make perfect sense.

I'm also suitably humbled with regard to my embarrassingly anglocentric comment on letters being intuitive for note selection. I'm doubly guilty as I speak a couple of languages where other systems are used!

Reply

• Sep 16, 2012 - 00:10

According to brod: "So if it's set at the 3rd fret that becomes 0 and the 4th fret becomes 1 etc

According to mtherieau: "the notes and fret numbers are placed as if there were no capo".

To me, these seem contradictory explanations: is there are way to make then consistent?

Thanks,

M.

Reply

• Sep 16, 2012 - 08:31

Maybe there are different aspects of this, but I personally have never seen anything but the following:

(capo 3)
e |--0---|           e |--3---|
b |--1---| ------\   b |--4---|
g |--2---|        \  g |--5---| 
d |--2---|        /  d |--5---| 
a |--0---| ------/   a |--3---| 
E |--0---|           E |--3---|

Reply

• Sep 16, 2012 - 09:39

Where left is notation and right are the actual notes played?

This might be relatively easy to implement. However, I would put it somewhat down in the priority list, as there are still notation elements missing in the TAB setup.

But if you could remind me of it every now and then, I would be grateful...!

Thanks,

M.

Reply

• Sep 16, 2012 - 10:18

Without wanting to put words in mtherieau's mouth I believe this is what he meant as well. Whilst my comment and his may have looked contradictory, looking at the rest of his post suggests we are in line.

I appreciate this may be a lower priority but just in case I miss a later discussion on it, let me add one more thing now ;-)
This may resolve the tablature question but what about linked pitched staff. It could reflect the actual notes or the notes as they appear to be from the fret numbers. Both are valid and it would be good to allow the user to set it according to their own needs. The decision, at least for scores for solo, will often be down to which is easier to read. For ensemble, my expectation would be to see the pitched staff to show actual notes played.

Reply

• Sep 16, 2012 - 13:03

sorry for the confusion -- I think my comment was unclear. I meant to say the same thing as the "set at the 3rd fret becomes 0.." comment, but also add the point of how a capo makes a transposing instrument. The scores I have seen with capo treat the capo position as the open string position. For standard notation, a guitar with a capo on the 3rd fret would become a transposing instrument, so if you notated its open strings, they would still be e,b,g,d,a,e, even though the "concert pitch" is g,d,a#,f#,c,g. Likewise for TAB notation, to play open strings with the capo on the 3rd position, the TAB would mark them as "0" frets.

Reply

• Sep 16, 2012 - 00:25

The intended behaviour when inputting note in a TAB staff is to have each string 'independent':

You press a fret key when a string is selected => a note is entered on this string; it should not matter whether there are already notes on that chord or not (regardless they are the same pitch of the new note or not) and, for sure, it should not delete any existing note on other strings! No need for extra short cuts: string + fret => note!

So, I'll check this part.

(I think johey's issue with the balalajka specificities should go once this part will work as intended).
_____________________________

Overwriting fret numbers; brod remark is correct: when a string already has a note on it, entering a new fret does nothing. This is by design (I am cautious about overwriting what is already there), but of course it can be changed if you think it more reasonable.

Thanks,

M.

Reply

• Sep 16, 2012 - 08:23

Yes, if strings were really independent in that way you describe, and if insertion of two same notes of different strings would give only one visible note in the linked pitch staff, this would save my day.

But! If I was to decide, this should be doable from both the tab staff and the pitch staff. Therefore, beside the above mentioned fix, I think you'd better to reimplement the stacking behaviour of note insertion in pitch scores. Either by just reverting the change, or by adding another hotkey to do it.

Reply

• Sep 16, 2012 - 10:10

As per my post above, the current note 'toggling' behaviour seems to be done on purpose, but which the purpose might be, it is not clear (layout issues with multiple occurrences of the same note head in the same position?).

I'm disabling this for TAB staves only (allowing entering no matter which fret in no matter which string, of course within the limits of the instrument), but I'm not going to change it for other types of staves until the reasons for such a 'feature' are made clearer.

So, for the moment being, multiple occurrences of the same note will only be possible by note entry on the TAB staff.

I'm also removing the 'protection' on existing frets mark.

Thanks,

M.

P.S.: introducing more hotkeys for adding notes to chords would make little sense to me; there are such hotkeys already ([Shift]+[A/B/...]) and they have been circumvented to prevent adding the same note twice; before trying to circumvent the circumvention, let's understand the purpose of all this.

Reply

• Sep 16, 2012 - 19:14

I have just merged into Github repo a patch which, during TAB note entry

*) permits multiple notes of same pitch in TABs
*) allows overwriting existing fret marks

Github commit b9984ffeaf; it should be in nightly tomorrow.

Thanks for the comments and suggestions,

M.

Reply

• Sep 17, 2012 - 20:22

It works well thanks.

I've been having a look at the alt-number and alt-letter commands for entering frets ... or to be more accurate I've been looking at all keyboard shortcuts which include the alt key on a Mac and found that it's not just your new shortcuts that don't work.

It seems that all the shortcuts which select something, change the selection or move the insertion point seem to work. With the exception of "alt-command-t" to insert a tempo marking, none of the shortcuts involving alt which should insert objects (whether notes or markings) work. So it looks as if the problem may not be in your new code.

I'll start a new thread with this information.

Reply

• Sep 19, 2012 - 09:38

Some days ago, you could select one tone number in a tab, move it to another string by pressing ctrl+up/down arrow. If the target string had another note, it was swapped with your moving note. That was great, but now the note is still there, stacking with the new note. With a fret instrument, it is hard to play two different notes on one string simultaneously. :)

Report: http://musescore.org/en/node/18214

Reply

• Oct 15, 2012 - 21:44

How do I add fingering to a guitar Tablature?

Wouldn't the way TuxGuitar does Tablature be better? It has a normal right hand piano staff on top and a tab staff below that only shows the 0s and so forth for where the left hand fingers should be on the strings. Fingering could be added very easily to that as well, because on a good guitar score you need fingering for both hand when you play guitar.

Thanks.

Reply

• Oct 15, 2012 - 22:14

If you want a pitched/TAB two-stave setup, you may add a second stave linked to the first (in the "Create | Instruments" dlg box) and change either to TAB. Linked staves are not 100% reliable yet, but more tests are always useful.

Alternatively, you may try adding fingering to the TAB itself. I have not tested that, as I expect them to be difficult to distinguish from the fret marks; but you are very welcome to test and tell the outcome. Fingering are found in one of the palettes.

Thanks,

M.

Reply

• Oct 16, 2012 - 07:37

When you add a linked staff it always results in another staff of the type you first chose. You need to manually change this in "Staff Properties".

Right click somewhere on the staff you want to change and choose "Staff Properties ..." from the menu. In the dialog which opens, entitled "Edit Stave/Part Properties" the first section contains a property called "Type". As you started with tablature the dropdown will show "Tab". Click on this and select "Pitched 5 Lines" then "OK" and the staff will change. If you start off with a pair of pitched staves you can change one of them to tab in the same way.

Reply

• Oct 16, 2012 - 20:11

There's no fretboard diagram input in MuseScore and no plans for one as far as I know. In fact, whilst I'm sure it would be very useful for guitarists, I don't think I've even seen a feature request for it. I think it would probably be a bit more challenging to implement than the piano keyboard because of all the possible tunings for a guitar.

Reply

• Nov 25, 2012 - 18:16

I just noticed this.. where have I been? oh, using standard notation in 1.2 :). Miwarre, you probably remember my blog post from 6 months ago with some suggestions for the tab UI... glad to see it becoming reality!

Anyway, I tried inputting a song I'm working on... here's my feedback:
1) Big improvement over 6 months ago. Usable now :-)
2) I think "Show Rests" should be on by default.
3) I would like a *completely different* set of keyboard shortcuts in TAB mode (plain 1,2,3... to enter notes, CTRL+4,5,6 for note duration, up/down to change strings, etc)
4) Multiple voices would be nice... maybe one 'implicit' voice per string? (I know, it's a design/coding nightmare)

I can see a need for two voices... probably not 3 or 4 though. In handwritten tabs, I add stems below the bassline if it's complex, e.g. Bach lute pieces. But that's usually overkill. In most of the renaissance tabs I've seen, there are stems above the melody, but no stems on the bass notes, to reduce visual clutter. You can *almost* do that with MuseScore now (it won't sound quite right but it'll look right) except for some edge cases.

By "implicit voices" I mean MuseScore would display an upstem for the duration of the topmost note in a chord, and a downstem for the bottom-most note (if enabled), and display nothing for any notes in between -- it's up to the player's interpretation. It's a bit more complicated because the bassline and melody are often interleaved (otherwise there'd be no need for this feature). Anyway, it's just an idea.. I haven't thought it through fully. I think it'd be a better UI than the standard 1-2-3-4 voices thing. But coding it could be hairy.

Reply

• Nov 25, 2012 - 19:34

I probably should remember the blog post you quote above, but in fact I am not sure I saw it in due time...

Anyway, coming to your points:

1) :) Thank you ! !

2) Well, I think this is mostly a matter of what one does most frequently; many of the peoples asking for the TAB feature had the simpler tab's in mind and would probably be put off by such a default.

It would be possible to split the current "Modern" preset in two: one for more complete types of TAB's and one for the 'quick and dirty' type (no rests). Rest display would be one difference but there could be other too.

If you can come with two suggestive names for each of them -- and perhaps a list of differences --, I can do the split rather easily.

3) Oh well!! I would like different shortcuts too! But 1, 2, 3, ... for note duration is common to the WHOLE program and cannot be changed easily for TAB's alone.
Same for [Up]/[Down]: they are used to move the note up/down one semitone; again a program-wide setting.

Of course, you can change them (they are all configurable in preferences), but this would apply to other staff types too. This may probably be useful if you only use MuseScore for TAB's (or almost only), but I do not think it would be a wise setup to propose as default.

In theory, with some code changes, it would be possible to have the same action covered by different shortcuts in different contexts, but I think it would become more complex to remember the relevant shortcuts than it is using [Ctrl] or [Alt] some more.

But of course this is just my opinion; discussion and suggestions are welcome. Anybody else has an opinion?

4) I know. The major issue stopping me so far from implementing full voice support in TAB's is not the display part (which would be not trivial anyway) but how to check -- and cope -- for string conflicts among different voices; given the current internal structure, which separates completely chords belonging to different voices, this is rather complex (and then slow(er)!). And this is not going to change, as the current architecture suits well the other types of staff: string conflict is an issue for TAB's only!

Also, historic tablatures always had a single row of duration symbols, sustained notes were totally left to the player. If several voices would be implemented, it would require to construct the duration symbols not from chord actual durations, but from time delta between chords across the several voices: again complex, error prone and slow.

If there is a real need, all these considerations may become secondary, but at the moment evidence is lacking: if you need a really complex voice structure, possibly TAB's are not the way to go; after all, when the lute / guitar literature become more architecturally complex and/or precision of notation become more important, TAB's were abandoned in favour of 'regular' music notation. Voices are not really needed for historic literature (at least in notation) nor for the 'simple' notation TAB's are often used for today. Nice to have, of course, but within the currently available resources I'm afraid this area remains at low priority.

Thanks for spending time on testing and for the comments!

M.
_______________________________

P.S.: Finally, a rather off topic remark on your blog post: in Figured bass implementation, you lament the lack of support for symbols like "4/"; historically, the "/" suffix, meaning 'diminished', was only used with "5". It is not "the same thing" as "4+", "4\" would be, which is in fact accepted (and converted to "4+", as "4\" was not used in itself). Of course, one may invent new usages for B.C., but it refers to a historical practice, defined in epoch and usages... But thank you anyway for the comments! m.

Reply

• Nov 25, 2012 - 23:28

Yep, you definitely read that blog post before - I remember you saying the same thing about figured bass :)

2) Good idea... how about "Full Tab" and "Basic Tab", or just "Tab"? More ideas -- Fancy, Advanced, "with stems", "with rhythm". In LilyPond it's "tabFullNotation". Wikipedia tells me nothing. Other programs don't seem to have a word for it... I skimmed some docs for Finale, Sibelius, Fronimo, Django, Guitar Pro. So, "Full" sounds good.

My "full tab" options -- Lines: broken, Stem: above, Stem style: beside staff, Half notes: short stem, Show Rests: yes.

3) Well, I managed to assign shortcuts (see attached) more to my liking... 1-9 for frets, up/down switch string (so arrow keys move in all 4 directions, logically), remapped raise/lower to '[' and ']', remapped note durations to a cluster of unused keys (KL;'M,). I was also thinking, I could map F1-F12 to frets 0-11, and hold down SHIFT for frets 12-23. Or use the key left of '1' (tilde/backtick on US keyboards) for fret 0, to avoid an off-by-one discrepancy with the F-key labels... shrug :)

Would it be easy to include an alternate set of predefined tab-friendly shortcuts, switchable in the prefs UI?
For now, people could manually overwrite ~/.local/share/data/MuseScore/MuseScoreDevelopment/shortcuts.xml

4) Well, at least the voices 1-4 still work in tab - I thought they didn't. Just needs some debugging and maybe UI tweaking. Better to have "good enough" today than "perfect" in an eternity!

Attachment Size
shortcuts.xml 16.66 KB

Reply

• Jan 2, 2013 - 20:24

There seems to be two main forms of tablature. The US version which uses beizer lines and similar to notate string bending. And another version which relies on text.(for instance a bend up by a whole tone is notated with the letters BU above the fret number on the tabstaff.)
My personal peference is the 2nd way.And I have managed to use lilypond to achieve this to some extent. where it falls down is the vertical aliment of the text with tabstaff, if we can use musescore's fingering markings for this , it would be great.
Also being able to enclose a number in parentheses is quite important. can we do this with the standard notation in musescore ? finallly a quartertone bend symbol would be great to add to the symbols in musescore. it looks like an up arrow with a 1/4 above it.
http://www.musicradar.com/guitartechniques/guitar-techniques-user-guide…
i suggest adhering to this guide as closely as possible, for guitar tab that blends smoothly with musescore.

Thank you so much,
damien

Reply

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