MS2 Beta1 -- tab staff ignores "Play transposition" property
Downloaded MS2Beta1 to try out the tab staff feature and noticed that the tab staff no longer pays attention to the "Play transposition" property, which in prior versions was very useful as a quick means to indicate capo position (i.e. Play transposition == '2 - Major Second' is like having a capo on the 2nd fret). In prior MS2 versions, the tab staff has considered the transposed notes as "open", but beta1 seems to ignore this property and shows the frets numbered from the nut, not relative to the transposed notes. I see that "Edit String Data" allows each string to have a custom "open" note, but changing each string one at a time seems to be a cumbersome way to handle what was much easier in prior revisions.
q: is this behavior intentional?
regards,
markt
Comments
it seems "capo" support has been discussed at length:
http://musescore.org/en/node/20512 and
http://dev-list.musescore.org/Capo-support-in-tablature-td7577937.html
Am not sure that the capo support discussed on the dev list is available in beta1?
Also, I don't see any mention of how capo support would relate to the "play transposition" property. To my mind, the two should cooperate, but maybe there are differing opinions?
regards,
markt
Downloaded MS2Beta2 to see if I could create a tab score that would playback as if a guitar were capo'd to 2nd fret. I wanted to see if this could be done without first class support for a capo element.
I changed "Play Transposition" in staff properties to transpose up a major second and also edited the string data such that each string's open pitch as if it were capo-II. Unfortunately, these settings seem to have confused the tab staff fingerings. Some fingerings show up as "?" and others are way too high on the neck. After playing around with this a bit, I can't find a way to make the score "look correct" and also play at correct transposition when a capo is present.
I am not aware of any recent change to TAB's which could make the areas you refer to any better or any worse, so it might very useful to know something more.
1) Which version (or at least how old) was the one(s) you refer to as working?
2) Which version are you using now.
3) A sequence of steps, precise enough to replicate it, which were previously working and are not now.
4) The sequence of steps (again precise enough to replicate) which led to the score you attached in the above post.
5) The usual info: version of operating system, where you got your current MS version from.
Notes:
A) As always, it is not possible to correct a bug (or improve a behaviour) if the developer cannot replicate the bug itself on his computer, in order to locate it and understand what is wrong. Please note that, when dealing with bugs, the order in which steps are performed may be relevant, even if they appear to be unrelated from 'outside'.
B) After long and eventually inconclusive discussions about capo support, there is no currently any direct support for capo in MS. The 'supported workaround' is to edit the string data raising the pitch of each string by the same amount the capo would have.
C) The "open" column you see in the string data editor has nothing to do with this topic: it is used to mark strings as 'not fretted', like the bass strings of the lute or similar instruments.
Thanks,
M.
In reply to I am not aware of any recent by Miwarre
I think this is due to an orientation mistake in editing of strings data. And the "Play transposition", in this case, of course, follows the same initial error and loses the compass!
See this example with the original file: first test.mscz
Then, with the mistake: second test.mscz
If I change, e.g. the pitch of the first two strings: (E4 -> G4), and (B3 -> D2, instead of D4), I get this:
![first result.jpg]( "first result.jpg")
The lesson of this: we must be vigilant to take the right direction! It is true that at this "crossroad" of B3 eg, it can be tempting to go to your right ... rather than go back and to your left (when you want to climb of a third, even minor!)
So, priority to left :)
More seriously, can we imagine a way to avoid this error (or to reduce risk?) one way or another?
![string data.jpg]( "string data.jpg")
Finally, note that the code has always worked by this way (same result to nine months back)
In reply to I think this is due to an by cadiz1
Hi cadiz1, thanks for the comment.
If I understand correctly, the origin of the issue is a mistake in setting string pitches. I have not worked the math out, but I can confirm that, if the pitch of a string is off mark by two octaves, the fretting algorithm can loose its compass.
And, if I also understand correctly, there is no actual issue at all: once given meaningful data, the program will spits meaningful fret marks out (and, yes, there is still the issue of no explicit capo support, but this is well known since long).
Correct?
________________
About helping to reduce this kind of errors:
I thought, perhaps naively, that by placing the lower octaves below and the higher octaves above, a user would have 'naturally' gone UP to increase the pitch and DOWN to decrease the pitch; perhaps it is not so.
Any suggestion about how to improve the situation? It is perhaps possible to actually play the selected pitch in the pitch table or the selected string in the string list, giving an aural feedback. I am not sure this is possible (we are inside system dialogues); but would it help?
Thanks,
M.
In reply to Hi cadiz1, thanks for the by Miwarre
"It is perhaps possible to actually play the selected pitch in the pitch table or the selected string in the string list, giving an aural feedback"
Absolutely. I know that some softwares do it. It would be a nice improvement for post 2.0.
My thought was also in how to display the String data.
Currently, it is displayed (from left to right and top to bottom) from the Octave 8, to Octave -1.
![string data.jpg]( "string data.jpg")
I ask the question (because not having a definitive answer!): is it a very intuitive way to do it?
(it was maybe the origine of the mistake mentioned above - B3-> right-bottom -> D2 instead D4?)
- Keyboard instrument players, and string instruments players (I will not go into details and differences between each specific instrument) have the bass notes to their left, and advanced towards the treble notes to their right (my way of presenting this thought is awkward, may be?) :(
To go in the same direction, look at this article (in French, I did not find the equivalent in English) on Wiki: http://fr.wikipedia.org/wiki/Tessiture
The tessitura of different instruments is displayed starting with the lower octaves and going up to the higher octaves (and not the reverse)
Just a thought ...
In reply to "It is perhaps possible to by cadiz1
Let me summarize your argument, to see if I have correctly understood it:
1) Within each line of that dlg box, notes raise form left to right; let's assume this is 'intuitive' for the great majority of human peoples (peoples accustomed to Arabic or Hebrew writing may think differently, but their computers will presumably present these dialogue boxes reversed; anybody can confirm this or not?).
2) As text lines normally go from top to bottom and each line from left to right (again, let's take aside Semitic writings for a moment), once one arrives at the right end of a line (by increasing pitches), the 'natural' tendency is to go on by going to the line below, rather than to the line above.
3) Then, the line below should contains the next higher octave, rather than the next lower octave.
Correct?
Once put in this way, it makes sense, but still, it would be appear counter-intuitive to me to place the lower octaves at the top of the dlg box and the higher octaves at its bottom.
And, to be honest, I find the image in the Wikipedia article you quote, well, 'strange'! Listing voices in the order "basse, baryton, ténor, contralto, mezzo, soprano" top to bottom does not look 'right' to me.
As we are 1 to 1, anybody else has an opinion?
(Then, we still have to sort out how this dlg box actually appears vs. should appear on computers with Arabic / Hebrew system locale).
Thanks,
M.
In reply to I think this is due to an by cadiz1
thanks for these replies (sorry I'm late in catching on these reponses). it sounds like I made some mistakes in editing the string data. Am happy to correct any mistakes and re-test. I'll do so and report back.
(I also have some separate comments/suggestions on how string data editing could be presented and how it could be improved if it paid attention to the "play transposition" staff property, but I will follow up separately on that)
regards,
markt
In reply to thanks for these replies by mtherieau
@mtherieau: any suggestion about improving the user interface is welcome. As well as any comment, suggestion, etc. about any other part of the programme.
I only would suggest to keep the ball rolling: the pressure to close the current code into a Release Candidate is raising...
Thanks,
M.
In reply to @mtherieau: any suggestion by Miwarre
@Miwarre -- thanks for being open to feedback.
first: I went back and confirmed that I had completely messed up my string data by accidentally choosing wrong octaves and also confirmed that when I selected the correct octaves, then the tab fingerings worked as expected. sorry for the confusion--I had quickly scanned the layout of the notes in the edit-string-data grid and obviously I did not read it carefully enough, resulting in these mistakes.
Not sure if you had considered alternative to the grid layout? Am wondering if a drop-down list that presents the notes vertically would be more intuitive and possibly less error-prone? This is the approach used in the "Play Transposition" setting in Staff Properties. (For the common cases of editing guitar string data, the desired note is within 5 semi-tones up or down so would be visible without arrowing up/down in drop-down list)
But this leads to another suggestion: What if the string data pitches could be enhanced so that they pay attention to the "Play Transposition" property? So if I were to set "Play Transposition" to "Major Second", then the pitch of each string would automatically be adjusted by that same value? If that could be supported, then in many cases, there would be no need at all to edit the string data (i.e. for standard tunings).
If this enhancement were added, then I personally wouldn't care if any further capo work got added to MS2. Adding "Capo II" staff text as a display-only element is perfectly fine for my purposes.
best regards,
markt
In reply to @Miwarre -- thanks for being by mtherieau
"first: I went back and confirmed that I had completely [...], then the tab fingerings worked as expected": glad to see this has been sorted out!
"Am wondering if a drop-down list that presents the notes vertically would be more intuitive and possibly less error-prone": possibly yes, but please take into account that, in general, there will be 120 notes to choose from, which would be a very long list. For editing, the dlg box could assume the new value is nearby the current value and centre it in the drop list, but for adding a new string? It could be at any point of the list.
About transposition, I'll check if it can be added with relative ease. I suspect other users would prefer an improve Capo support, though. Anybody else has an opinion?
Thanks,
M.
In reply to "first: I went back and by Miwarre
A drop-down list of 120 notes ...? No, not for me! :(
I'm already really annoyed in the Mixer for finding the right sound for the right instrument in the interminable list. So, please, not again for the String data!
I think it's really better to have an overview of the pitch of strings as currently.
I always come back to the starting point, at the beginning of this thread, what was the cause of the wrong choice of pitch.
The most dangerous place is the last column (that of B), as a intersection. You lose your bearings at this instant, because there is nothing to the right and you need to go back and to left to find the right path and good string.
So, the idea would be to add a grayed column, inactive (that of C, as a "courtesy column") to the right of column B ( click on the attachment for all displaying )
And so, e.g., when you are in B3, you have an useful benchmark (i.e. C2-> Octave 2-Down, or C4-> Octave4-Up) to take the good direction.
To give relief and visibility to the whole (currently, all is written with the same font), one could put the first column of C in bold (I could not do otherwise on the attachment to add a black frame ... but it was to illustrate the idea. I presume that the result would be better visually with only the notes, C8, C7, C6 etc. in bold ?)
- For Capo support, of course, any idea of improvement is welcome. I read recently this type of request on a french guitar forum.
In reply to A drop-down list of 120 notes by cadiz1
@Miwarre -- thanks for offering to look into linking the "Play Transposition" with string pitches. That was the original issue that triggered this thread, beginning last summer. Also, I should clarify that while I would welcome more robust capo support, but would argue that linking string pitches to "Play Transposition" would be a very useful step forward, hopefully with only minimal impact to code.
best regards,
markt
In reply to A drop-down list of 120 notes by cadiz1
@ cadiz1: I tried to implement your suggestions and this is the result:
NOT FOUND: 1
I am not sure it really helps, but I am probably not the best judge; do you think it makes sense?
M.
P.S.: You may want to see the image alone, as the browser may truncate its right part, to fit the web site layout.
P.P.S.: I have also added a bass clef to F3, just to complete the clef reference points.
In reply to @ cadiz1: I tried to by Miwarre
My opinion, Miwarre? Really, really good (in any case, much better, in reason of an improved "visibility")
This "courtesy octaves column" to the right is really useful.
I like also the double arrow (top right under the C: may be better in bold character also? but it's a detail) Good point also for the bass clef (edit: treble clef and bass clef in bold, for better visibility, or rather, or/and slight higher size?)
I would have preferred, for reasons explained above, that the octaves should be distributed from low to high (top left /start, to bottom right /end).
But your argument outlined in a previous message ("let's assume this is 'intuitive' for the great majority of human peoples - peoples accustomed to Arabic or Hebrew writing may think differently, but their computers will presumably present these dialogue boxes reversed; anybody can confirm this or not?)" is admissible.
So, this seems to be a good compromise right now. Thanks.
In reply to @ cadiz1: I tried to by Miwarre
as I've mentioned before, my primary interest here is the linkage between play transposition and the string data pitches.
but on this subject of how to present a set of string pitches and also allowing them to be edited, I have another thought/suggestion. I'm not trying to be cute/sarcastic, but it occurs to me that there is a well-established interface for this type of problem and it's called "standard notation". I'm not saying that this is easy to implement, but I think this example screenshot is a precise capture of standard guitar tuning. It also has the benefit of showing all the string pitches at once. Am not sure how difficult it would be to allow standard MS editing of these notes (arrow-up/down, keyboard letters, assigning clefs, etc) but I would say that this type of arrangement would be highly intuitive. just my thoughts...
regards,
markt
NOT FOUND: 1
In reply to as I've mentioned before, my by mtherieau
@mtherieau : it would be surely intuitive for changing the tuning of the existing strings of an enough defined instrument, but string data are not limited to guitars; all stringed instruments known to MuseScore (violin & relatives, viols, lute & relatives, banjos, mandolins, ukulele, balalaika, bouzouki, ...) have string data and with many of them tablatures (which are the main reason to have string data) are actually used.
They use a variety of clefs and string number varies, I believe, from 3 to at least 14. Some instruments distinguish between fretted and non-fretted (open) strings.
Making a general enough dlg box for editing these data according to you suggestion is not easy; in addition, accessing and using MuseScore note entry / editing power while inside a dlg box raises a number of problems.
Also, some of those instruments have a variable number of strings and the user should be able to add or remove strings; especially adding new strings raises some questions.
So, I suspect that the proposal could make sense in the long term, but would be rather complex to implement, unless someone has a stroke of genius. Then, my opinion is to postpone it.
The idea should not be forgotten, though!
Thanks,
M.
P.S.: the transposition issue is the next item on my to do list; please remember that most of us do all the work on our free time, so I cannot promise any deadline.
In reply to @mtherieau : it would be by Miwarre
@Miwarre: thanks for the response and agreed that my suggestion wouldn't be very easy to implement. Also I totally understand and appreciate that your contributions are at the expense of your free time. fwiw, I'm very much impressed with MS tab support and am looking forward to MS2 specifically for tab features.
best regards,
markt
@mtherieau:
I played a bit with making tablatures to follow transposition and I realize that I have not understood what you do expect to happen when transposition alone (no string re-tuning) is applied.
Quoting your first example, where an F5, C5, C4, F4 appear, when a Major second up transposition is applied:
1) what would you expect to obtain, for the notes you enter?
2) And in fact, which notes do you enter and how?
In reply to @mtherieau: I played a bit by Miwarre
If the staff has "Play Transposition" set to +Major Second, then the notes that appear as F5, C5, F4, C4 on the staff will have actual pitches of G5, D5, G4, D4. This is a common way to notate relative to a capo position (e.g. Capo II). The goal would be to adjust the string data pitches by this same transposition amount so that a linked TAB staff would show fingerings relative to a capo position as well.
Am attaching two test scores, both have "Play Transposition" set to +Major Second, and one uses the default String Data settings, while the other manually adjusts each string's pitch by a Major Second. The goal would be for the TAB staff to appear as it does in the "string_data_edited" score, where the fingerings are shown relative to the capo position, but without having to edit each string's pitch manually.
I hope these examples clarify the request.
![play_transposition_major_2nd_default_string_data.png]()
![play_transposition_major_2nd_string_data_edited.png]()
In reply to If the staff has "Play by mtherieau
Thanks, this certainly helps.
Another detail I forgot to ask before: the pictures above were taken while the programme was set with "Concert Pitch" off, aren't they?
Assuming this was the case, I have practically solved the issue: expect a patch soon...
In reply to Thanks, this certainly by Miwarre
confirmed -- "Concert Pitch" was off for the snapshots I attached.
thanks for the update -- sounds like good progress!
best regards,
markt
The change has been larger than I expected and I doubt transposition could ever have worked with TABs.
Anyway, PR pushed to github : https://github.com/musescore/MuseScore/pull/1754 .
Waiting for Travis to compile and for the code devs to decide...
Things ended up not being so straightforward and I have open a specific issue: #47526: TABs do not (properly?) support transposition; comments from guitarists are welcome!
I'm a newbie to MS, on a free transfer from GuitarPro6. Capo question: in MS, is it possible to have guitar showing & sounding on staff-&-tab in, say, [D major, two sharps, capo3= F major], and simultaneously have the vocal (or other) lines showing/sounding in in one flat, F major. I'm assuming it's feasible, but having trouble navigating to find out how...
All help appreciated.
Grant.