Offsetting symbols in text(?)

• Feb 19, 2016 - 05:08

Called it that because I'm not sure exactly what to call it. Here's the problem:

See attached. I had to use system text to get the red capo chords (putting chords above the concert pitch chords has been discussed to death; that's not the point this time). In order to get the proper sharp symbol instead of a number sign (or a pound sign or a hash tag, depending upon how old you are), I resorted to the F2 symbol set. But when I select the sharp sign, well, you can see where it lands: well below where I'd think it should land. (See first line for first example; but it's below the baseline throughout.) I would expect the symbol to align on the bottom with the baseline of the text, if not be elevated above as almost a superscript (almost, but not quite). But at least for Franklin Gothic Heavy, it doesn't. Without going into all the typefaces I have on my computer, is this a function of the typeface, or of the program? And in either case, can it be made to align on the baseline, in a future update if nothing else?

Thank you.


Comments

Workaround: select the sharp, use the icons in the text bar:

Salmo103.png

and increases the size. A little annoying but it might work?

In reply to by Shoichi

Yes, it would. It takes about an 8-point increase in the size to overcome the shrinking induced by superscripting the sharp character (and thanks for pointing that out on the properties bar [if that's what it's called; I don't know; but it's a handy term for it]); but it would achieve the desired effect.

In reply to by Shoichi

My experience has been that I wind up with one set of chords supreimposed over the other, and I'm stuck moving each of the second line of chords individually. Exceedingly tricky and time consuming. On top of that, changing the text definition for one set of chords usually alters all sets of chords, as long as one used the standard chord insertion protocol. Is there some magic wand I need to wave? This is typical of those who have asked for options in placing the capo chords (which, as I said at the outset, has been done to death here already).

Maybe I'm missing something, but I don't understand why putting capo chords above the concert pitch chords required the use of system text. This was discussed somewhere before?

EDIT: I see from a resposne you are referring to trying to select and move them, but this is easy, can be done in several different ways. For instance, enter one row of chords first, then select them all (right click one, Select / All Similar Elements) and use the Inspector to move them. Then enter the second row normally. This is but one of several different ways one could do this, any of which are bound to be much easier and more effective than trying to forcing plain text to look like a chord symbol.

As far as I know, the musical symbols always come from MuseScore's own font, since most other fonts don't provide those characters. And the positioning of various characters is set by standards like SMuFL and Unicode, and often ends up not really being exactly what one might want in some specific situation. Offhand, though, I can't think of a reason why this particular one should be that way.

In reply to by Marc Sabatella

It required the use of system text because MS, if you add a capo number to the chord symbols entry under general style, puts the capoed chord beside the concert chord and not above it. And in version 2.0.2, there's no option to put the capoed chords above the concert chords rather than beside them.

I just tried the offset trick in my latest score. Once that first line of chords is entered, the second line of chords does not respond as though it were the first; specifically, when I go to the next note where there's a chord change, the cursor jumps to the line above. Not where I want it. This means I need to insert each concert pitch chord note by note. So the workaround is still as awkward as using system text or anything similar.

Oh, and for those who are accustomed to seeing capoed chords like this: (D7), when you add the parentheses to the first line of chords, you get this: ( D7 ). Ungainly; and I've found no way to close up the gap. Yes, I enter the chord as (D7); but as soon as I leave the chord, the display shows ( D7 ). Not really what I want; but I'll live with it.

In reply to by km2002

Oh, yes, I forgot that the first row would "steal" the cursor. But that's easy to defeat - just enter the second row into a different voice (eg, enter one note in voice 2, attach the first chord symbol to that, then go from there. This also has the advantage of making it easy to then re-select either row later to adjust position further. Probably other workarounds exist that will be far better than trying to to-opt system text for this purpose. If they are chord symbols, you really should focus on finding a way of the chord symbol facility - that way they behave they should. Chord symbols will transpose correctly, export to MusicXML correctly, they will automatically respace measures where necessary, etc - all sorts of things that system next will never do.

BTW, the parenthesis you enter manually are not meant for capo - they are meant to indicate alternate chords or sequences (eg, "( Dmi7 G7 )". And in those cases, that is about the right amount of space. Eventually, we should add a way to control the formatting / position of capo chords.

In reply to by Marc Sabatella

I had to hide a second voice in a place or two in order to get proper chord spacing on the second line. Selecting that second line and spacing through the chords, the cursor still jumps up to the original, higher line at every bar. So either I need to do more experimenting, or I guess I'll wait to see if the next version of MS offers the option to relocate capoed chords.

As to whether chords in parentheses are not meant for capos, observe the attached PDF. It was scanned from a major US publisher of Catholic hymnals. It's also the usage to which I've been accustomed for more than 40 years.

Attachment Size
Ps 27 The Lord Is My Light.pdf 305.32 KB

In reply to by km2002

Hmm, you shouldn't need to place anything in the second voice except a single rest at the beginning to get you started. When you select that note or rest and hit Ctrl+K, the chord symbol goes to voice 2. After that, every time you press any of the relevant shortcuts like Space for next note or beat, Tab for next measure, or semicolon for next beat, the chord input cursor will remain on voice 2, so the chords in voice voice 1 should be completely ignored. If you are encountered some particular case where this does not seem true, please post the specific score you are having problems with and precise steps to reproduce the problem. But given the score you posted earlier (Psalm 103), the following works as expected for me:

1) select first full measure
2) press "N Ctrl+Alt+2 7 0" to enter a whole rest into voice 2
3) press "Ctrl+K Bm" to enter a Bm chord
4) press semicolon to move to next beat
5) type "F#m7" to enter an F#m7 chord
6) press semicolon to move to next beat
... etc.

At no time will the chords already entered into voice 1 steal the cursor (to be clear about this, first select all the existing chord symbols and use the Inspector to move them out of the way). And you can delete that single rest when you are done with it.

Regarding parentheses, I didn't mean that parentheses are *never* used for capo chords. Just that the MuseScore feature that allows you to place chords in parentheses was not intended for that purpose specifically. The layout is designed to look correct for the *other* use case I mentioned - substitute chords, which might include sequences of chords.

In reply to by Marc Sabatella

OK, I see how that works now that I tried it. Even worked overwriting the last file on which I worked. Compared to what I've been doing, it's almost elegant.

Whichever use is intended by MS for using parentheses in chord notations, I would suggest that an extra space at both ends inside the parentheses doesn't look correct in either usage. It's the copy editor in me, I guess. That and I've seen the occasional presence of alternate chord changes that don't require the excess space fore and aft.

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