Request for new "swap strings" feature in tab
MS 2.0.2 / Nightly d45cc19 / Win 7 / Win 10.
The original score is attached. In certain combinations, TAB notes cannot be moved to adjacent strings. Two examples are shown below:
In this example, in the TAB staff it is not possible to change A --> B or C --> D. You have to delete and re-enter notes.
| Attachment | Size |
|---|---|
| Tab_note_adjustment_error.mscz | 8.4 KB |
Comments
It's hard to follow you. What is exactly your purpose here? It is an open tuning DADGAD. Nobody wants you to get the result displayed in your first measure in TAB staff. Because it is unplayable (well, playable, but incoherent) in this state. On the contrary, this type of tuning will encourage the search of open strings.
So, if you copy and paste the first measure (standard staff) into the second measure (Tab), the result is as expected. Ditto, if you enter numbers directly in Tab in the third measure, and then by making a copy-paste in the standard staff.
For the demonstration, and if you really want that A is like B and C and as D: select a number and modify it with the arrow keys, eg (for the B): the first 0 second string to 5 (Up/ X5), and the 7 third string to 2 (Down/ x... ditto)
View the result for measure 4 in this file: A Tab_note_adjustment_error.mscz
(I have not change the notes in the standard staff)
Have I understood it or not at all?
I'll try to explain better. The file was created for demonstration purposes only, but it is based on fingering issues that have cropped up in other files. The TAB notes were created by pasting the music from the pitched staff.
Having done this it was necessary to correct the tablature notes using ctrl + up/down arrows. But there is a limit to the correction ability of the program and I can't change A (the default entry) to B (the desired result) or C (the default entry) to D (the desired result) using the ctrl + arrows. You can only acheive B and D by deleting the tab marks in A and B and re-entering the correct ones.
I don't understand how this is a bug. There is indeed no way I can see to get from A to B just using that one command, but at no time does the comman not do exactly what what it is supposed to do. Do you have a precise series of steps to follow where you the result of some particular step should be other than it is?
BTW, there is no need to delete notes in order to change them - simply enter the new ones directly on top of the old. Eg, in note entry mode, position the cursor on the 5, press 0, now it's a 0 - no need to delete anything.
Click on [fret 2, string 3] in chord A and use ctrl + up arrow.
Expected result: Exchange of notes between strings 3 and 2. i.e:
– [fret 2, string 3] --> [fret 0, string 2], and
– [fret 5, string 2] --> [fret 7, string 3].
Actual result: Notes are not exchanging as expected but both move onto the open positions on strings 1 and 2.
------------------------------------
Here's another example in standard tuning:
1. Try to change the first tab chord using ctrl + up/down arrows so that the B is on the fourth string (9th fret) and the G is on the 3rd string (open).
2. Now try a similar thing with the tab notes in the second bar so that the F is on the fifth string (8th fret) and the D is on the 4th string (open)
In "1," the note exchange is not possible but in "2" it is!
As far as I know, the algorithm was never intended to swap notes, so failure to do something it was not designed to do is not a bug. I could see value in a new feature that *is* designed to do that, though.
Marc S. comments "As far as I know, the algorithm was never intended to swap notes"
According to the handbook, the command Ctrl + ↑ or Ctrl + ↓ (in normal mode) moves the note to the above/below string while keeping the pitch.
However, in practice the command does allow note exchange to take place in many cases where possible, and this is an essential feature. So this is not so much a request for a new feature but for an improvement of the existing command (AFAIK).
In many cases clicking on a note and using Ctrl + ↑ or Ctrl + ↓ gives the expected result. But there are some irregularities where pairs of notes are concerned:
1. It only allows note exchange to take place (if possible) if you click on the lowest note of the pair and use Ctrl + ↑. If you click on the highest note and use Ctrl + ↓, either nothing happens or the note moves backwards (!) onto a free adjacent string (if possible).
2. For some note pairs, which should exchange using the procedure in "1" (i.e click on lowest note and use Ctrl + ↑), both notes move unexpectedly to the open position on adjacent strings.
There are more details in the attached file which may be useful.
I hope you don't mind if I slightly amend the title as this is a request to improve the current command rather than a new feature.
Please, the handbook actually actually says:
"Ctrl+↑ / ↓ moves the selected note to upper/lower string (if the string is free and can produce that note)." (bold is mine, but important).
I can assure that swapping notes has never been a purpose of this feature. And in fact, it never swaps notes; it always and only moves an existing note to another string, if possible.
So, this is really a new feature request. A legitimate feature request? Of course, any feature request is legitimate!
Please note however that such a feature would work only in the cases where either string can produce either note, which is not always the case (I would say it is only the case in the minority of occasions, but I am not so familiar with guitar fingerings to hold any position). So sometime it would work and sometime it wouldn't, possibly creating as much problems as it solves.
Note also that at least in the case C -> D, you are not asking for a string swap, but for a re-assignment of strings; in fact, the A on the 2rd string should keep its position and the G on the first string should 'jump' over it to reach the third string; so the same feature could not cover both A -> B and C -> D cases.
Finally, it is possible to convert A into B and C into D (with other commands). For instance A -> B:
1) Select '2' and increase it to '7' with ↑.
2) Select the '5' and decrease it to '0' with ↓.
And it also always possible to enter the notes directly in the TAB when a specific fretting is required.
In summary, the feature seems under-defined and, given the presence of other ways to reach the same result, its priority does not seem very high.
__________________
P.S.: There is a bug in the short-cuts and the [Shift]+[Up/Dn] keystrokes do not work as described in the manual. This is fixed in nightly, though.
Miwaree comments: "Please, the handbook actually actually says:
"Ctrl+↑ / ↓ moves the selected note to upper/lower string (if the string is free and can produce that note)." (bold is mine, but important)."
Agreed. But it appears to the user that there is an undocumented feature of the command, whether intended or not, that if you click on the lowest note of a note pair and press Ctrl+↑, some note-pairs exchange strings. You can try this for yourself with the above file "note_pair_exchange.mscz."
My feature request is simply to allow this exchange to work with Ctrl+↓, as well, when you click on the top note of a pair.
@ geetar: you call it an "undocumented feature", someone else could call it a "bug", for instance someone preferring that Ctrl+↑ on the lower note would 'push' both notes up each to its next string (a difference from your requirement which in fact "needs info" about), but this is marginal; even if it be considered a 'bug', I would not bother to 'correct' it. So, I repeat my arguments:
1) Assuming this "undocumented bug" <g> could be extended to the opposite case, it would work only in certain cases (when either string can produce either note) and not in others and the situation would not be any clearer to the user.
2) Even this extension would not cover the C -> D case described above and for which precise specs are not given (or can be deducted from the description; in fact, the "needs info" tag was primarily for this aspect).
3) There are other documented, implemented and working ways to obtain the same results more or less easily.
4) Lastly and somehow marginally, this extension would require a major reworking of the fret-assigning algorithm, which I am very reluctant to do, as the current situation is the result of rather long discussions and occasionally compromises between conflicting requirements which would be hard to reconstruct correctly; and this in order to obtain a result which is already rather easy to obtain in other ways. For instance, as to reach your intended result you would need to leave the standard staff and work on the TAB anyway (to swap the strings), it might be simpler to enter the notes in the TAB directly.
So, unless more pressing evidence or bigger shortcomings in the current implementation come out, I feel no urging need to implement this myself.
Thanks, M.
P.S.: I believe it better this "undocumented feature" to remain undocumented, and the sentence you recently added in the handbook about it should be probably removed. But in any case THANKS for your continuous effort in improving the documentation!
I agree there is no way we should be reconsidering the current string assignment algorithm at this point Way too much much water under the bridge; the current system is the result of some very careful and delicate compromises between competing needs and has served people well since it was implemented. A "swap strings" feature might be very occasionally nice - it would save one or two keystrokes in this case - but it definitely would need to be a *new* feature, nbot a change to the existing feature which already nworks extremely well.
Meanwhile, though, simply re-entering the frets directly on top of the old takes ontly one or two more keystrokes than any new "sap strings" command would.
Fair enough.