This would make a lot of sense. The string numbers in the notation really should be mirrored in the TAB.
The string number objects appear to be able in the Plugin API as element type 39 with the text property containing the string number so this should be possible via a plugin if it is not integrated into the main program.
TAB string and fret number can be changed via a plugin provided this wouldn't change the note's pitch.
Didn't get to the capo, but the string text should be working. Testing appreciated :) No properties were added, it just straight up takes account of the presence of a string text - or at least it should.
P.S. Can a user insert a capo in MuseScore 3? Some code exists since 2018/2019 for capos from a staff:
but from a cursory look it isn't apparent to me how the user could go about placing one. Maybe just the "functionality' was there but then it wasn't user-allowable until MS4? In which case, unfortunately not going to be able to get that implemented today as intended :-/
I was referring to the statement found here:
"Here the barre/Capo line has no influence" etc.
Sounds like they're two different things and not related to each other. To implement something that takes into account these "barre lines", there needs to be a specific "barre line" type or style internal in Musescore, but the only thing I'm aware of so far is what I'm used to as a prev guitar player (barres for barre chords in a fret diagram... not text lines). Unfortunately I don't see any "barre lines" as an actual type handled internally so far, but I certainly could be overlooking something.
Aside: looks like "barre lines" are more for classical guitarists or something of the sort, so I'm unfamiliar with them. Again, the only thing I knew about were barre chords, but apparently they are instructions in classical guitar to not move the fretting hand during a passage, keeping it at a particular fret (barred) via roman numeral designation. Seems kind of 'unnecessary' to me to do in tablature, but on a treble-clef I suppose it's reasonable.
Ironically, it makes more sense to me as a notation program instruction so that it applies to linked tab-staff automatically, yet that's the very thing it doesn't do in the program. End of aside...
The Barre/Capo issue is blurry ... in multiple regards!
Guitar bar — Nomenclature / Terminology
First, in common usage, the Barre/Capo can be represented by:
• BIII for Barre, a barre at the 3rd fret • CIII for Capotasto, for a barre at the 3rd fret (equivalent to BIII) • III alone is ambiguous, indicating either a barre at the 3rd fret or a general 3rd fret playing position.
In other words, in guitar notation Barre and Capo are equivalent in meaning. MuseScore 4 could emphasize this with a "Capotasto" tooltip, or better yet "Capotasto/Barre" tooltip—and that would also help avoid ambiguity regarding Capo referring to a physical capo.
Second, I don't see a dedicated Barre object in MuseScore 3, and MS3's guitar related objects are strewn about in various palettes. It appears that scorists rely on the Text Line object which a) has a "Staff" Text Line tooltip in the Text Palette, and b) has "Staff" as its default text, though the user can freely enter CI, CII, CIII, CIV ... or BI, BII, BIII, BIV ... or whatever they want in MS3's Inspector, such as Barre III or Bar III.
Third In MuseScore 3 capoing, as with a physical capo device, is emulated with a Staff Text object>Staff Text properties>Capo Settings>Capo. (It's buried pretty deep in MS3, right?)
Importing MS3 scores into MuseScore 4
MuseScore 4 now has a dedicated Guitar Palette. And it handles capoing far better via its Guitar>Capo object—interestingly though, in the Properties panel, it appears to be just a Text object.
And after importing an MS3 score to MS3 it appear's that:
• the MS3 Text Line (our makeshift Capotasto/Barre symbol) survives import and remains the same type of object.
• a MS 3 Staff Text with capo properties is converted to a MS4 Capo popup, and yet appears in the Properties panel as a Text object.
I hope I got most of this right ... and that it helps!
Here's a simple score for testing an import of a MS3 score to MS4:
It's late, and I'll have to think this through. But I don't think a Staff Text Line with Capo properties needs to affect anything in the tablature staff. The net result simply transposes the sound output without notational consequences, i.e. the notation works as it does for a transposing instrument, so there's nothing to change or restrict in the tablature.
As accomplished, the String Number fix you've imparted is much welcomed.
And so too allowing the Capo/Barre construct to affect linked tablature ... once the internals allow that.
Oh man, didn't know that it transposed the instrument. Personally, I find that weird. Are you saying, for instance, that if a person puts a capo on fret 3, then plays at the 12th fret (double dotted position on guitar), that that's considered in reality the sound of the quote-unquote 15th fret, and to get the original fret 12 the guitarist would play fret 9? I would never have thought like that when I used to play, but then again I was never professionally trained. It just meant for me that playing below the 3rd fret is impossible, and that "open" means "fret 3" without requiring a fretting hand, however the instrument be tuned. To see a tab position @ "fret 2" with an instruction for a capo at fret 3 beforehand would seem absurd to me.
It now has three Capo settings. At each capo setting you can hear the transposition applied to the sound output. For instance:
• at capo 3 the sound output is a minor 3rd higher than the written 8vb pitch.
• at Capo 5 the sound output is a perfect 4th higher than the written 8vb pitch.
Note that the Capo setting emulates the placement of a physical capo on the guitar. Concert pitch button has no effect, because there's no Transposition in Staff properties. It appears that the transposition is handled internally and non transparently.
For ease of access, here's a screenshot of the above mscz:
The sounds change, but nothing visual changes, so practically speaking as it is, the capo text functions as like a "moveable" transpositioning element, which is kind of neat.
My own personal judgment is that it's undesirable, but again, my judgment in the matter doesn't have any bearing on the validity of the current functionality. If it were up to me, I'd rather see like a "transpose" or "moveable tuning"-like element that would function as how the current capo text works, but my opinion in the matter is of no concern :) It raises the issue though that to have an actual barre-line automatically dictate how the chord/phrase shaping algorithms work would be nice to have. Heck, in a sense the auto-shaping in general could probably be "updated" in some sense. I vaguely remember in the past getting weird results with linked-staves and thinking it could be better by default. Thanks for the conversation...
...Maybe should separate the second commit so it's like a [WIP] separate PR or something or "concept" pr so that it doesn't affect merely having the string text affect the tablature.
Re: worldwide weary, "To see a tab position @ "fret 2" with an instruction for a capo at fret 3 beforehand would seem absurd to me."
This is indeed how capo works! All the fret numbers become relative to the capo. So, a C shape cord with capo 2 is actually a D chord. It makes things so much easier to read and play.
Thanks! I understand that it would make chord shapes easier since they follow the open voicing shapes (with the ol' caged system for guidance or what have you), but if I were to read tabs with passages of notes and play at the same time, I'd hate to have to re-calculate fret positions mentally while reading tabs and playing (and not to be able to rely on fret markers anymore to be true to value), but we all work in different ways. Twelfth fret will always be that double-dotted position on the physically 12th fret for me personally. Then again I never did read tabs with capo positions so I'm inexperienced :-/ At least I know now how capo notation works for other people.
Since I don't use notation or note names at all, (only TAB), I have no mental re-calculations to do. For me, fret numbers are always relative to the capo. The nut is capo 0 so at this setting the absolute fret numbers just happen to coincide with the relatives ones - but this is a special case.
Yeah that makes sense, yet from my point of view I don't see how there are no mental re-calculations because I'm so bound up with the actual physical fretboard as an idea. When I think "12th fret", I think of the 12th physical fret and not that in relation to a capo position. For example, If I had a capo at fret-3 and someone said "Play 12th fret," or I read "12" on a tablature, I would have played the absolute neck position at 12th fret, not relatively to the capo which would be the 15th fret position absolutely of the guitar neck. Different way of seeing things, I suppose.
But back to the coding topic, at least [String text] can work in the PR. Should probably retract the capo change to keep it in accord with how it was. Too bad there's no internal "Barre Line" code because that would've been nice to automatically re-factor the tablature in accord with the barre position.
Be aware that the capo fret can be changed at any place where there is a stave text. I guess that it's unlikely to change in a real world score but the potential exists in MuseScore.
In relation to your observation, the nice thing here is that whenever the capo fret is changed (by any/all staff text), it gets "added" into a list so that nothing extra is necessary. Invoking Staff::capo(const Fraction& tick), where tick is the segment position of whatever note being evaluated, will provide a capo offset value. No further testing is necessary.
If someone said to me, "play the 12th fret" then I would play the 12th physical fret. But seeing fret 12 in TAB when capo 3 is active I would play fret 15, so I suppose this is a re-calculation but it's trivial and totally automatic.
Sorry. It seems I used the term “transposed” in an ambiguous manner.
To clarify things (that you likely already know) first I'll contrast a Transposing Instrument with a capoed instrument. Then absolute frets vs. capo relative frets.
Transposing Instruments vs. a Capoed Instrument
In MuseScore Staff/Part Properties>Transpose transposes the notation for a Player’s Part, without altering the Sounding Pitch. There’s no pitch transposition, just the option to view a Part at written pitch or Concert pitch.
Conversely, a MuseScore Capo Fret property leaves the notation unchanged but raises the Sounding Pitch. For instance, with the Capo fret property = 3 MuseScore transposes the sounding pitch up 3 semitones. (When I when I mentioned the transposition in a previous post I only meant that a MuseScore Capo property transposes the sounding pitch.)
But before we can speak of how to view things “fretwise” let’s look at the difference between absolute frets and capo-relative frets
Absolute Frets vs. Capo-relative frets
An absoute fret is the same whether there’s a capo on the guitar or not. For instance, in absolute terms Fret 12 is the one with the double dot—this is true when there’s no capo on the guitar OR if the capo is on any fret.
When using capo-relative frets (the norm) we view the capo as the nut of the guitar, and imagine that no frets “behind” the capo exist, because they are not accessible (except when using a partial capo.)
By default frets in tablature notation are capo-relative, and overwhelmingly this is also the way guitarist speak of them. And it's how MuseScore handles it. Here are some examples:
• The “open string” at the capo is written and referred to as 0 (zero).
• When there’s a capo at fret 3, the written tablature fret for the “open strings” is 0.
• The capo-relative fret directly above the capo is 1.
• With the capo at fret 7 the tablature number 5 is the same as the absolute 12th fret.
• With a capo at fret 3 tablature fret number 12 is played 12 frets above the capo—which is absolute fret 15, as yonah_ag pointed out.
Experimental example score
In this score I attempted to create "capoed guitar tablature" (but without a capo property in effect) just by using STarr/Part Properties>Transposition. It's weird ... and I haven't quite wrapped my head around it, but here it is:
Yeah, I understand now that Scorster's statement "barre/capo line" was incorrect based on your input, and that in reality it is a mere a text-line suggesting to the musician to barre at a given fret for the given phrase under the line. Thanks for the feedback!
Comments
This would make a lot of sense. The string numbers in the notation really should be mirrored in the TAB.
The string number objects appear to be able in the Plugin API as element type 39 with the text property containing the string number so this should be possible via a plugin if it is not integrated into the main program.
TAB string and fret number can be changed via a plugin provided this wouldn't change the note's pitch.
Seconded. This would be extremely useful.
https://github.com/musescore/MuseScore/issues/22228
In reply to https://github.com/musescore… by scorster
Sounds like a decent idea! No promises, but I'll see if I can make something work in "3.7" for you to test.
In reply to Sounds like a decent idea!… by worldwideweary
Thanks!!
In reply to Thanks!! by scorster
Didn't get to the capo, but the string text should be working. Testing appreciated :) No properties were added, it just straight up takes account of the presence of a string text - or at least it should.
artifact @ https://github.com/Jojo-Schmitz/MuseScore/pull/403 but there are some mtest/vtest problemos
In reply to [inline… by worldwideweary
The mtest/vtest failures have been fixed meanwhile
In reply to [inline… by worldwideweary
See also https://github.com/musescore/MuseScore/pull/22254, where I've ported it to master
P.S. Can a user insert a capo in MuseScore 3? Some code exists since 2018/2019 for capos from a staff:
![capo.png]( "capo.png")
but from a cursory look it isn't apparent to me how the user could go about placing one. Maybe just the "functionality' was there but then it wasn't user-allowable until MS4? In which case, unfortunately not going to be able to get that implemented today as intended :-/
In reply to P.S. Can a user insert a… by worldwideweary
Yes, capo is supported in MS3:
See https://musescore.org/en/handbook/3/capo-playback
In reply to Yes, capo is supported in… by yonah_ag
Cool, thanks.
In reply to Cool, thanks. by worldwideweary
Also, in Scorster's above score, it looks like there's a capo "line". Maybe that's a Mu4 only feature? The handbook doesn't seem to mention it.
In reply to Also, in Scorster's above… by worldwideweary
I only see barre lines in scorster's score; no capo lines.
https://musescore.org/en/handbook/3/lines#Guitar_barre_line
In reply to I only see barre lines in… by yonah_ag
I was referring to the statement found here:
![barrelinecapo.png]( "barrelinecapo.png")
"Here the barre/Capo line has no influence" etc.
Sounds like they're two different things and not related to each other. To implement something that takes into account these "barre lines", there needs to be a specific "barre line" type or style internal in Musescore, but the only thing I'm aware of so far is what I'm used to as a prev guitar player (barres for barre chords in a fret diagram... not text lines). Unfortunately I don't see any "barre lines" as an actual type handled internally so far, but I certainly could be overlooking something.
Aside: looks like "barre lines" are more for classical guitarists or something of the sort, so I'm unfamiliar with them. Again, the only thing I knew about were barre chords, but apparently they are instructions in classical guitar to not move the fretting hand during a passage, keeping it at a particular fret (barred) via roman numeral designation. Seems kind of 'unnecessary' to me to do in tablature, but on a treble-clef I suppose it's reasonable.
Ironically, it makes more sense to me as a notation program instruction so that it applies to linked tab-staff automatically, yet that's the very thing it doesn't do in the program. End of aside...
In reply to I was referring to the… by worldwideweary
The Barre/Capo issue is blurry ... in multiple regards!
Guitar bar — Nomenclature / Terminology
First, in common usage, the Barre/Capo can be represented by:
• BIII for Barre, a barre at the 3rd fret
• CIII for Capotasto, for a barre at the 3rd fret (equivalent to BIII)
• III alone is ambiguous, indicating either a barre at the 3rd fret or a general 3rd fret playing position.
In other words, in guitar notation Barre and Capo are equivalent in meaning. MuseScore 4 could emphasize this with a "Capotasto" tooltip, or better yet "Capotasto/Barre" tooltip—and that would also help avoid ambiguity regarding Capo referring to a physical capo.
Second, I don't see a dedicated Barre object in MuseScore 3, and MS3's guitar related objects are strewn about in various palettes. It appears that scorists rely on the Text Line object which a) has a "Staff" Text Line tooltip in the Text Palette, and b) has "Staff" as its default text, though the user can freely enter CI, CII, CIII, CIV ... or BI, BII, BIII, BIV ... or whatever they want in MS3's Inspector, such as Barre III or Bar III.
Third In MuseScore 3 capoing, as with a physical capo device, is emulated with a Staff Text object>Staff Text properties>Capo Settings>Capo. (It's buried pretty deep in MS3, right?)
Importing MS3 scores into MuseScore 4
MuseScore 4 now has a dedicated Guitar Palette. And it handles capoing far better via its Guitar>Capo object—interestingly though, in the Properties panel, it appears to be just a Text object.
And after importing an MS3 score to MS3 it appear's that:
• the MS3 Text Line (our makeshift Capotasto/Barre symbol) survives import and remains the same type of object.
• a MS 3 Staff Text with capo properties is converted to a MS4 Capo popup, and yet appears in the Properties panel as a Text object.
I hope I got most of this right ... and that it helps!
Here's a simple score for testing an import of a MS3 score to MS4:
https://musescore.com/user/35880724/scores/15314767
scorster
In reply to The Barre/Capo issue is… by scorster
Thanks for the feedback.
Since there isn't really any internals for barre text lines, I can at least get the Capo text going for testing:
applied another commit to the mentioned PR
In reply to Thanks for the feedback… by worldwideweary
It's late, and I'll have to think this through. But I don't think a Staff Text Line with Capo properties needs to affect anything in the tablature staff. The net result simply transposes the sound output without notational consequences, i.e. the notation works as it does for a transposing instrument, so there's nothing to change or restrict in the tablature.
As accomplished, the String Number fix you've imparted is much welcomed.
And so too allowing the Capo/Barre construct to affect linked tablature ... once the internals allow that.
Thanks for all this!
scorster
In reply to It's late, and I'll have to… by scorster
Oh man, didn't know that it transposed the instrument. Personally, I find that weird. Are you saying, for instance, that if a person puts a capo on fret 3, then plays at the 12th fret (double dotted position on guitar), that that's considered in reality the sound of the quote-unquote 15th fret, and to get the original fret 12 the guitarist would play fret 9? I would never have thought like that when I used to play, but then again I was never professionally trained. It just meant for me that playing below the 3rd fret is impossible, and that "open" means "fret 3" without requiring a fretting hand, however the instrument be tuned. To see a tab position @ "fret 2" with an instruction for a capo at fret 3 beforehand would seem absurd to me.
In reply to Oh man, didn't know that it… by worldwideweary
I've updated the test score I attached here.
It now has three Capo settings. At each capo setting you can hear the transposition applied to the sound output. For instance:
• at capo 3 the sound output is a minor 3rd higher than the written 8vb pitch.
• at Capo 5 the sound output is a perfect 4th higher than the written 8vb pitch.
Note that the Capo setting emulates the placement of a physical capo on the guitar. Concert pitch button has no effect, because there's no Transposition in Staff properties. It appears that the transposition is handled internally and non transparently.
Scorster
In reply to I've updated the score… by scorster
For ease of access, here's a screenshot of the above mscz:
The sounds change, but nothing visual changes, so practically speaking as it is, the capo text functions as like a "moveable" transpositioning element, which is kind of neat.
My own personal judgment is that it's undesirable, but again, my judgment in the matter doesn't have any bearing on the validity of the current functionality. If it were up to me, I'd rather see like a "transpose" or "moveable tuning"-like element that would function as how the current capo text works, but my opinion in the matter is of no concern :) It raises the issue though that to have an actual barre-line automatically dictate how the chord/phrase shaping algorithms work would be nice to have. Heck, in a sense the auto-shaping in general could probably be "updated" in some sense. I vaguely remember in the past getting weird results with linked-staves and thinking it could be better by default. Thanks for the conversation...
...Maybe should separate the second commit so it's like a [WIP] separate PR or something or "concept" pr so that it doesn't affect merely having the string text affect the tablature.
In reply to Oh man, didn't know that it… by worldwideweary
Re: worldwide weary, "To see a tab position @ "fret 2" with an instruction for a capo at fret 3 beforehand would seem absurd to me."
This is indeed how capo works! All the fret numbers become relative to the capo. So, a C shape cord with capo 2 is actually a D chord. It makes things so much easier to read and play.
In reply to Re: worldwide weary, "To see… by yonah_ag
Thanks! I understand that it would make chord shapes easier since they follow the open voicing shapes (with the ol' caged system for guidance or what have you), but if I were to read tabs with passages of notes and play at the same time, I'd hate to have to re-calculate fret positions mentally while reading tabs and playing (and not to be able to rely on fret markers anymore to be true to value), but we all work in different ways. Twelfth fret will always be that double-dotted position on the physically 12th fret for me personally. Then again I never did read tabs with capo positions so I'm inexperienced :-/ At least I know now how capo notation works for other people.
In reply to Thanks! I understand that it… by worldwideweary
Since I don't use notation or note names at all, (only TAB), I have no mental re-calculations to do. For me, fret numbers are always relative to the capo. The nut is capo 0 so at this setting the absolute fret numbers just happen to coincide with the relatives ones - but this is a special case.
In reply to Since I don't use notation… by yonah_ag
Yeah that makes sense, yet from my point of view I don't see how there are no mental re-calculations because I'm so bound up with the actual physical fretboard as an idea. When I think "12th fret", I think of the 12th physical fret and not that in relation to a capo position. For example, If I had a capo at fret-3 and someone said "Play 12th fret," or I read "12" on a tablature, I would have played the absolute neck position at 12th fret, not relatively to the capo which would be the 15th fret position absolutely of the guitar neck. Different way of seeing things, I suppose.
But back to the coding topic, at least [String text] can work in the PR. Should probably retract the capo change to keep it in accord with how it was. Too bad there's no internal "Barre Line" code because that would've been nice to automatically re-factor the tablature in accord with the barre position.
In reply to Yeah that makes sense, yet… by worldwideweary
Be aware that the capo fret can be changed at any place where there is a stave text. I guess that it's unlikely to change in a real world score but the potential exists in MuseScore.
In reply to Be aware that the capo fret… by yonah_ag
In relation to your observation, the nice thing here is that whenever the capo fret is changed (by any/all staff text), it gets "added" into a list so that nothing extra is necessary. Invoking Staff::capo(const Fraction& tick), where tick is the segment position of whatever note being evaluated, will provide a capo offset value. No further testing is necessary.
In reply to Yeah that makes sense, yet… by worldwideweary
If someone said to me, "play the 12th fret" then I would play the 12th physical fret. But seeing fret 12 in TAB when capo 3 is active I would play fret 15, so I suppose this is a re-calculation but it's trivial and totally automatic.
In reply to Oh man, didn't know that it… by worldwideweary
Regarding the reply at: https://musescore.org/en/node/362557#comment-1236510
Sorry. It seems I used the term “transposed” in an ambiguous manner.
To clarify things (that you likely already know) first I'll contrast a Transposing Instrument with a capoed instrument. Then absolute frets vs. capo relative frets.
Transposing Instruments vs. a Capoed Instrument
In MuseScore Staff/Part Properties>Transpose transposes the notation for a Player’s Part, without altering the Sounding Pitch. There’s no pitch transposition, just the option to view a Part at written pitch or Concert pitch.
Conversely, a MuseScore Capo Fret property leaves the notation unchanged but raises the Sounding Pitch. For instance, with the Capo fret property = 3 MuseScore transposes the sounding pitch up 3 semitones. (When I when I mentioned the transposition in a previous post I only meant that a MuseScore Capo property transposes the sounding pitch.)
But before we can speak of how to view things “fretwise” let’s look at the difference between absolute frets and capo-relative frets
Absolute Frets vs. Capo-relative frets
An absoute fret is the same whether there’s a capo on the guitar or not. For instance, in absolute terms Fret 12 is the one with the double dot—this is true when there’s no capo on the guitar OR if the capo is on any fret.
When using capo-relative frets (the norm) we view the capo as the nut of the guitar, and imagine that no frets “behind” the capo exist, because they are not accessible (except when using a partial capo.)
By default frets in tablature notation are capo-relative, and overwhelmingly this is also the way guitarist speak of them. And it's how MuseScore handles it. Here are some examples:
• The “open string” at the capo is written and referred to as 0 (zero).
• When there’s a capo at fret 3, the written tablature fret for the “open strings” is 0.
• The capo-relative fret directly above the capo is 1.
• With the capo at fret 7 the tablature number 5 is the same as the absolute 12th fret.
• With a capo at fret 3 tablature fret number 12 is played 12 frets above the capo—which is absolute fret 15, as yonah_ag pointed out.
Experimental example score
In this score I attempted to create "capoed guitar tablature" (but without a capo property in effect) just by using STarr/Part Properties>Transposition. It's weird ... and I haven't quite wrapped my head around it, but here it is:
Guitar with tranposition to emulate a capo.mscz
Partial capo and Absolute vs. Capo Relative frets
https://musescore.org/en/node/353203
https://musescore.com/user/35880724/scores/12476551
https://musescore.org/en/node/317042
https://github.com/orgs/musescore/discussions/20476
scorster
In reply to I was referring to the… by worldwideweary
Re: worldwideweary • Apr 7, 2024 - 22:54
"I was referring to the statement found here:"
The statement below the stave is simple text. The barre indicator is a line. There is no capo line or object.
In reply to The statement below the… by yonah_ag
Yeah, I understand now that Scorster's statement "barre/capo line" was incorrect based on your input, and that in reality it is a mere a text-line suggesting to the musician to barre at a given fret for the given phrase under the line. Thanks for the feedback!