Set the size of fretboard offset text as part of the style

what text?

The only text I *normally* see are the X's and O's at the top of the strings, and I can't imagine those being bigger. They already practically touch each other for adjacent strings. And if you then decide the show the diagram starting somewhere other than the top, the number that displays appears the same size as the X's and O's. So I guess you'd be wanting to increasing the latter but leave the former alone? Is that standard practice? I could also easily see wanting the whole diagram bigger, with the text scaling accordingly.

Anyhow, there don't seem to be any user-accessible controls for any of this. It's all hardcoded in fret.cpp. It all scales, as does almost everything in MuseScore, with the Space setting. So you can get bigger diagrams with correspondingly bigger text by using bigger staves. I suppose you could try playing tricks with small and invisible staves - attaching a fret diagram to a normal staff that you make invisible, then having your other staves be small, and using an appropriate large Space setting to make your small staves look normal. Not fun, but you did ask for workarounds.

Anyhow, FYI, there is no such thing as a "critical" feature request. Critical is reserved for bugs that cause crashes, corruption, loss of data, etc. But looking at the code, it seems it would be a pretty simple matter to add the following as style parameters:

- stringDistance (currently hardcoded to 0.7sp)
- fretDistance (current hardcoded to 0.8sp)
- font (current hardcoded to FreeSans 4pt, scaled by sp)

I suppose the same font could be used for both X/O and for fret offset, but really, I think the X/O is better off scaling with string distance. So if there really is consensus that it would be common to want the fret offset font larger in proportion, I think maybe only that should be controlled by the style.

Features are, as a general policy, already frozen for 2.0. Not sure if this would end up being an exception. There's a few other things about fret diagrams that feel "unfinished" right now (not the least of which is the apparently useless parameter in style / general / chord symbols to control distance between fret diagram and chord symbol), so maybe this all could get more attention.

That number is indeed very small, but it is hardcoded and made to fit into a rectangle of fret- and sting distance
I think the entire fretboard diagram needs to be larger

also I think it should be horizontally centred to the top fret, as it constitutes that fret's number?

FWIW, looking around at published sheet music, it really seems MuseScore's defaults are pretty spot on size-wise. Both the size of the fret diagram relative to the staff and the size of the text relative to the diagram seem competely in line with the published examples I see. And in particular, I was unable to find any published exampes where the fret offsets were anywhere near as large as the example posted above. On the other hand, I think it's all crazy small in published music too, and the idea of being able to customize this appeals to me, probably using the parameters I mentioned. For simplicity, perhaps just two: one for the overall diagram size, one for fret offset font size.

In general, I don't think having inaccessible parameters - ones set only via configuration files as opposed to dialogs - is looked well upon. Nor are explosions of dialogs, though. It's been suggested that some day MuseScore might add some sort of "configuration editor" to give access to a number of parameters that don't otherwise make sense to expose. I'm pretty sure this is not being considered for 2.0, and I don't know if this is the sort of thing that it is intended for anyhow.

If you can follow the instructins for building MuseScore yourself, it would be an easy matter to build yourself a custom version by changing fret.cpp. But while of course anyone could do that for you, I don't think anyone would want to sign up for doing so every time a bug fix came along you were interested in - so it's really something you might want to try for yourself.

I can submit this for you if you like?
If you show me the code to scale up the font, I can add that too (I had tried yesterday but failed miserably)

In the other hand just create a pull request and make sure to have signed the CLA

See http://musescore.org/fr/developers-handbook/git-workflow

https://github.com/musescore/MuseScore/pull/673

Fixed in 14cd6e5a2a

back to active, to make it a style setting

There is also a question of whether it should get its own full text style, or just have a size parameter you set in style / general / chord symbols. I'd recommend the latter, and have both the overall diagram size and font size settable there. It's kind of a hack, but you'll see Figured Bass does the same. Chord symbols probably could as well, but there no real advantage since the text style already existed in 1.X.

Yes, vertical distance belongs here as well.

Also, we've observed before there is an existing parameter for distance between fret diagram and chord symbol, but that it doesn't seem to do anything. It seems from the code it affects chord symbol position *if* the chord symbol is a child of the fret diagram rather than of the segment, but I don't see any way to make that happen. I think this is leftover from when for a while there was a concept of a frame containing both?

Anyhow, I think we don't need that parameter to work. I guess the parameter was there so a chord symbol would automatically reposition itself relative to the fret diagram if present. But in my experience, it's usually all or nothing. You either have fret digrams everywhere there are chords or you have them nowhere. You can get this behavior already simply by choosing an appropriate vertical position for the chords. If you really do have some chords with fret diagrams and some without - which I don't see often - it shouldn't be a huge hardship to reposition manually.

But actually, it's probably not a big deal to alter the chord symbol layout to check to see if a fret diagram exists at the same segment, rather than check if the parent is a fret diagram.

Understood. If it's as easy to fix as I suggested above, maybe it could be included in a set with the others.

But also, I would think in your case, you'd be likely to want to put the fret diagrams *above* the chord symbols so the chord symbols would be in a consistent location. In which case, it's still true that simply by setting appropriate default vertical positions, no special handling is necessary. And even if you do decide to move the chord symbols above the fretboard diagrams for these cases, it still special purpose enough of a situation where asking the user to move the chord symbol manually is not unreasonable. The Inspector makes it easy enough to just apply a vertical offset to as many chord symbols as you want at once.

I have something working for this, needs a bit of polishing still though

See 1a0152b and let me know what you think.
(this won't be the final version)

Zscore - Just to clarify - you are saying you put fret diagrams under chord symbols even in cases where the fret diagrams are not present for all chords? If so, does that means the chord symbols that do not have fret diagrams are at a lower vertical position than those that do, or that the chord symbols without fret diagrams have empty space below them? If the latter, you can get this effect with the current style settings. If the former, manual adjustment would currently be necessary, but a fix to the "distance to fret diagram" style setting would eliminate that need. I'd be curious though to see if this is something that is a common standard in published music or not.

Jojo - code looks basically good to me, although the variable name biggerFont doesn't do it for me :-). I do kind of like having this be a scale factor rathert han outright font size, as it makes it seem less like soemthing there needs to be an actual text style for.

The examples clarifies nicely, thanks. I'm still wondering if this is something that "standard" that a notation program is "supposed" to support well, or if it's the sort of special case thing that one would expect to need manual adjustments for.

BTW, if that's the size for fret offset you are proposing, I will say that I feel that should definitely *not* be the default. That looks to be almost (but not quite) twice as big as anything I've seen in a published score. From what I can see, the usual size of the fret offset is just slightly more than the distance between frets. But the whole diagram is often printed larger if there are chords that require fret offsets.

As long as people are looking at this, two other things that could be worth adding:

1) Most of the published scores I see put the fret offset to the *right*, not the left. This could be a style parameter too.

2) Most published scores I see also have additional text, like "4 fr." or "4th fret". I could imagine a style parameter for text to append, but in the latter case, it would need to be "1st", "2nd", "3rd", "4th", etc - not always the same. So maybe better to allow text to be entered directly in the fret diagram. This might have to wait.

my proposed code change may look OK (except for variable names, which I'll fix) but it doesn't work. :-(
a) the font is huge
b) not changeable
Scratching my why...

Need to get that going before adding the left/right option.

Edit: a couple hours later
I got it, instead of accessing e.g. "ST_fretNumScale" directly one has to use "score()->styleD(ST_fretNumScale)".
That does work in the score, but not (yet) in the properties dialog, but I'd like that to be a proper preview of what you'd get.

Anyway, here's the version that works for the score: a1cfe86 (and the previous version removed from GitHub)

And here a commit on top for the left/right option: 5393c28

https://github.com/musescore/MuseScore/pull/684

ad 1: I'll try to address this, by having 2 frames on that page, one for Chord Symbols and one for Fret diagrams
ad 2: Capo is part of Chord Symbol, so belongs up there.
ad 3: I'm working on that, but don't have a good solution yet, I'm struggling how to find the height of the fretboard diagram inside the layout of a chord symbol, I have it halfway working with using a fixed value of 5.5sp, but don't like this, so I'll disable this spinbox for the time being
ad 4: this requires a code change too, but I'll look into it.
ad 5: will do, but this needs the above change for consistency
ad 6: I'll change it to "Fret offser number font size:
ad 7: will do

OK, added this to my PR, except for the topics 4 and5, need some advice here:
do we want the position to be negative when we men above staff, or should it be positive?
currently we have it negative for chord symbols, but positive for fretboard diagrams and it really should be consistent, but which way round? I think it is negative in other places too, e.g. voltas and trills.

As far as I know, it is consistent throughout MuseScore: vertical distances are measure downward, so negative numbers are needed to move something higher. Think also text style settings, inspector settings, etc.

That's my view too. Corresponding commit is on its way ;-)

Regarding the size of the fretboard diagram:

To actually calculate the height of the fret diagram while in the chord symbol, I *think* it's a question of referencing the fret diagram's bbox. Probably fd->bbox().height() (where fd is pointer the fret diagram).

As I mentioned previously, there might be a layout-order issue: Harmony objects are currently laid out before FretDiagram objects according to element.h & element.cpp. So you might consider reversing those two if it doesn't break something else (which it might - I'll bet this stuff is pretty delicate). But without reversing the order, you may be looking at a stale value of fd->bbox(), so for instance adding a fret diagram after the chord symbol might not affect the chord symbol until the *next* layout() call.

Actually, looking further at harmony.cpp, I see some semi-related code is already there - not sure how I missed it earlier. At the very end of Harmony::layout(), there is a calculation involving bbox().top(). Unfortunately, this code too is looking for a parent of type FRET_DIAGRAM rather than looking for another annotation on the same segment with the same track. So this code isn't being hit.

Hmmm. On further examination, it looks like this code is not moving the chord symbol, but is instead allocating extra space for the staff to accommodate the chord symbol. Thus, increasing the vertical distance between staves / systems. This is done only in the case where a fret diagram also exists, which makes sense, because extra space is allocated for fret diagrams so we might as well do so for the chord symbol too. But since this code is presumably never being hit, no extra space would be allocated here even if you got the chord symbols to display above the fret diagrams. So if you're already testing at the top of the function to find a matching fret diagram, maybe just check the same flag here at the bottom and you'll get extra space allocated for the chord symbol for free.

Again, this extra space is allocated only in the fret diagram case, which I think is good for now. Eventually we might want an option to add extra space for all chord symbols, but that would be too disruptive to do by default at this point.

Genius! This works! Commit on its way...
{syntaxhighlighter brush:cpp}
@@ -848,6 +848,15 @@ void Harmony::layout()
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
yy += score()->styleP(ST_harmonyY);
+ Segment* s = static_cast(parent());
+ for (Element* e : s->annotations()) {
+ if (e != this && e->type() == FRET_DIAGRAM && e->track() == track()) {
+ yy = score()->styleP(ST_fretY);
+ yy -= score()->styleP(ST_harmonyFretDist);
+ yy -= e->bbox().height();
+ break;
+ }
+ }
}
else if (parent()->type() == FRET_DIAGRAM)
yy = score()->styleP(ST_harmonyFretDist);
{/syntaxhighlighter}

Fantastic! Are you fixing the code at the bottom too so extra space is allocated for the chord? You might as well. Probably save "e" in the code above into another variable "fd" (explicitly initialized to 0) local to the whole function, so you can reference it later as "if (fd)".

I haven't yet touched that part, will have a try tomorrow.

Edit: I just looked at it and don't understand what you mean.

Do you mean something like this?
{syntaxhighlighter brush:cpp}
@@ -844,6 +844,7 @@ void Harmony::layout()
}

qreal yy = 0.0;
+ Element* fd = NULL;
if (parent()->type() == SEGMENT) {
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
@@ -854,6 +855,7 @@ void Harmony::layout()
yy = score()->styleP(ST_fretY);
yy -= score()->styleP(ST_harmonyFretDist);
yy -= e->bbox().height();
+ fd = e;
break;
}
}
@@ -902,7 +904,7 @@ void Harmony::layout()
setUserOff(readPos() - ipos());
setReadPos(QPointF());
}
- if (parent()->type() == FRET_DIAGRAM && parent()->parent()->type() == SEGMENT) {
+ if ((parent()->type() == FRET_DIAGRAM && parent()->parent()->type() == SEGMENT) || fd) {
MStaff* mstaff = static_cast(parent()->parent())->measure()->mstaff(staffIdx());
qreal dist = -(bbox().top());
mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());

{/syntaxhighlighter}

Probably not, as this crashes ;-)
Guess it's time for bed...

Yes, that's the basic idea. Except that won't quite work, as the code within that block is assuming the chord is a child of the fret diagram, so it is going up two levels of parent() to get to the segment - line 23 above. As far as I know, all that stuff about parent being FRET_DIAGRAM can just be ripped out. If you must leave it in, you've have to initialize mstaff differently for that case versus the fd case. But as I said, as far as I can tell, other places in the code just assume the parent is segment, so I don't think we're gaining anything keeping a test for a condition that will never happen.

So it could go more like this:

    if (fd) {
        MStaff* mstaff = static_cast<Segment*>(parent())->measure->mstaff(staffIdx);
        ... // everything is the same from here on out
    }

As I said, I don't know that this code actually works properly, but it's not even being hit now. So at least give it a shot to see if it works.

yea, I wasn't thinking properly, but this doesn't do anything to the layout:
{syntaxhighlighter brush:cpp}
@@ -844,6 +844,7 @@ void Harmony::layout()
}

qreal yy = 0.0;
+ Element* fd = NULL;
if (parent()->type() == SEGMENT) {
Measure* m = static_cast(parent()->parent());
yy = track() < 0 ? 0.0 : m->system()->staff(staffIdx())->y();
@@ -854,6 +855,7 @@ void Harmony::layout()
yy = score()->styleP(ST_fretY);
yy -= score()->styleP(ST_harmonyFretDist);
yy -= e->bbox().height();
+ fd = e;
break;
}
}
@@ -907,6 +909,11 @@ void Harmony::layout()
qreal dist = -(bbox().top());
mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());
}
+ else if (fd) {
+ MStaff* mstaff = static_cast(parent())->measure()->mstaff(staffIdx());
+ qreal dist = -(fd->bbox().top());
+ mstaff->distanceUp = qMax(mstaff->distanceUp, dist + spatium());
+ }
}

//---------------------------------------------------------

{/syntaxhighlighter}
Nor does it when dropping the 'fd->'

Shoot, I was going to say drop the "fd->" - assuming you mean on the bbox() call. The point of the original code, as far as I can see, is to allocate more room above the staff to accomodate the chord symbol itself. Space for the fret diagram is allocated in FretDiagram::layout(). Anyhow, since we are trying to allocated room for the chord symbol, we definitely want bbox() (which is to say, this->bbox()), not fd->bbox().

To be clear on what this does:

Have a score with fairly tight system spacing - tight enough that there is little room for fret diagrams. Now add a fret diagram to a note/rest on the second system. You should see the system move down as extra space is allocated for the fret diagram (because of the code in FretDiagram::layout()). Now add a chord a symbol to that same note/rest. If the code you are looking at is doing it's job, more extra space should be allocated for the chord symbol, so the system should move down farther.

I have no trouble believing it doesn't work, though. The code doesn't really look much like the code in FretDiagram::layout(). Could be that's not really supposed to be a negative value in dist, could be simply adding spatium() to it is the wrong thing to do.

I get the sense maybe you aren't actually running under a debugger, so stepping through code line by line isn't feasible? Could be worth figuring out QtCreator - not just for this, but in general.

Meanwhile, I'm looking into this, and will let you know shortly.

I am using QtCreator, but haven't yet got the debugger to run. I did try with and without the "fd->", no difference and the staff doesn't move down further that without any of the 2 changes. I used a qDebug() statement to check it enters that section and it does.

Actually we want to always allocate space for chord symbols (like we do fpr lyrics), and if there is a fretboard, add to its space allocation, so maybe we catch both birds with one stone?

OK, it *does* seem to work, but not well. First, it actually only affects spacing within a system, not space between systems. Not sure why, since with fret diagrams it works both ways. But also, the chord symbol placement is wrong. Although while you're typing it shows close to the staff where it should be, it moves higher - probably to where its original position would have been had the staff not moved down - upon completion of chord symbol entry.

So now we're dealing with deeper intricacies of layout than I am comfortable with. If I were you, I would make the change exactly as you have it but put an "#if 0" - "#endif" around that whole block and add a comment there like "TODO - allocate additional space for chord symbol". That means extra space won't be allocated for chord symbols, but that's OK as far as I am concerned - you can add space for that staff yourself by dragging it down, or increase system distance globally if necessary.

Posts crossed :-)

FWIW, when I did my test, it *was* allocating space for chord symbols always (because I was too lazy to reproduce your code that looks for a fret diagram). I agree that at some point it would be good to provide such an option. But since most existing scores aren't expecting that space, and actually, it isn't common in published scores to alter staff spacing just for chord symbols, it would have to be am option in my opinion. And I have to think, post-2.0.

I'd rather leave it as is in my current PR and submit a new issue for this, with a hint at the code change I tried and couldn't get to work.
I guess there's also quite some dead code to be removed, unless fret frames are supposed to come back one day.

As long as your current PR still has the old check for parent, so the code to add extra space won't get hit. I wouldn't want that code to get hit, since it actually messes up layout.

the current PR messes up the position of the chord symbol when having a fretboard diagram on any non-top staff :-(
Stupidly I only ever tested with the top staff.
Looking into this now.

OK, something very strange is going on, and it is not my PR, as it happens with a nightly build (b453dfe):

adding a fretboad diagram to the top staff allocates extra space above it, added chord symbols appear as per the configured setting above staff
adding a fretboard diagram on the bottom staff of a 2.staff instrument allocates space above it (i.e. between the staves), added chord symbols appear much higher than the configured value (but still between staves), but during entry the curser shows up at the right spot.
adding a fretboad diagram to any other independent staff does not allocate additional space about it and added chord symbols behave as strangle as for the bottom staff of a 2-staff instrument.

My PR's last commit's behavoir seems to be just a poor victim... here it looks like this:

At least all chords in the same hight...

a) I have no idea how to fix that
b) I won't find the time to look into it further for the next couple days...

This is similar to what I observed with the code to allocate more space for chord symbols, so I guess maybe the problem lies elsewhere.

I'll try to look into this. It's possible the our code will cross and be hard to merge, so I may wait until your PR goes through. As far as I can tell, the only only occurs if fret diagram are involved, right? I don't see any such positioning issues while just enter chord symbols. Or maybe I just haven't found the right series of steps?

yes, only when fretboard diagrams are involved on any but the topmost staff

You might fork my repo and work from there?

My suspicion is the culprit is at fret.cpp, Line 304 ff , i.e. near the end of Fretdiargam::layout()

@Marc: did you get anywhere with looking into this?
I've just filed a new issue: #24735: fretboard diagrams don't allocate extra space on any non-top staff

No, I haven't had time, plus it really doesn't make sense to look at this until the text handling code settles down. The recent changes (over the past month or so) have really shaken things up and much is still broken.

Fixed in 8018564b6b

reopening as http://musescore.org/en/node/24349#comment-95166 still happens

and unasign for the time being...

nonsense, there is a separate issue for this: #24735: fretboard diagrams don't allocate extra space on any non-top staff

Automatically closed -- issue fixed for 2 weeks with no activity.